7 simple habits of the best engineers I know
How great software engineers maintain outperformance
I’ve worked with phenomenal engineers, both at large companies, like FAANG, and smaller companies, like startups. They opened my eyes to the mythical “10x” engineer - they actually existed in real life!
Some of these engineers have went on to start their own companies, lead developments that change the web as we know it (like Vercel!), or have grown to lead billion-dollar initiatives at big tech companies today.
Throughout my time working with them, I noticed that all of them had some overlapping habits in the code they produced.
Code for the human, not the computer
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” – Martin Fowler.
Code is for humans, not just for computers.
Code is for the engineers on your team, who read, maintain, and build on top of your code.
Code is for the users, whether it’s a kid on their phone, a developer calling your API, or yourself.
The best engineers I know are product-minded: thinking about solving a problem for humans first.
The best engineers I knew always evaluated the value of their code, for all audiences.
If they missed the mark on one of the audiences, that code did not make it into production.
Detach from the code itself
Amazing engineers stay unattached to the code itself.
They were unafraid to delete and start over on code, even if they were 90% of the way in, if it meant that the end result would be better overall.
Code isn’t personal, so feedback was taken with stride.
Code isn’t perfect. Nobody cares about perfect code. They care about code that delivers change.
The best way to teach yourself to be unattached from your code is to realize that in 20 years, there’s a high chance that much of your code will either be technical debt, deprecated, or rewritten.
Use consistent standards
When writing code, stick to a consistent standard and style of coding. Consistency makes code easier to read and understand by both future you and your teammates.
A consistent style guide allows both a team and a codebase to scale easier. This is how companies like Meta and Google ship so much code without the codebase becoming unreadable and unmaintainable over time.
Every amazing engineer I knew had the team’s code standards internalized and followed it as closely as possible, knowing its benefits.
Meta has a C++ style guide for some of their open source code. (Link)
Tip: Formatting a linter for your team is definitely worth the time to set up, if there isn’t one already.
Write simple code
Every great engineer I knew produced code that may have been complex to produce, but was simple to both read and understand at the end. The best word I had for this was that their code was aesthetically pleasing.
Their code was clean, organized, and logical. Each decision made in their code made sense, and when something didn’t, it was documented well within the code.
A good way to write clean code is to follow principles, like the SOLID principles. Though they were initially designed with OOP (object-oriented programming) in mind, they are extensible to general programming:
Single Responsibility: A class should only have one responsibility.
Open-Closed: Software objects (classes, modules, etc.) should be open for extension but closed for modification, allowing predictable, maintainable code.
Liskov Substitution: Subtypes must be substitutable for their base types without affecting the correctness of the program.
Interface Segregation: Code shouldn’t be dependent on giant interfaces in which they don’t use all of it. Instead, packages should both contain and allow smaller, specific interfaces to be importable.
Dependency Inversion: High-level modules should not depend on low-level modules; both should depend on abstractions, fostering a more flexible and decoupled system design.
An example of this is naming. Good naming has no magic values, clear distinctions, descriptive function names, and understandable variables.
Don’t allow surprises
Code shouldn’t produce surprises. This is done by following code principles and writing proper tests.
Good code is predictable.
Tests force code clarity and predictability. They provide confidence. Good automated testing allows teams to make changes to code without worrying about breaking something unseen.
Some types of tests include:
Unit tests for individual components and isolated functions.
Integration tests for interactions between multiple components.
End-to-end tests that assess the entire system’s functionality from a user’s perspective
Tests should be simple. It should be easy to identify what went wrong when reading a failing test.
It’s also important to know what not to test.
For example, if the effort of an end-to-end test outweighs the actual benefit of the program, then the test is replaced by thoughtful documentation, monitoring, and alerting to the right people (such as the code owner).
Tests should also not test implementation details within the code, such as testing for certain CSS selectors in frontend code versus using data-attributes or just screenshot tests.
Communicate often
No great systems were built alone. Great engineers went through design reviews, solicited feedback, and continued iterating on their initial designs for their code.
Everyone has gaps in their knowledge that can be filled in by other people. Fresh perspectives can often help code become clearer or provide a new approach that may not have been thought of previously.
The best engineers were both communicative and collaborative - not afraid to take the time to work together for the chance at a better end result.
This can be as simple as pinging a teammate for a quick review over a document or adding extra code reviewers to an important pull request.
Code fast… and slow
The best engineers I know complete projects fast… by coding slow.
Sounds weird, right?
All these principles and habits above add more time to the overall first pass of coding. But they allow engineers to take a project’s progress forward, step by step.
By taking the time to use standards, test properly, use principles, and communicate often, they save themselves more time in the long run.
The alternative as I personally have experienced myself when I was an intern and junior engineer, as I’m sure many others have, is rushing 3 steps forward, hitting a blocker, then having to retreat 5 steps back.
Don’t follow rules blindly
The above “rules” and “principles” are simply guidelines.
Not everything can fit neatly and nicely into guidelines.
Sometimes, the code you’re writing is a square that just can’t fit into that circle. That’s okay.
In that case, make sure to document why your code is written in a certain way.
If you don’t, then someone, like future you, might come look at the code in the future and think “wow, I was dumb back then. Why isn’t this following our standards?”.
They then will spend 20 hours re-coding it to fit the standards just to come to the same conclusion as before. Sound familiar?
The reality of software development is that not all code can be clean or follow the rules perfectly.
What it can be, though, is consistent, clean, understandable, testable, and valuable.
Other patterns I noticed about these engineers, that I will write about in the future:
Deep domain knowledge in at least one field. Every single engineer that I took notes on is at the top of their field today because they focused and became experts at a certain field, whether it be frontend infrastructure, distributed systems, or clean UIs. Check out my app SWE Quiz to test your software knowledge gaps and really become a domain expert.
Marketed themselves often and appropriately. These engineers were not hiding in plain sight at all. Everyone on their team and everyone that worked with them knew their value and expertise. This came through a combination of marketing themselves appropriately and working on high-impact projects.
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.
Really well written....will definitely try and follow a few of these