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.
I would like to take a strong objection to that, although I must say I am not in the typical programming field (I dislike the word "engineer", it is programming), but an ERP consultant who can write scripting-level business automation code well. Functions with database lookups, not objects with architecture astronautism.
But my greatest skill is saying no. Just a few years ago, a company asked me to implement the thing that they have a product, it has an item number, they sell it, customer returns it, they find it is actually working OK so they refurbish it, this should have a different item number, so item ABC turns into item ABCREFURB, and then when a customer returns ABC they give him ABCREFURB as a replacement. My spidey sense got tingling, this might not be entirely legal, I went googling and bingo, and then told them "Yes, this is exactly why there is a class action lawsuit against Apple in the US and Netherlands, they are doing exactly this an this might be illegal, talk with a lawyer" and then the whole thing was dropped.
I like this story because it illustrates how a consultant developer is different from a developer. The consultant developer always sees requirements with a critical evaluation and often says no.
Also this is an illustration why IMHO the word "engineer" is not accurate, and it is not about hard or easy code. This would have been easy code if I would have accepted the spec.
It as about knowin what SHOULD be done and what should not. It is about design, or the pre-design - is what they want even legal? Does it violate accounting principles? Does it make sense?
So IMHO it is working on domain knowledge. After 22y in accounting software, I can defeat tax controllers from the German government (for example) in a debate about what my code is doing is legal. Well, almost. I argued down a 200K euro fine to 20K. 90% win.
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.
1) easy, just be forgetful and stare at your own 6 months of code as if it was new
2) clear, even the project scope can change, why should not the code
3) easy in my field, when we big business customize the stuff of the big business, we always follow their lead
4) basically, make your code an essay, don't be a techie or enginer, be a writer
5) yes, if the task is at the level of complexity that SOLID is even needed. My experience frequently not. Like no high-level modules, that come from a vendor library, only low-level ones. No subtypes, no interface. Let's be honest here, 90% of programming is just glueing libraries provided by others together, automating those libraries for something productive. Read something from this web service, throw it into that web service. It is not that hard as to need SOLID, usually.
6) automated testing is field-dependant, does not work in all fields, certainly not in mine. surprise is unavoidable, because we always make certain assumptions and life tends to not play nice with them. Surprising outputs are coming from surprising inputs. Like we assume one customer has N delivery addresses, the relationship is one to many. Then we learn sometimes multiple customers live at the same address. Oops.
7) which is why the autistic genius is both necessary but also a curse
8) I think the counter is overflowing now, but anyway, depends on the field, in my ERP scripting and not intern but 22 years in, there are just no 5 steps. Spec: import this file into the customer master data. Step 1: done.
Pet peeve. Why call programming "engineering" ? Real engineering is like heavy maths. And this is not like that. When I ask people what is "software engineering" they say "it is also design, not just coding". OK design I call in the ERP field "consulting", which why I am a consultant developer, not just developer. Like discussing stuff with managers and writing specs.
When people say design is necessary even after specs, I think they are trying to solve the wrong problem. They are trying to build a too low level thing. Let me try to explain.
Customer wants a kind of billing solution. But I know perfectly well billing needs to be integrated with stuff like accounting, payment processing etc. so they need something like SAP, and they likely already do. It would be insane to not have it.
So we do not build a billing solution out of scratch, from zero. We take the SAP they already have, which already has a kind of billing, and then we just make customizations of that code, which is simple enough, and for this reason design goes into the spec, and once the spec is done there is no design ,just coding. So we have no "engineers", we have consultants who write the spec and devs who implement it. I do both.
Haha, love your comments on the various articles I wrote! I appreciate it :)
You know - you're right. Engineering does have the weight of a more tangible, complex discipline. However, the term of "software engineering" has gained its prominence, so it's here to stay. Secondly, I do think there is a level of complexity for large systems that run the world today. I would not hesitate to compare a system with the size and complexity of YouTube to the building of a skyscraper. Though of course, one is more hands-on and involved, and the other can be done by teams sitting in front of their computers.
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.
I can really relate to the sentiment of writing readable code. I will also add write easily debuggable code. When I meant is code that one can open up six months down the line and not have to spend a week just trying to understand code that uses a lot of reflection and patterns etc that makes it so complex. I am all for following Solid but some coders use too many patterns. Love this post.
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.
"You’ll never hear them say “it can’t be done”"
I would like to take a strong objection to that, although I must say I am not in the typical programming field (I dislike the word "engineer", it is programming), but an ERP consultant who can write scripting-level business automation code well. Functions with database lookups, not objects with architecture astronautism.
But my greatest skill is saying no. Just a few years ago, a company asked me to implement the thing that they have a product, it has an item number, they sell it, customer returns it, they find it is actually working OK so they refurbish it, this should have a different item number, so item ABC turns into item ABCREFURB, and then when a customer returns ABC they give him ABCREFURB as a replacement. My spidey sense got tingling, this might not be entirely legal, I went googling and bingo, and then told them "Yes, this is exactly why there is a class action lawsuit against Apple in the US and Netherlands, they are doing exactly this an this might be illegal, talk with a lawyer" and then the whole thing was dropped.
I like this story because it illustrates how a consultant developer is different from a developer. The consultant developer always sees requirements with a critical evaluation and often says no.
Also this is an illustration why IMHO the word "engineer" is not accurate, and it is not about hard or easy code. This would have been easy code if I would have accepted the spec.
It as about knowin what SHOULD be done and what should not. It is about design, or the pre-design - is what they want even legal? Does it violate accounting principles? Does it make sense?
So IMHO it is working on domain knowledge. After 22y in accounting software, I can defeat tax controllers from the German government (for example) in a debate about what my code is doing is legal. Well, almost. I argued down a 200K euro fine to 20K. 90% win.
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
1) easy, just be forgetful and stare at your own 6 months of code as if it was new
2) clear, even the project scope can change, why should not the code
3) easy in my field, when we big business customize the stuff of the big business, we always follow their lead
4) basically, make your code an essay, don't be a techie or enginer, be a writer
5) yes, if the task is at the level of complexity that SOLID is even needed. My experience frequently not. Like no high-level modules, that come from a vendor library, only low-level ones. No subtypes, no interface. Let's be honest here, 90% of programming is just glueing libraries provided by others together, automating those libraries for something productive. Read something from this web service, throw it into that web service. It is not that hard as to need SOLID, usually.
6) automated testing is field-dependant, does not work in all fields, certainly not in mine. surprise is unavoidable, because we always make certain assumptions and life tends to not play nice with them. Surprising outputs are coming from surprising inputs. Like we assume one customer has N delivery addresses, the relationship is one to many. Then we learn sometimes multiple customers live at the same address. Oops.
7) which is why the autistic genius is both necessary but also a curse
8) I think the counter is overflowing now, but anyway, depends on the field, in my ERP scripting and not intern but 22 years in, there are just no 5 steps. Spec: import this file into the customer master data. Step 1: done.
9) yes, rules never replace common sense
Pet peeve. Why call programming "engineering" ? Real engineering is like heavy maths. And this is not like that. When I ask people what is "software engineering" they say "it is also design, not just coding". OK design I call in the ERP field "consulting", which why I am a consultant developer, not just developer. Like discussing stuff with managers and writing specs.
When people say design is necessary even after specs, I think they are trying to solve the wrong problem. They are trying to build a too low level thing. Let me try to explain.
Customer wants a kind of billing solution. But I know perfectly well billing needs to be integrated with stuff like accounting, payment processing etc. so they need something like SAP, and they likely already do. It would be insane to not have it.
So we do not build a billing solution out of scratch, from zero. We take the SAP they already have, which already has a kind of billing, and then we just make customizations of that code, which is simple enough, and for this reason design goes into the spec, and once the spec is done there is no design ,just coding. So we have no "engineers", we have consultants who write the spec and devs who implement it. I do both.
Haha, love your comments on the various articles I wrote! I appreciate it :)
You know - you're right. Engineering does have the weight of a more tangible, complex discipline. However, the term of "software engineering" has gained its prominence, so it's here to stay. Secondly, I do think there is a level of complexity for large systems that run the world today. I would not hesitate to compare a system with the size and complexity of YouTube to the building of a skyscraper. Though of course, one is more hands-on and involved, and the other can be done by teams sitting in front of their computers.
True, true, but how many people work at such big systems? Do you? Me I am just like glueing a webshop to an order processing software mostly.
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.
great
Thank you for sharing. Loved this post - inspirational
Very nice article
I can really relate to the sentiment of writing readable code. I will also add write easily debuggable code. When I meant is code that one can open up six months down the line and not have to spend a week just trying to understand code that uses a lot of reflection and patterns etc that makes it so complex. I am all for following Solid but some coders use too many patterns. Love this post.