Having started as a software engineer in the late 1970s, including experience as a project manager, executive, management consultant , and entrepreneur, I think you got them all right except for two. They are the most common that people fail to understand, especially in the software industry. Regarding number three, it is always better to build it right the first time without bugs than shio bugs. All software development companies and clients feel speed is everything so they don't do adequate line testing during the process building in bugs that are impossible to find and never resolved. It's a major flaw and tradition in software development. Number 20 is true but conveys the wrong message. Process is there to guarantee the desired results, regardless of the person executing the process. The risk is that the process isn't followed or the process wasn't designed correctly. The software industry relies too much on heroes and long hours and not enough on proper processes. For example, lean development is not a process, it's a methodology. Other than these, the rest are the same conclusions I reached even though my experience started much earlier. Because people haven't changed and management hasn't earned any of the important lesson lessons. I spent much of my career solving impossible problems that management created only to discover these rules that your network, politics, and managing up is how you create a career, not by doing a good job designing and developing software. One final point that wasn't mentioned is that good software that solves problems comes from properly interviewing potential users, asking them how they experience frustrations and problems in their everyday process, whether that is a personal process or a business process, not how they would solve the problem or if they would buy the software. Those questions are worthless.
Really appreciate this thoughtful pushback, and your perspective from the 1970s adds valuable context.
On point 3 - you're right that shipping bugs has real costs, and I may have under-emphasized that. My intent was more about avoiding analysis paralysis than endorsing sloppy work. The sweet spot I've found is shipping small, well-tested increments rather than waiting for a "complete" solution. But I take your point that the industry often uses "move fast" as cover for inadequate testing. That's a real problem.
On process - I think we're actually agreeing from different angles. You're describing what good process should do (guarantee results regardless of who executes). I was warning against what bad process often becomes (bureaucratic theater). The distinction between methodology and process is important and worth calling out.
Your final point about user interviews deserves its own lesson. Asking "how would you solve this?" or "would you buy this?" is such a common trap. Watching users struggle and asking about their frustrations yields infinitely better insights. Thank you for adding that.
I find point 3 as an exceptional observation and one of the most valuable tips across 24 (all are great). At FAANG a ton of products have high levels of ambiguity, constraints and requirements that make even senior engineers struggle to find any solution that would resolve the bottlenecks and allow business to scale and operate reliably. This is where the doc writing shows up and drags for months in meetings and architecture discussions. Eventually some development work gets kicked off and abandoned in few weeks later because either priorities changed or the leadership lost patience. Building a prototype in such conditions in front of any doc writing is a game changer. Spending 2-3 weeks on the POC and then 2-3 more on a follow up MVP, if the idea resonates, is worth a thousand docs. Ultimately, decision makers need a 1-2 pager describing a high level idea, comparing prototype with other approaches, load testing results and the timeline to deliver a product to Prod. Maybe also a 1-pager for tech readers articulating how the existing issues get addressed. Instead of spending months on doc writing or debates, build something that works in weeks. It will take 1-2 days to generate a doc before selling it.
I’m 10 years into product career, and the article and these comments sum up my experience as well. Once our heads pop out above the silos, it’s interesting to see the patterns that touch on every discipline and industry.
This was some of the best stuff I've read all year. Even after writing software for so many years, I still fall into these holes of novelty and cleverness; for instance, this morning I realized that my need for a more "semantic" folder structure for a new project was just forcing me to create a custom build command that was creating unnecessary complexity. But, why.
Thank you - this means a lot. The "but, why" question is so powerful. I've started asking it reflexively now, and it's surprising how often the honest answer is "because it felt clever" rather than "because users needed it." Appreciate you sharing that.
My pleasure. I particularly enjoyed how few of the lessons were "technical" and more about ways of working. I often say, "Software is easy, people are hard."
And it points to a lot of things that should be part of the Agile culture, but isn't.
1. The best engineers are obsessed with solving user problems.
This goes not just for technology but for frameworks as well.
We should be focusing on learning to solve our problems not in technology that has us follow it.
2. Being right is cheap. Getting to right together is the real work.
The lack of teaching people how to coach and train is one of the biggest impediments to effective teams.
3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one.
We need to focus on small increments to get feedback quickly.
This requires understanding the physics of flow.
4. Clarity is seniority. Cleverness is overhead.
Explicit workflow, while specifically discouraged by those who claim our work is too complex to have explicit workflow is actually seriously important.
6. Your code doesn’t advocate for you. People do.
It's always about value. not the means to get there.
7. The best code is the code you never had to write.
This is only true if somewhere else you make it so you don't have to write it.
9. Most “slow” teams are actually misaligned teams.
People do not just automatically align. You have to know how to help them align.
10. Focus on what you can control. Ignore what you can’t.
You should protect yourself from what you can't ignore. But I agee with the general point.
11. Abstractions don’t remove complexity. They move it to the day you’re on call.
The key to complexity is either to lessen it or make it clear what's happening.
12. Writing forces clarity. The fastest way to learn something better is to try teaching it.
Agreed. Again, how to teach should be incorporated in anything taught.
14. If you win every debate, you’re probably accumulating silent resistance.
Agreed. Better to not be debating - but to be resolving.
15. When a measure becomes a target, it stops measuring.
It is often a symptom of people not understanding what is going on.
16. Admitting what you don’t know creates more safety than pretending you do.
And more learning.
21. There are no shortcuts, but there is compounding.
True. But most places hae so much rework to be done let's not forget that we can eliminate a lot of it.
There's a lot to know and learn. The key is learning how to present it and remind oneself of it when needed.
This is an aspect that has been lot on the Agile community that insists less is more.
Thanks for sharing. I definitely resonate with many of these points from my own career like the focus on impact and customers, maximising the work not done, reducing complexity, being action-oriented and making your work visible.
This is such a great article. So many of these points resonate with my experience and how I think about things. I realize I sometimes lose the compass and miss the point. I should come back to this article from time to time. Thank you for sharing!
This is a goldmine of insight — not just for engineers, but for anyone serious about creating impact. These lessons remind us that success isn’t about writing perfect code, but about solving real problems, owning growth, and working well with people.
I intermittently worked in software development for three years before switching to another field. Since March of this year, I've returned to software development, and your article is very practical and insightful. It has inspired me, thank you!
Having started as a software engineer in the late 1970s, including experience as a project manager, executive, management consultant , and entrepreneur, I think you got them all right except for two. They are the most common that people fail to understand, especially in the software industry. Regarding number three, it is always better to build it right the first time without bugs than shio bugs. All software development companies and clients feel speed is everything so they don't do adequate line testing during the process building in bugs that are impossible to find and never resolved. It's a major flaw and tradition in software development. Number 20 is true but conveys the wrong message. Process is there to guarantee the desired results, regardless of the person executing the process. The risk is that the process isn't followed or the process wasn't designed correctly. The software industry relies too much on heroes and long hours and not enough on proper processes. For example, lean development is not a process, it's a methodology. Other than these, the rest are the same conclusions I reached even though my experience started much earlier. Because people haven't changed and management hasn't earned any of the important lesson lessons. I spent much of my career solving impossible problems that management created only to discover these rules that your network, politics, and managing up is how you create a career, not by doing a good job designing and developing software. One final point that wasn't mentioned is that good software that solves problems comes from properly interviewing potential users, asking them how they experience frustrations and problems in their everyday process, whether that is a personal process or a business process, not how they would solve the problem or if they would buy the software. Those questions are worthless.
Really appreciate this thoughtful pushback, and your perspective from the 1970s adds valuable context.
On point 3 - you're right that shipping bugs has real costs, and I may have under-emphasized that. My intent was more about avoiding analysis paralysis than endorsing sloppy work. The sweet spot I've found is shipping small, well-tested increments rather than waiting for a "complete" solution. But I take your point that the industry often uses "move fast" as cover for inadequate testing. That's a real problem.
On process - I think we're actually agreeing from different angles. You're describing what good process should do (guarantee results regardless of who executes). I was warning against what bad process often becomes (bureaucratic theater). The distinction between methodology and process is important and worth calling out.
Your final point about user interviews deserves its own lesson. Asking "how would you solve this?" or "would you buy this?" is such a common trap. Watching users struggle and asking about their frustrations yields infinitely better insights. Thank you for adding that.
I find point 3 as an exceptional observation and one of the most valuable tips across 24 (all are great). At FAANG a ton of products have high levels of ambiguity, constraints and requirements that make even senior engineers struggle to find any solution that would resolve the bottlenecks and allow business to scale and operate reliably. This is where the doc writing shows up and drags for months in meetings and architecture discussions. Eventually some development work gets kicked off and abandoned in few weeks later because either priorities changed or the leadership lost patience. Building a prototype in such conditions in front of any doc writing is a game changer. Spending 2-3 weeks on the POC and then 2-3 more on a follow up MVP, if the idea resonates, is worth a thousand docs. Ultimately, decision makers need a 1-2 pager describing a high level idea, comparing prototype with other approaches, load testing results and the timeline to deliver a product to Prod. Maybe also a 1-pager for tech readers articulating how the existing issues get addressed. Instead of spending months on doc writing or debates, build something that works in weeks. It will take 1-2 days to generate a doc before selling it.
I’m 10 years into product career, and the article and these comments sum up my experience as well. Once our heads pop out above the silos, it’s interesting to see the patterns that touch on every discipline and industry.
This was some of the best stuff I've read all year. Even after writing software for so many years, I still fall into these holes of novelty and cleverness; for instance, this morning I realized that my need for a more "semantic" folder structure for a new project was just forcing me to create a custom build command that was creating unnecessary complexity. But, why.
Thanks for these great reminders.
Thank you - this means a lot. The "but, why" question is so powerful. I've started asking it reflexively now, and it's surprising how often the honest answer is "because it felt clever" rather than "because users needed it." Appreciate you sharing that.
Great summary of experience.
Thanks Bill - appreciate you taking the time to read it.
My pleasure. I particularly enjoyed how few of the lessons were "technical" and more about ways of working. I often say, "Software is easy, people are hard."
This is a great post.
And it points to a lot of things that should be part of the Agile culture, but isn't.
1. The best engineers are obsessed with solving user problems.
This goes not just for technology but for frameworks as well.
We should be focusing on learning to solve our problems not in technology that has us follow it.
2. Being right is cheap. Getting to right together is the real work.
The lack of teaching people how to coach and train is one of the biggest impediments to effective teams.
3. Bias towards action. Ship. You can edit a bad page, but you can’t edit a blank one.
We need to focus on small increments to get feedback quickly.
This requires understanding the physics of flow.
4. Clarity is seniority. Cleverness is overhead.
Explicit workflow, while specifically discouraged by those who claim our work is too complex to have explicit workflow is actually seriously important.
6. Your code doesn’t advocate for you. People do.
It's always about value. not the means to get there.
7. The best code is the code you never had to write.
This is only true if somewhere else you make it so you don't have to write it.
9. Most “slow” teams are actually misaligned teams.
People do not just automatically align. You have to know how to help them align.
10. Focus on what you can control. Ignore what you can’t.
You should protect yourself from what you can't ignore. But I agee with the general point.
11. Abstractions don’t remove complexity. They move it to the day you’re on call.
The key to complexity is either to lessen it or make it clear what's happening.
12. Writing forces clarity. The fastest way to learn something better is to try teaching it.
Agreed. Again, how to teach should be incorporated in anything taught.
14. If you win every debate, you’re probably accumulating silent resistance.
Agreed. Better to not be debating - but to be resolving.
15. When a measure becomes a target, it stops measuring.
It is often a symptom of people not understanding what is going on.
16. Admitting what you don’t know creates more safety than pretending you do.
And more learning.
21. There are no shortcuts, but there is compounding.
True. But most places hae so much rework to be done let's not forget that we can eliminate a lot of it.
There's a lot to know and learn. The key is learning how to present it and remind oneself of it when needed.
This is an aspect that has been lot on the Agile community that insists less is more.
Thanks for sharing. I definitely resonate with many of these points from my own career like the focus on impact and customers, maximising the work not done, reducing complexity, being action-oriented and making your work visible.
Thanks Andrea!
Thank you for your shared lesson learned!
Beautiful and clear insights. Thank you.
Really great pearls here! Thanks Addy!
My pleasure!
Brilliant!
my fav
Writing forces clarity - ❤️
Clarity is seniority - ❤️
When a measure becomes a target, it stops measuring - ❤️
Focus on what you can control - ❤️
Process exists to reduce uncertainty - ❤️❤️❤️
This is such a great article. So many of these points resonate with my experience and how I think about things. I realize I sometimes lose the compass and miss the point. I should come back to this article from time to time. Thank you for sharing!
Thanks Addy this is a great list! Definitely many that resonate with me.
This is a goldmine of insight — not just for engineers, but for anyone serious about creating impact. These lessons remind us that success isn’t about writing perfect code, but about solving real problems, owning growth, and working well with people.
You hit the nail on the head with this one. I can relate deeply to so many of these points. 🙏
So real!
I intermittently worked in software development for three years before switching to another field. Since March of this year, I've returned to software development, and your article is very practical and insightful. It has inspired me, thank you!