I’ve worked with some truly brilliant developers over the years. There was the guy who programmed in C++ to whom every problem could be solved with templates whose knowledge I envied but whose code I could never understand.
There have been frontend developers who couldn’t use source control or format their code consistently but who produced great pages that worked well.
I’ve envied how people seem to produce the end results well with the very latest technologies whilst all the time I’ve just been one of those good solid developers who waited a few years for the new stuff to become accepted standards.
Some of that may well sound like back-handed complements and to some extent it is but in other ways it isn’t.
Those developers that have an innate confidence in their abilities and can go home and sleep at night not worrying that they’ve left bugs in a system whereas, until I discovered test-driven development, I lived in a constant state of doubt.
But lately, having had to start leading teams and being the tech-lead on some really quite awkward problems, I’ve found that the confident but rigour-lacking developers are tougher to work with when at this level.
The problem is that, in a team, your code needs to be workable for the lowest common-denominator which is always going to be the junior new-hire who has several months experience of coding and no domain knowledge. And if the code isn’t formatted consistently and obvious in intent then it’s not worth having. If the test coverage is poor then continuous integration (which is not a pipe-dream) is impossible. If the boring crap like following Github Flow or similar isn’t done then you can only have one small team working on a system.
And I can do this. I’ll not be writing you an Angular page anytime soon or enthusing about the latest technology that Sitepoint have an article on and I’ll not solve a problem by writing a whole generic framework that solves that problem and what I envisage being the system needs in 18 months time (quick hint, like forecasting the weather, your predictions for the medium-term future are wrong – build for the short term without backing yourself into a corner).
Books like Clean Code for how to code, Two Scoops Of Django or the Symfony best-practices docs for how best to solve problems with a framework are essential reading.
As a tech-lead, give me a smart and curious developer with some healthy self-doubt and no experience over anyone lacking any of those attributes but years of experience.
Once, with a lot of time pressure on a project, I was given a new member of the team who had little experience and the idea of training him up just seemed like a task that just added to the teams’ workload.
But he was smart, curious, enthusiastic, and sociable and if you gave him a task he’d learn how to do it and come and ask for help if he had exhausted the depths of Stack Overflow. And taking the time to explain the problem to him was worth the rewards of having him then taking this new knowledge as a foundation to build on.
Whereas I’ve often been given new developers with years of experience who can’t use source control or push back when you ask for tests to be written before the code – the confidence they have in how they’ve always done things seems to prevent them from changing.
I finally seem to be becoming confident and happy in my abilities even though I still have the healthy self-doubt that I know the one true right way to do anything and that I treat any code I’ve written as mildly suspect until someone else has reviewed it.
It still bugs the hell out of me that I’m not constantly at the bleeding edge of technology, but then again those at the bleeding edge of technology produce beautiful but fragile systems.
