3 challenging questions to ask as a software engineer
3 challenging questions to ask as a software engineer
Discover three crucial high-level questions that software engineers often overlook. Learn why understanding the problem, timing, and worst-case scenarios are key to impactful solutions.
As software engineers, we love solving problems.
We love diving into the technology, the specifics of the details.
But that narrow focus can make us miss important high-level aspects.
Perfect work in the wrong direction doesn’t create the impact we intend.
It’s often the most tenured person who can step back and ask challenging high-level questions.
The question all the other engineers haven’t stopped to think.
Here are 3 of these questions
#1 What is the problem we are trying to solve?
We focus too much on the solutions. The technology. Solving obstacles when they appear.
But in the end, we are trying to solve one particular customer problem.
That’s your essence. Picture your team solving that problem and work backward from it.
When I involve a Senior engineer in some review, it’s not to get an expert opinion on a technology. But to validate the solution I propose is adequate for the problem we have.
#2 Why is now the right time?
Something software engineers have to learn early on is how to deal with imperfection.
There’s legacy code. There’s tech debt. There’s more work than people to handle it.
You have to learn to give up on particular tasks.
This means prioritizing properly the resources you have. When you are working on something, you are paying an opportunity cost of working on something else.
#3 What’s the worst-case scenario?
I have never worked on an evergreen project with zero customers.
The reality is that we join a company and jump into an ongoing project with existing customers.
Your tiny code change is supposed to improve the experience of those customers.
But in the process of it, you may impact the existing functionality negatively.
Assume something will go wrong. What’s the worst thing that the customer can perceive?
A typical question in postmortems is how can you reduce this blast radius.
If the impact of something going wrong outweighs the benefits of everything going right, you are taking too much risk.
It’s important to limit the potential blast radius and apply risk mitigation strategies.
That’s all for today. I hope you find value in these 3 ideas to evaluate on any project
Thanks for your readership :)
👏 Weekly applause
Some articles I enjoyed during the last week:
How To Get More Done – HR hates me for this weird trick by
. Concise and to-the-point productivity advice. Hemmingway applied it to its writing, Akos applies this to his coding.How to recognize the potential in engineers by
. An interesting article to focus on the potential, not the current state. Find people who are seeking discomfort to learn, going out of their way, and looking to make others better around them. Besides this article I recommend the book Hidden Potential by Adam GrantLessons From The Most Famous Coder of All Time by
. Lessons from the book “Hackers and Painters“ by Paul Graham. As I was reading I was relating to daily struggles in my team.
This is great! You can learn these really fast if you're freelancing.
#1 dictates your solution & budget. I sold solutions from custom software to Excel sheets as long as they solved the problem!
#2 is one of the difficult questions to ask. But you also learn that customers are always a priority compared to some software engineering daydreaming about code perfection. Stuff that's simple, maintainable, and works shouldn't be touched, no matter the latest trend.
#3 keep backups, ship often, have tests, monitoring, and logs. Preparing for the worst is hard, but you can reduce its impact.
“Why now is the right time” particularly resonated with me. Often developers try to convince why fixing some technical debt is important. They focus on why it should be fixed in general, but miss the fact that they need to explain why NOW is the best time to fix it.