This scheme comes from Kent Beck, and it’s an excellent technique to train yourself into writing better code. I use it to teach good programming practice. This is how I coach programmers, and it works.
-
First, write code that you know works.
Any moron can write code that works. This is called hacking, and it’s a pavlovian-conditioned pleasure. “Hey, it works. Can I have another biscuit now?” Sometimes, code that works is copied from other code that works. That’s ok, we’ll deal with it later.
How do you know it works? You’ll need tests, of course. Do not go on to the next step until you have tested code that works.
The hard bits are yet to come. You are far from finished.
-
Now, remove any duplication.
This is the hardest part of programming and takes years of experience to get passably good at. The programmers I think of as naturally talented have the best noses for sniffing out duplication. Experience gives you a range of techniques by which to remove it.
Do not remove duplication if it stops the code working. Sometimes duplication is easy to spot, othertimes it’s more subtle; sometimes it’s easy to remove, sometimes it’s very tricky.
This is where familiarity with the idioms and features of your chosen language is important.
This is the hardest part. If you want a name for this stage, you can call it abstraction or, if you like, design.
-
Now, make the code clearly express your intentions.
Removing duplication has already helped you here. But there’s likely further to go. Well-named methods, variables, classes. Spend some time here. Aim to concisely express, not to literally describe.
Please don’t think that this is where you comment your code. Prefer clearly written code over comments. Readable, beautiful, clear code is your aim. Trust that the how and why of the code will take care of itself.
The tricky bit here is that clarity is subjective. But, if you rename and restructure so that a programmer of your level can read the code and understand it, you’re in the right mindset.
You’re likely an average programmer. Your own understanding is a good benchmark.
Don’t introduce duplication and keep the code working. We’ve been there already, and we don’t want to slip backwards.
-
Remove redundant code and classes.
Just a final chance to tighten the nuts. And if you’ve got this far, you’re probably already in good shape, but this is where you have a chance to polish.
The tests you wrote in the first stage keep you in check here. Don’t regress: keep the code clear and free of duplication.
If you do these things, in this order, you will, with practice, produce better code and become a better programmer. There’s no magic here. Give it a try.


I'm Ben Griffiths: