Over my career, I’ve come to realize there are some important truths that you should keep in mind.
The senior people have experience.
Pay attention to them.
Senior people have seen more and likely have insight into subtle and/or complicated issues. They do not always have insight into your issue. But, their experience should not be discounted. This is especially true for senior people with experience in your domain, technology, or company.
Someone with a decade of experience in your technology stack has probably tripped over most of the sub-optimal design decisions and odd quirks in that technology. Likewise, someone with extensive experience in a domain is likely aware of the non-technology and legal (in some cases) pitfalls that are likely to cause problems. Finally, someone who has been in your company for many years probably has a few answers for why some decisions were made. This might prevent your team from trying to make an obvious optimization that would trip over decision that a senior person has made that is part of their political or business identity.
The junior people ask stupid questions.
Pay attention to them.
Part of the stupid question issue is really only ignorance. The junior person doesn’t have as much experience, so of course, they wouldn’t know the answer to some questions. Answering those questions is part of how they will learn to be less junior. Sometimes the questions are technical, sometimes the issue is more business-focused. All of these are just part of the learning/training of a junior person.
The real jewel of a stupid question is the one that exposes an design or process issue that has not been re-examined in a while. Some design decisions are made for perfectly valid reasons that no longer apply. The same is true for process. When a junior developer asks a question that has a nuanced answer or describes some trade-off, this is a great opportunity to teach them and to revisit the issue. Walk them through why things are the way they are, and really think about your answer.
Every now and then, this leads to the realization that the current approach really needs to be re-considered. The whole team now gets a chance to learn from something that really needed fresh eyes to see.
The question to never ask.
Never ask “Why would anyone do that?
” about customer input.
In particular, never ask this question in a condescending or insulting fashion. The user is almost never trying to do something wrong for no reason. They probably have a reason, even if it is based on a misunderstanding of how the system works. Developers usually ask a question this way when the customer manages to enter data that the developer never expected or perform steps in an order that was not expected. If you find yourself blaming the customer, you probably need better input validation.
This question is more nuanced than the others. If a customer wants to do something you have never considered before, curiosity is useful and a good thing. Trying to understand why the customer wants to do something we never considered is a good thing. It may be a lack of understanding on their part. It may be an opportunity to make something that we had never considered before.
Software always has bugs.
Some bugs are mistakes made by the programmer. Some are results of misunderstanding of the original problem (either by the customer, the business, or the programmer). Some are the result of changes in the environment or the business or needs of the users.
Much has been written on the Y2K problem. Many have opined on how stupid the original programmers were to have made the mistakes that were obvious to the developers of the late 90s. Except those two groups of developers were living in very different environments. When the original software was written storage was expensive and saving two bytes on every date was a reasonable trade-off (quite a few of these dates were stored as text strings). Just as importantly, no one expected that code to last 30+ years without being replaced.
This was not a bug as much as a design decision. The environment changed and invalidated the original decision.
This is one large, hairy example. There are others, the “Year 2038 Problem” was the same issue affecting every system programmed in C or a C-derived language. C. A. Hoare described his idea of NULL as a way to specify a missing or undetermined value a his “Billion Dollar Mistake”. One might argue that any code (or language) that depends dealing with NULLs as have an undisclosed number of bugs.
This is not a cause for despair. It’s just the reality of working with code. The Year 2038 problem has been mitigated in standard libraries by redefining the time structures. Only code that hasn’t been recompiled since those changes were made will still see issues. Some languages are moving in the direction of replacing the concept of NULL with other language features that are harder to misuse.
Despite best intentions, we will make mistakes.
Programmers are human, after all.
At some point in time every programmer will make a mistake. Some will make mistakes with large consequences. When I was a young programmer, it was pretty much expected that every programmer that has made it to mid-level or senior has at least one example of a really bad mistake that made it into production.
Most mistakes will be small and/or related to a rare edge-case. Some (hopefully the worst) will be caught by code reviewers or QA. However, some will lie dormant in the code for weeks, or months, or years before being triggered. Some of the worst bugs I’ve seen are in error recovery code, that are almost never executed, because the errors that would have exposed them are rare.
Risk analysis is important.
Junior developers do not always think about risk. Busy programmers often ignore risk for other issues.
In short, risk defines the possibility that we have made a mistake or misunderstood or missed something. It also includes the level of impact of this mistake.
To the extent possible, we try to prevent as many problems as possible. But, risk covers the possibility (probability) that some problems still remain. We can remove the problems we know about. But there are always potential problems that we don’t know about.
Risk management is about identifying possible issues and either preventing them, or more likely, mitigating the effects of those issues. This sometimes involves considering unlikely possibilities and determining any actions we can take that would reduce the impact of the problem. If the impact is small enough or the error is unlikely enough, we (or the business) might just accept the risk. In other cases, we should probably accept some cost to reduce either the probability or the impact, if the risk actually manifests.