If life were a game...

Do you do any of these? Do you see these habits in others. Clean code is when you look at code and think "of course you would do it that way". It's simple, elegant, and straight forward. Once you look at it you can't think of a better way to do it. It seems 'obvious' but only with the power of hindsight. But it's not something you'll get much of from these programmers 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 Di...

Have you ever had to work with that guy. The one who hates going to meetings. Ridicules the other developers. Sits by themselves rarely talking with anyone while "working". Sometimes they swear a lot, sometimes they often show up late to work and often they have little interest in showing someone else how their code works. 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 beha...

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 ...