Underestimate your Programming Abilities
At the beginning of their career, it is common for programmers to think that the main thing that prevents them from delivering working software in a predictable way is lack of technical skill. And there is some truth to that. However, one thing I’ve learned over the last 8 years is that the fact that there is a boundary to your abilities will never go away, and it will never feel like that boundary is far away.
Part of what it means to mature as a professional programmer is getting better at gauging what is or isn’t within your abilities. Whenever there is a chance that you might cross the line that divides things you know how to do from things you might be able to figure out how to do, it is advisable to be very careful and think about, and also openly talk about, the estimated cost, risks, and benefits of potential choices. Otherwise, you will be yet another programmer who keeps promising more than they can deliver, who keeps being surprised by unexpected complications, who keeps getting stuck after biting off bigger chunks than they were able to chew. That’s the risk of not learning how to recognize and work with the ever-present limit of your abilities.
The basic method I am presenting in this article involves the following steps:
- Categorize the predictability of different approaches you could take.
- Do the most predictable thing first.
- Investigate if the riskier approaches are worth it.
When confronted with a technical problem, there is usually a range of solutions you can come up with, which can roughly be divided into three categories:
The Safe Bet
You have done basically the exact same thing before, and all you have to do is do it again.
The Puzzle
You are confident that you are able to get through it, maybe after doing some research and talking to people.
The Opportunity
You have a great, novel idea for how to solve something a lot of other people have struggled with.
Given the choice between three potential technical solutions where one is a Safe Bet, the other a Puzzle, and the other an Opportunity, which one would you choose, intuitively? Depending on how confident someone is in their abilities, they might go for the most promising, but also most risky solution they can think of—something that they hope might stretch their abilities, something that they hope to be proud of when it’s all done. From a personal development perspective, that can be a good strategy. If you are working on a private project and it doesn’t really matter that much whether or when it will be finished, feel free to go wild with your ideas and throw predictability out of the window if you feel like it.
However, in a professional context, your personal satisfaction and learning experience are usually not the top priorities. What is much more important for companies is the ability to decide what to deliver, make a plan for how to do it, and execute it. Any technical decision that doesn’t contribute to that jeopardizes the success of the project. (Even if there are areas where the company wants to innovate, that doesn’t necessarily mean that the technical execution must also be novel.) The reality of things is that if projects take longer than expected, companies can eventually run out of money. So what they tend to do instead of waiting indefinitely is redefine goals, move people around, switch focus, and limit scope, hoping to reach some level of stability. Companies want to be able to have answers to the questions: what are you working on, how much will it be worth when it’s done, and how much are you expecting to invest in it until then. They pay you money because they rely on your ability to do what is necessary for them to deliver a product that enables them to survive—not because your solutions are creative and challenge and stretch your abilities.
What follows from that is that, in a commercial context, given the choice between three approaches, where one is a Safe Bet, the other a Puzzle, and the other an Opportunity, it makes sense to go for the Safe Bet before investigating whether the other approaches are worth spending additional time on. And if there really is no Safe Bet, you either have a good reason to solve a Puzzle instead, or the problem you are trying to solve is too big and should be split into smaller chunks first.
You might ask: but if there is a great Opportunity, isn’t it a waste of time if you implement the Safe Bet first? And what if you don’t get around to investing in the Opportunity? What if we’ll be stuck with the Safe Bet forever? Wouldn’t that be kind of sad? I agree, it does seem a bit sad. On the other hand, delivering a technical solution that is so boring that you were able to make a plan, estimate the effort, and make it work in time, is actually a great achievement.
Doing work that doesn’t exceed your ability has traditionally been the exception for software developers. We are so used to the feeling that we can do everything, anything, but unfortunately only relatively poorly and with low predictability, that it takes conscious effort to focus on doing what you know how to do. Especially if there isn’t a lot of continuity in the type of work that you do, it can be hard to recognize that even though you are fairly certain about a technical solution you’ve chosen, you don’t know enough about it for it to qualify as a Safe Bet. In fact, most of the work programmers do lives somewhere on the spectrum between those categories. If you want others to rely on you, it is better to underestimate your abilities and overestimate risks than to go in a direction that actually involves more uncertainty than you can justify.
Over time, your abilities will grow, and some approaches that used to be Puzzles will become Safe Bets, and some Opportunities will become Puzzles, but the categories themselves won’t go away. It is worth learning to recognize and work with them.
Published in Techspiration + Ideas + Making It Happen.
