This is all correct. All the high-performing coders I’ve met have these attributes. While most engineers write flowery complex code, the 10x coder writes simple elegant code that is easy to understand and just enough to get the job done. Because they write less complex code, then achieve 10x more and they do it 10x faster. They be proud of a PR that deletes more code than it adds. They also have some other attributes too. They live and breath KISS, YAGNI, SRP, LSK, they can tell the O-complexity of the code by looking at it - these are not academic exercises to them - they’re practical things they use every day. You’ll never hear them say “it can’t be done”, they get on with and find a way. They have a bias for action and they don’t take BS, they probably not a fan of process because it gets in the way. They know results speak for themselves. They leave meetings early because they have more valuable things to do. There’s no “fat” or “padding”.
How do you become a 10x engineer? I don’t think you get there by being “safe”. You have to practice your craft, you write as much code as you can. You have to read about things like SRP and apply them. You focus on outcomes, not the process.
In 10 years most code will be written by AI. It’ll be the easies code, not the hardest code. This means only the best engineers will be needed. Every engineers working today needs to be working hard to become 10x to they have a job in the future.
Wonderful article! I love the point about "Communicating Often" as a tip for the top 1% of engineers. At the end of the day, software engineers are trying to solve problems with technology and humans are involved! Now that I think more about principles like SOLID/GRASP/LSP etc, I think they all come together to suggest that when we implement solutions, the simple, intuitive/understandable solution that solves a valuable problem trumps the complicated, confusing solution that may be overkill.
This article also reminded me of a quote a data scientist at my company once said: "In data science, there's a tendency to throw machine learning algorithms at every problem. However, when you step back and think about the problem at hand, you realize that sometimes, a data science problem can be solved with simple Google sheets and plotting tools"
Wonderfully written. Communicate often is so important and people just get it wrong. Sometimes there is hesitation or barriers in the way people interact that results in weeks to resolve stuff when they just needed a good meeting.
Alex Collins, your insights resonate deeply with the essence of high-performing coders. Your depiction of the 10x coder crafting simple, elegant, and efficient code aligns with the core principles outlined in the post. The emphasis on KISS, YAGNI, SRP, LSK, and the ability to discern O-complexity as practical tools underscores the practicality and effectiveness of these approaches in daily coding life.
Your mention of the 10x engineer's bias for action, aversion to unnecessary processes, and commitment to results over bureaucracy is a spot-on characterization. The anticipation of AI's role in future coding, where the emphasis on simplicity and effectiveness becomes even more crucial, adds a thought-provoking layer to the discussion.
Your advice on becoming a 10x engineer through continuous practice, learning, and a focus on outcomes resonates as a practical roadmap for those aspiring to excel in the evolving landscape of software development.
Thanks for sharing your valuable perspective, and best of luck on your journey to mastery.
This is all correct. All the high-performing coders I’ve met have these attributes. While most engineers write flowery complex code, the 10x coder writes simple elegant code that is easy to understand and just enough to get the job done. Because they write less complex code, then achieve 10x more and they do it 10x faster. They be proud of a PR that deletes more code than it adds. They also have some other attributes too. They live and breath KISS, YAGNI, SRP, LSK, they can tell the O-complexity of the code by looking at it - these are not academic exercises to them - they’re practical things they use every day. You’ll never hear them say “it can’t be done”, they get on with and find a way. They have a bias for action and they don’t take BS, they probably not a fan of process because it gets in the way. They know results speak for themselves. They leave meetings early because they have more valuable things to do. There’s no “fat” or “padding”.
How do you become a 10x engineer? I don’t think you get there by being “safe”. You have to practice your craft, you write as much code as you can. You have to read about things like SRP and apply them. You focus on outcomes, not the process.
In 10 years most code will be written by AI. It’ll be the easies code, not the hardest code. This means only the best engineers will be needed. Every engineers working today needs to be working hard to become 10x to they have a job in the future.
It does sound like they also like acronyms a lot :).
What is LSK??
He might have meant LSP - Liskon Substitution Principle.
Really well written....will definitely try and follow a few of these
wonderful post! I love the visuals you used to convey your thoughts.
Awesome article. We so often forget as engineers that we are not writing code for computers as much as we are writing code for humans. 😅
We are going to spend 95% of our time reviewing existing code, and or refactoring it or extending it.
Readability and standard patterns are key to making your code live long, and be extensible, readable, maintainable, and performant.
Thanks for sharing!
Wonderful article! I love the point about "Communicating Often" as a tip for the top 1% of engineers. At the end of the day, software engineers are trying to solve problems with technology and humans are involved! Now that I think more about principles like SOLID/GRASP/LSP etc, I think they all come together to suggest that when we implement solutions, the simple, intuitive/understandable solution that solves a valuable problem trumps the complicated, confusing solution that may be overkill.
This article also reminded me of a quote a data scientist at my company once said: "In data science, there's a tendency to throw machine learning algorithms at every problem. However, when you step back and think about the problem at hand, you realize that sometimes, a data science problem can be solved with simple Google sheets and plotting tools"
Wonderfully written. Communicate often is so important and people just get it wrong. Sometimes there is hesitation or barriers in the way people interact that results in weeks to resolve stuff when they just needed a good meeting.
Thank you Raviraj! Totally agree with you - communication can be hard skill to get right, but is only positive in collaborative situations.
Thanks for sharing, I think I need to fix my mind. lol
Alex Collins, your insights resonate deeply with the essence of high-performing coders. Your depiction of the 10x coder crafting simple, elegant, and efficient code aligns with the core principles outlined in the post. The emphasis on KISS, YAGNI, SRP, LSK, and the ability to discern O-complexity as practical tools underscores the practicality and effectiveness of these approaches in daily coding life.
Your mention of the 10x engineer's bias for action, aversion to unnecessary processes, and commitment to results over bureaucracy is a spot-on characterization. The anticipation of AI's role in future coding, where the emphasis on simplicity and effectiveness becomes even more crucial, adds a thought-provoking layer to the discussion.
Your advice on becoming a 10x engineer through continuous practice, learning, and a focus on outcomes resonates as a practical roadmap for those aspiring to excel in the evolving landscape of software development.
Thanks for sharing your valuable perspective, and best of luck on your journey to mastery.