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.
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.
I remember as an entry-level engineer I just followed the path that was set. Later on, I saw the importance of influencing the roadmap and priorities of the team with these questions.
It's important to have some decision power, either at a job or freelancing. If we just follow someone else's direction, we may be walking toward a bad place
“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.
> They focus on why it should be fixed in general,
We can all find an argument in favor and a counterargument opposing doing anything.
In the end, prioritization is taking some risks and mitigating some others. Having the big picture of the roadmap ahead helps on making those decisions
Solid questions, Fran. Agreed with asking each of these, particularly "What's the worst case." Always think about the risk. Nothing will ever go as smoothly as you think it will
I remember reading this idea in Antifragile by Nassim Taleb (if I recall correctly).
We have to evaluate the upside and the downside of our actions. We don't know exactly what will be the outcome, but a spectrum of alternatives.
If it's not a favorable action, to make it so, either we reduce the downside (put guardrails and reduce the blast radius) or we increase the upside (try to get a bigger win without risking more)
Also, humans are risk-averse. But business needs us to take action as engineers. If we flip a coin and win $1001 on heads and lose $1000 on tails, we wouldn't play out of fear. I think from some studies, humans need on average 2x the upside to take action
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.
I agree, Akos!
I remember as an entry-level engineer I just followed the path that was set. Later on, I saw the importance of influencing the roadmap and priorities of the team with these questions.
It's important to have some decision power, either at a job or freelancing. If we just follow someone else's direction, we may be walking toward a bad place
“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.
> They focus on why it should be fixed in general,
We can all find an argument in favor and a counterargument opposing doing anything.
In the end, prioritization is taking some risks and mitigating some others. Having the big picture of the roadmap ahead helps on making those decisions
Solid questions, Fran. Agreed with asking each of these, particularly "What's the worst case." Always think about the risk. Nothing will ever go as smoothly as you think it will
Thanks, Jordan!
I remember reading this idea in Antifragile by Nassim Taleb (if I recall correctly).
We have to evaluate the upside and the downside of our actions. We don't know exactly what will be the outcome, but a spectrum of alternatives.
If it's not a favorable action, to make it so, either we reduce the downside (put guardrails and reduce the blast radius) or we increase the upside (try to get a bigger win without risking more)
Also, humans are risk-averse. But business needs us to take action as engineers. If we flip a coin and win $1001 on heads and lose $1000 on tails, we wouldn't play out of fear. I think from some studies, humans need on average 2x the upside to take action