As a bit of a follow-up on a previous entry, I’ve found another question that inexperienced programmers are prone to asking which bothers me.
Will this work?
This question at least comes with significantly more detail than what is delivered with the “This doesn’t work” rhetoric I’ve discussed before. The problem here is that developers are prone to forget that they are engineers.
Now, I was never taught this in school, and I don’t have an engineering degree, but similar to the Scientific method, there is something called the Engineering design process, and for most software developers, you’re following this process (or something extraordinarily close to it) every single day.
The process looks something like this:
- Define the problem
- Do background research
- Specify requirements
- Brainstorm, evaluate, and choose solution
- Develop and prototype the solution
- Test the solution
After step six, we determine whether the solution meets the requirements fully, partially, or not at all. If the solution is not satisfactory to the stakeholders, we jump back in to steps four through six and continue to try new solutions, improve solutions, retest and collect new data to determine whether or not we’re meeting the specified requirements. Usually steps one through three are handled by product owners and business people and there might be some feedback from engineering.
But if you’re asking “Will this work?” then you are clearly stuck between steps four and five. Now, in fairness, sometimes step five can be expensive or incredibly time consuming. In those cases, bouncing your idea off of your colleagues can be considered part of the brainstorming and evaluation period, but as an engineer yourself, you need to develop a sense for when it’s the right time to move into step five.
If it would take you less time to develop and test your solution than it would take to have a conversation with a colleague about your solution, you should start by testing your solution. There is absolutely no sense in writing a snippet of code, taking it to a colleague, and asking “Will this work?”
If you ask me that question, the conversation always starts with “Did you test it?”
You may think your vastly experienced colleague knows better than you (and you may be correct). But neither of you know better than actually running the experiment. Asking your colleague has now increased the human capital invested in solving your specific problem, and it’s probably unlikely that the answer is a simply “yes” or “no”.
First, you’ll have to provide your colleague appropriate context. If the problem is not sufficiently understood, the question of “Will this work?” is impossible to answer fully.
Next, if your colleague believes your solution does work, someone still has to test it anyway to prove it works (work that could have been done before involving the colleague).
But if your colleague can quickly identify your solution as something that won’t work, they will likely have to explain to you what the problem with it is and point you in a direction toward a more likely good solution.
They key takeaway here is that programming is experimentation. If you want to be a good developer, you cannot be afraid of experimentation. If you want to know why your colleague can more quickly identify good solutions and rule out bad solutions, it’s because of the knowledge they’ve gained over time through experiments they’ve performed themselves. But when faced with a brand new problem to solve, the only edge that a 10-year-veteran might have over an intern is that they’re simply better at quickly working their way through the engineering design process outlined here.