Over the years I’ve been involved in a lot of developer hiring. Here I’d like to share a pearl of wisdom I gleaned from a colleague I shared the hiring process with.
Their angle was to give extra points to people with experience with both building AND maintaining systems, i.e those who stuck around long enough to understand the consequences of their own actions.
I found this is an interesting insight, the logic being that you learn the longer term impact of your design decisions from hanging around to fix the faults and add new features.
But what does staying the distance actually teach you? I think the only real way is to find out for yourself, but here’s a few things that spring to mind.
Simple isn’t easy, there’s an old saying that goes “I didn't have time to write a short letter, so I wrote a long one instead”.
The same goes for code; finding the underlying simplicity can take significantly longer than just bashing out the first thing that comes to mind. However the long term payoffs for system maintenance can be huge.
Tests can be a good thing, and test-driven development (TDD) can provide a helpful suite of regression tests to move forward with. However if the end result is tightly-coupled tests then the the pattern might be better coined Test-Driven Concrete (TDC), as instead of making change easier the product becomes almost impossible to maintain (thanks to Ian Johnson for the metaphor).
Instead of testing at the class and method level you should be testing required behaviour.
If you’re embarking on a big shiny new project, it might make sense to have some developers around who’ve been through the mill and come out the other side, and can help guide you to a more maintainable future.
Do you have any tips to share?