If you don't understand every line of code you write, your code is broken!
Ever start writing a pice of code, and it snowballs on you and you end up with a couple hundred (or thousand) lines of code, and it starts to get away from you? You start wondering what it all means? Maybe you're working with other developers, with various levels of experience, which is adding to the overall code mass. Collectively do you understand what you are writing?
If at any point you stop being able to understand the code you are writing, it's time to stop and rethink things. The code is broken. Now is the time to correct it!
A problem you perceive is a problem you own!
If there's something bothering you about your code base, there's no better time than the present to address it. It doesn't matter your seniority level. You should talk it through with other devs. Maybe they have similar problems with the code, but we're hesitant to bring it up. Continuously thinking about talking about, and improving your systems is the only way to keep your systems functioning. Putting off problems will only cost you more in the future!
From my experience, good code is boring code. Good good is self explanatory. Good code is modularized. Good code reads well. Good code matches up with the domain concepts. Writing good code takes time, patience, and access to experience developers who know what good code is and how to write it. Good code is hard to do, but worth the effort if you ever want to maintain it.
Writing good code is possible even under time pressure! Stress is no excuse for sloppiness!
If at any point you notice you can't understand the code, it's usually an indication that you are heading down the wrong path!
There is usually a simpler way!
When you recognize that you're code is getting to complicated, stop and think. Why is this so complicated? Is the complexity inherent to the domain? If not, then most likely it's incidental complexity.
The best thing you can do if you ever get this point is to talk it through with someone else!
The act of explaining things to someone else helps solidify in our minds what we're trying to accomplish.
Ever feel the need to write comments in your code such as
// hackety hack hack, this is a hack
? If you ever feel that need, stop. You know that your code us getting away from you. It's talking to you. Don't write that comment and carry on. While the business wants results, they also don't want to carry around a liability!
And what value to future maintainers do such comments provide? Every line of code, every character you type should have a reason, and a dam good one. The code should be clean, and as simple and straightforward as possible.
The single responsibility principle and the don't repeat yourself principle applied religiously go a long way to improving the maintainability of your code. In my experience, they aren't applied enough!
Ok, kind of a rantish vibe emerging.
To end this on a positive note, apply the 4 XP simplicity rules, and take pride in your work! Also, check out an answer I posted on Quora which has lots of links to great talks and books that I have found the most valuable.
I highly recommend you watch Rich Hickey's talk "Simple Made Easy".
Update
I just watched Uncle Bobs talk " The Last Programming Language" on InfoQ, and it fits really well into this post.
Uncle Bob talks about the divide between business and engineering, and I believe this divide does indeed exist. Deeply technical engineering work is necessary to deliver long lasting results, but it doesn't fit very well into high level business metrics.
Also, the developers and engineers who understand what it really takes to deliver quality software can have a hard time selling the costs of doing things "right". And on top of that, we developers and engineers don't agree on what " right" really means.
Ever start writing a pice of code, and it snowballs on you and you end up with a couple hundred (or thousand) lines of code, and it starts to get away from you? You start wondering what it all means? Maybe you're working with other developers, with various levels of experience, which is adding to the overall code mass. Collectively do you understand what you are writing?
If at any point you stop being able to understand the code you are writing, it's time to stop and rethink things. The code is broken. Now is the time to correct it!
A problem you perceive is a problem you own!
If there's something bothering you about your code base, there's no better time than the present to address it. It doesn't matter your seniority level. You should talk it through with other devs. Maybe they have similar problems with the code, but we're hesitant to bring it up. Continuously thinking about talking about, and improving your systems is the only way to keep your systems functioning. Putting off problems will only cost you more in the future!
From my experience, good code is boring code. Good good is self explanatory. Good code is modularized. Good code reads well. Good code matches up with the domain concepts. Writing good code takes time, patience, and access to experience developers who know what good code is and how to write it. Good code is hard to do, but worth the effort if you ever want to maintain it.
Writing good code is possible even under time pressure! Stress is no excuse for sloppiness!
If at any point you notice you can't understand the code, it's usually an indication that you are heading down the wrong path!
There is usually a simpler way!
When you recognize that you're code is getting to complicated, stop and think. Why is this so complicated? Is the complexity inherent to the domain? If not, then most likely it's incidental complexity.
The best thing you can do if you ever get this point is to talk it through with someone else!
The act of explaining things to someone else helps solidify in our minds what we're trying to accomplish.
Ever feel the need to write comments in your code such as
// hackety hack hack, this is a hack
? If you ever feel that need, stop. You know that your code us getting away from you. It's talking to you. Don't write that comment and carry on. While the business wants results, they also don't want to carry around a liability!
And what value to future maintainers do such comments provide? Every line of code, every character you type should have a reason, and a dam good one. The code should be clean, and as simple and straightforward as possible.
The single responsibility principle and the don't repeat yourself principle applied religiously go a long way to improving the maintainability of your code. In my experience, they aren't applied enough!
Ok, kind of a rantish vibe emerging.
To end this on a positive note, apply the 4 XP simplicity rules, and take pride in your work! Also, check out an answer I posted on Quora which has lots of links to great talks and books that I have found the most valuable.
I highly recommend you watch Rich Hickey's talk "Simple Made Easy".
Update
I just watched Uncle Bobs talk " The Last Programming Language" on InfoQ, and it fits really well into this post.
Uncle Bob talks about the divide between business and engineering, and I believe this divide does indeed exist. Deeply technical engineering work is necessary to deliver long lasting results, but it doesn't fit very well into high level business metrics.
Also, the developers and engineers who understand what it really takes to deliver quality software can have a hard time selling the costs of doing things "right". And on top of that, we developers and engineers don't agree on what " right" really means.
Keep up the great work! I'm completely absorbed in what you share. click now
ReplyDelete