A “fluffy” post today, that doesn’t talk about F# or EF or RavenDB etc. but about general development processes. Something I think all developers need to learn, and are always honing, is the ability to trust their instinct when something feels wrong.
What do I mean by this? Well, primarily this is about identifying when you’re working on a piece of code that e.g.: –
- takes longer than it should to write (or test!)
- is overly complicated
- involves copious amounts of boilerplate
These sorts of smells are things that we need to learn to identify as early as possible – ideally when writing it the first time, or at least before the whole team is exposed to a particular paradigm or pattern. By then it’s a costly exercise to fix because of the amount of “wrong” code that’s been written, and the re-training exercise that will occur throughout the team.
I think that when you make mistakes within software development, that’s when you learn the most – but you can only learn from those mistakes if you identify them (or someone identifies them for you). When I try to model a problem in code, often in my head I’ll go through a simple decision tree where I just knock off the solutions that I don’t think will “work” well and the ones that are left usually will do the job e.g.
- can I use a factory to make this easier?
- should I split this class into two… it seems like it’s violating SRP?
- can I use the Strategy Pattern to simplify the boilerplate and duplicate code in these classes?
More than that though, is I think having confidence in your instincts – if what you’re working on “feels” wrong, it probably is. Or to put it another way – if it quacks like crap code, walks like crap code and swims like crap code – it’s probably crap code.
Take 10 minutes in your day to review what you’re doing (or get a colleague to do it) before you get bogged down into the depths of the problem and lose perspective. I can’t stress enough how important it is to have early code reviews / pair programming sessions when developing – this is when you can shift between one approach and another as cheaply as possible. Otherwise, you’ll spend three or four days on something only for the code reviewer to say “mmmm… there’s a much better way of doing this in half the time”. You’ll most likely feel defensive that someone has essentially said you’ve wasted a few days on something, and they’ll feel awkward about saying it. It doesn’t matter whether you’re using a fantastic technology; dressing up crap code in an awesome language or framework will not save you – so spot these pigs in lipstick early, and save your team some money.