What’s it take to be a good developer?
Brains? Of course you have to be able to think.
Logic? Sure, you need to have logical constructions.
Detailed? Maybe, you do need to pick out the intricacies of requirements.
Thorough? Yeah, I’ll give you that. The cause of all bugs is failing to cover some scenario.
I could go on about features of good developers and I’m sure readers have their own favorites; but the thing that I think stands out among the best developers is a “need to be right.” Now, of course this doesn’t mean that a developer is always right. I certainly am not. Nor does it mean that a developer needs to win every argument, although we may try.
No, the need to be right is a pursuit of correctness or best. One of the nice features of the software world is that many of our problems have absolutes in correct or incorrect; or, if not, they at least have objective comparisons of better or worse.
Does your calculation produce the correct answer? yes or no?
Does your procedure/function/method fulfill the requirement? yes or no?
Does subroutine A consume more memory than subroutine B while getting the same answer?
Does query X perform more IO operations then query Y to produce the same result?
Of course, a good developer wants to write good code; so it can be humbling when a bug is found, or a better way obsoletes your method. The need to be right though, supersedes the challenge to your ego. The need to be right is a relentless curiosity. If you find a bug in my code, thank you, if you identify why the bug occurs and how to fix it… THANK YOU! If you and I both have functioning SQL statements but yours is more efficient, THANK YOU! When I learn from a mistake or a superior design I “become right.” The need to be right is not about somebody else being wrong, it’s about you having, provably, the most correct and most efficient method possible. If that means you have to revise your solution based on new information, so be it.
One of the danger phrases that worries me is “I got it to work.” There’s nothing wrong, per se, with that phrase. I use it myself after a difficult challenge. The worrisome nature of it is that it’s often used as a declaration of finality. The task strained the brain and finally after much struggle, there is a successful result. “I got it to work, YAY!” But… does it work well? If you have the need to be right then you’ll want that answer. If you don’t, then you’ll call it done, check it in, and ship it off to production.
I’ve had many people ask me why I think it’s not a success. That’s simple. The problem was difficult, right? So difficult that you found it to be monumental when you got a successful run out of it. So then, what makes you think the thing that was so hard it couldn’t even produce the correct results until just now has simultaneously achieved maximum efficiency? Were you so busy tuning it while it was still wrong that it couldn’t possibly be any faster or less resource consuming? If so, that’s kind of an odd work style. Maybe that’s why it seemed so difficult?
It’s all related to the classic engineering joke/truism: Good/Fast/Cheap – pick 2. I believe in a corollary to that rule, it’s cheaper to doing something right once than twice wrong. So, while it might take more effort and cost to build a correct and efficient solution. In the long run that will end up begin cheaper because you don’t have to revisit as often.
However, there are traps in the need to be right. First, and probably the most obvious – you might fool yourself. If you try options A, B, C and determine C is best, that’s great; but if you never thought to look at option D you still might not be right. All you’ve done is prove you’re not the most wrong.
Second, there are problems that don’t have absolutes. “Most easily supportable”, “Best documentation”, “Most pleasing UX” – these ideals have leanings. There are approaches that seem more reasonable (follow some kind of standard, documentation that actually describes the objects, fewer interruptions in navigation) but at some point the differences just become preferences.
Third, you can be a jerk about it. If you forget that being “right” isn’t about somebody else being wrong. If you fall into this trap then you’re no longer helpful to your team even if you do happen to be “right” because attitude precludes successful cooperation.
The last trap is particularly tricky because it’s self-conflicting. Sometimes you should call it “good enough.” If the cost to improve some code is $1000 but you’ll only get $900 of benefit out of it, then don’t waste the money. It might indeed be possible to make a more efficient version; but if doing so is a net loss then don’t do it. Another problem with this approach is that it might not be that easy to produce an accurate cost/benefit analysis. If you call it quits early, you may be missing an opportunity. If you pursue too long you may be wasting time, money and other resources. When I run into this gray area I talk to my manager or client or whomever is footing the bill and give them an honest status. “I think this is working well, but could probably be improved. I’m willing to continue working on it; but it’s up to you how much to spend before accepting the results.” If you can give an estimate of cost to implement and expectation of improvement that’s even better.
Some might dismiss the idea of need to be right; that it’s just an obnoxious way of saying “try to write good code.” Any programmer that cares about their results will try to be both correct and efficient with their results. Yes, that’s true. I agree with that. However, the differentiating factor between merely being conscientious and having the need to be right is the proving.
If you ask any developer “Are you trying to write good code or bad code?” They will, of course, answer “good code.” In my opinion though, a good programmer is willing to show why their code is good. This “need” has two important benefits. First, by proving their design qualities they demonstrate they really do care about the quality of their output, they aren’t simply giving the desired response. Second, the act of proving correctness and efficiency requires technical insight and skill.
My favorite developers to work with always demonstrate this need to be right by showing their work and asking for review.
I shied away from writing a philosophical article because it’s one of those areas without an absolute. This is merely an opinion; but I thought an interesting and important piece of successful development. I hope you enjoyed reading.
Sean