There’s one surefire way to determine if someone is a great programmer, or if they are merely good: their attitude towards automated testing. In fact, their attitude towards testing will tell you a lot about their attitude towards programming, design, project planning, almost every other aspect of a technical project.
The best programmers (and I would argue this is true for the best people in other technical fields too) love automated testing. A well designed test proves that something is finished. It means you can safely move on to other areas, because you know that you’ve shown that this piece works the way it should. And when I say ‘well designed test’, I mean a test that shows how things behave when all is not well.
It’s relatively simple to design a test that shows what happens if you do the right thing. That’s one test. Awesome. You now know that whatever you’ve designed/built will do that one thing. But what if something changes? What if the inputs are different? Unicode strings instead of plain strings? Strings instead of integers? A poorly formed XML document? The best programmers build in tests for common errors to make sure that their code or system behaves well. Either it copes sensibly, or degrades gracefully. Or maybe it fails hard so you know when it happens, and it tells you exactly what went wrong so you know how to fix it.
These are all areas where other programmers fail, but great programmers succeed. The best programmers go one step further and use automated tests. Then you can find out if the the tests that used to pass, 4 weeks ago before a bunch of things got changed, still pass today. And when they don’t, you find out now, not during the live demo to the customer.
The not-so-great programmers will beg off writing tests saying that they take too much time, or that you’ll have to waste time maintaining them. Wrong. Because a robust testing setup saves you lots and lots of time. Every time you have to go hunting for a bug that’s crept into the code, you’re wasting time. Every time you don’t understand why your new function isn’t working properly, because you can’t easily test just the new parts, you’re wasting time. Time that could be better spent adding more functionality, or testing other failure modes, so when you ship product, your code not only works, it works well.
I’ve long been a poor, or possible just good, programmer. I’ve been spending a lot more time writing tests for my code lately, and I’ve got to say, I’ve seen the light. If you’re not spending at least half your time writing test cases to test your code, you’re wasting a lot of time bug hunting. And even if the automation is as naiive as running a script from cron, do it. It’s really easy to ignore tests you haven’t touched in a month or so, and then suddenly find out the changes you’ve been making have broken huge swathes of functionality.
So, are you a great programmer? Or merely good?
Pingback: BlogFest2: Dimension Data | eigenmagic