I know that I’m not a good programmer and this knowledge makes me actually a very good one. As Kent Beck says: “I’m not an excellent programmer, I’m just a good one with excellent habits.” [1] I know I’m a bad (read “a little above average”, if you plan to hire me ;-)) programmer and therefore my code will contain bugs. So I like to write unit tests even before the code itself, and I prefer having the test fail first for thus I’m sure that it works (well, at least in a basic way). Being a bad programmer I also know that my design isn’t perfect and no matter how hard I try it’s very likely that it will need to be changed in the future. I therefore don’t try to account for all possible future changes and to make it so flexible that it could deal with all of them because I know I’d be wrong in this. Instead, I prefer simple designs and well isolated parts of code so that it will be easy to reorganize and refactor them as needed. Last but not least, knowing my weaknesses I appreciate very much when somebody else reviews my design and code and I’m very receptive of different points of view and ideas. For the same reason I do not hesitate to ask my collegues for an opinion or an advice when I’m unsure. (Kent Beck yeasterday twittered: “amazing how fast you can finish if you care more about feedback than avoiding criticism”.)
The net result is that I create a simple, well-tested code open to changes (i.e. easy to change in a safe manner), which is easy to read an understand (for I know that somebody will need to modify it many times, often the somebody being an older myself). And because I’m not afraid to ask, I’ve better and more suitable designs than I could create just by myself. Thus I produce a good, clean code as a good programmer would write.
[1] M. Fowler – Refactoring, page 73 in the Czech translation
[2] R.C. Martin (ed.) – Clean Code: A Handbook of Agile Software Craftsmanship
Moved to https://blog.jakubholy.net/ 