- The Hoarder - "I’ll add/leave this function because it may come in useful" litters your code with commented code and unused functions that rot and bloat your code
- Over-Complicator - "I've built an xml like nested config value loader to read in my three values instead of using a constant" yeah thanks. And when it turns out to have a bug we'll spend weeks trying to figure out how it all works and why you wasted company time (and money) writing it.
- Rewriter - "This 3D library doesn't quite fit my needs. I think I'll write my own and call it DirectY" and you waste weeks on it, it turns out buggy, has very little hardware support but by the time we find out the entire company is building on it and feels committed to keeping it.
- Obscurer - "CMiscValues init function runs ReadStream to setup the CoreFactory" this is not abstract this is waffle
- The Secret Recipe - "Oh it crashed because you have to call unloadAllSettings before you let the class run the deconstructor. But make sure you call close first" so basically no one can use your code without mysterious and random crashes. Thanks for your contribution.
Saturday, February 25, 2012
Tuesday, February 21, 2012
Have I been that guy? Honestly I can't say for sure I never have been. My programming idol Uncle Bob admits to being that guy once in his book Clean Coder.
There's a lot of old stereotypes around programming and computers in general. I've been told once to put up with a grumpy programmer on the promise he would work twice as fast as any other (if not faster). Turned out he was pretty clever but he wasn't any faster than the average for the team. And when he got really grumpy he got sloppy and produced some of the worst programming I've ever seen. So I've since resolved to never endure such behaviour and that any anti-social behaviour is potentially a problem.
A lot of programming issues are resolved through communication. Don't be the grumpy programmer. Don't ever think it's worth just "enduring" one.
Thursday, February 9, 2012
I've been thinking a lot about TDD, agile training and the long term behaviour of teams after such training. I've met far more programmers who have had training in TDD than I know programmers who practice TDD. And I've heard all the excuses
- You can't do TDD with this language
- You can't do TDD with this framework
- You can't do TDD with this database
- You can't do TDD with this hardware
- You can't do TDD with this schedule
All bullshit, believe me. I may have said some of those myself once
But once you get past all that you get programmers who will give you a lucid agreement that TDD is good and they should use it more. You train them and show them how it's done as well as push past the issues above.
And then they don't use it.
But why? They agreed it's a good idea and they should do more. We solved all the serious issues that were stopping them from trying. Why wont they even try and put it into their routine?
Routine. That's part of the problem. They still follow the old patterns all programmers learn. "I need to make something to do X. Not sure how to do it"... write write write "still not there"... write write write "okay it works. oh wait! I forgot to write any tests"
I want to delete that programmer's code and make him write it again. Seriously! You're so focused on writing code you forget how important it's function, adaptability and readability is. And the tools that help you get there are tests. Yes you solved X but I can't test it, can't easily change it and can't easily extend it. At least if I deleted his/her files that programmer would get some more practice at TDD.
Practice. That's part of it too. Do your TDD homework! Spend each working day after training with "what can I apply TDD to today?" Consider it incidental exercise to help improve your TDD muscles.
Is learning TDD like learning an exercise routine? Making part of it your daily routine. Setting achievable goals. Measuring your progress. And talk to others for encouragement and support. And if you get really stuck call in a personal trainer!