There’s Almost No Replacement for a Good Developer
I've been doing a lot of stuff today on a project another developer built. There are a lot of interesting ideas in the code, lots to use, but there are little things that keep making me wonder why it was put together the way it was, and that slows down what I need to do. An example is that the code throws a NullPointerException for an unknown command, and that's OK. It's the expected behavior. In my mind, there should never be a NullPointerException thrown because it's just too easy to check all the times you'd get one, and make sure that you don't try to message a null. Simple.
This made me think back to several conversations I've had in the past with developers, as well as lots of things I've read over the years about the productivity gap between decent developers and really top-notch developers.
There's clearly a difference between great developers and good developers. Much of it is experience, domain knowledge, and education. But it's not always that simple. Some of the best developers I've worked with did not have a wealth of experience, but they had made the most with the experience they had. They weren't the ones with the most education, but they kept learning and always drove to the root of each problem to make sure they understood why it happened, and what needed to be done to correct it. And I suppose in doing these things, they acquired the best experience in the time they had.
But how they got it, or what their specific qualifications were, aren't nearly as important as how they did the job. That's the big difference.
A great developer is worth far more than a good one. Even the development paradigms designed to make great developers from good ones don't really work that well. Sure, they will make fewer bugs, and the effective developer multiplier might be 1.5, but it's never going to be 10.0 - it's just not realistic. I think of woodworking... using bad, rough, chipped tools in different ways may make the table look better, but it's never going to be the same as using good tools, and the right tools for the job.
While in many cases, it might not seem like it matters, in my experience there are more times that it does matter that management doesn't think it does, than times that it really doesn't matter. Management fools itself into believing that it doesn't matter if this is throw-away code. But it does. Hacks hurt.
In the end, I haven't found the replacement for a really good developer. They understand the problem, how to design the right system - not too little and it can't expand and grow, and not too much so that it's overly complicated for the task at hand. It's a skill. It's not magic or luck. And those that think it doesn't matter are kidding themselves. It does. All the time.