How to Be a Great Software Engineer

There is more than one way.

I did not write for the last few weeks as I enjoyed taking a break. Ha! That’s probably the first point I could write about being a great software engineer: taking breaks.

Nevermind.

What do I know, after all? I’m not a software engineer anymore. I’m a CEO, god damn it.

Not my role model.

At least being a CEO gives me some excuse to dispense some pieces of advice regularly. It turns out that over the last couple of years, I had to become a manager of people — and many people in my team are software engineers. The only thing I knew about management so far was being managed, which taught me many things, such as:

1. how to manage;

2. how not to manage;

3. how to be managed.

I don’t want to talk about the first two points here, but I’d like to write about the latter. I regularly have to give feedback to people on my team, and they often rely on the Great Engineer Framework that I built in my mind.

It’s time to write that down.

Expectations

Since I started my career as a software engineer 20 years ago, I always wondered how to improve. My initial appeal for this career was typing code on a keyboard, so I decided that the best way to become a great engineer was to be the best at technical stuff.

I coded days and nights, learned everything I could, and became amazing. I Debian-packaged hundreds of software, wrote C code for a window manager, Linux and CPython, wrote CIEDE2000 color space computation functions in Lisp, wrote thousands of lines of Python to do crazy stuff, implemented XML binding for the X11 protocol, built a scalable time-series database based on object storage, etc; you name it. I did many tech-crazy things and thought I was a great engineer.

It turns out I was only 33% good. As I grew into the tech and startup ecosystem, I started to understand whatever was around me, the industry, the business, the people. And I soon realized that this was not enough, even if I was among the best engineers you could probably find (sorry for bragging).

Aspects

After a few years, I built a mental model that I still use nowadays to give feedback to engineers in my team, based on 3 aspects that you must master to become a great engineer — like the 10x engineer they all talk about:

1. Tech

2. Business value

3. Collaboration

Tech

I just discussed tech. You have to be amazing at it, which means you have to dig deep into it. As my co-founder Mehdi says, great engineers pull the strings. This means that you’re not just there to paper over the problem; you’re here to understand it fully, to grasp it entirely, from top to bottom, and to fix it forever because you understand it.

Many junior engineers are not able to do that. They just tinker with their code until “well, it works, tests pass, whatever.” The rise of AI tooling is supporting that, and engineers working this way will have to step up their game, or they’ll disappear.

It takes a large amount of time to achieve this expertise, and as common sense says, maybe 10,000 hours. This is actually a major issue for people switching to tech after another career; 10,000 hours of coding 25 hours a week (if you just do it on the job) in a typical 45-week year is more than 8 years before starting to “know what you’re talking about.” If you start at 18 years old, tinkering with computers 60 hours a week for fun, you’ll be pretty good at it by 21. I know that’s not fair, but I see this as a major roadblock for hiring tech talents coming from a career change.

So: do tech. Don’t stop until you understand everything of what you are responsible for. I remember 15 years ago being screened by a recruiter at Google who’d ask me what happened when I typed google.com in my Web browser. Being able to explain everything, from the keyboard input to the DNS requests and TCP headers of the packet sent, to the HTTP server made me pass without a blink.

Business Value

This sounds totally stupid, and I might be slightly biased by my French experience, but there are too many engineers who do not understand business value. It actually took me a few years to understand this, probably because I was only focused on tech. Let me give you a good anecdote to illustrate this.

Ten years ago, I was called by a senior manager to help with a Python project in a media company. I go to the meeting and meet the manager. He comes from a famous French tech school — one where they learn the C standard library from scratch in their first year — and so do most of the engineers in his team. They’re managing hundreds of servers, and after evaluating various software to do that (Puppet, Ansible, etc) they didn’t find anything that suited 100% of their needs, so they built their own. They invested hundreds of hours in it, and now they’d need help maintaining it.

It turns out that what they needed was probably Ansible plus a custom plugin to reach 98% of their need in a tenth of the time, but they didn’t see it that way. They just built an entire tech project, not related to their core business, from the ground up, investing hours of time. This is the kind of similar experience I talked about in my previous post, Solving Build vs Buy. I skipped that project and moved on to other things. I had no interest in maintaining a project that was not providing core value to the business. That’d have been a great way to be ditch as soon as somebody smarter in the company realized the amount of wasted time that project might have been.

Solving Build vs Buy

This kind of behaviour applies everywhere. Engineers would spend hours trying to implement perfect systems that will scale to millions of users. While the business might have no user — yet. Engineers would spend hours building a feature or solving a problem that would impact 0.1% of users. It’s true that engineering might not be entirely responsible for the roadmap directly, but they are responsible for the time they spend on how far they go into implementing systems and features.

We live in a world where economy is the driver, which means you have to maximum throughput and minimize input. Input is your coding time, and throughput is the (extra) money the company that hires you can make with you work.

Collaboration

I could probably summarize this aspect with just:

If you want to go fast, go alone. If you want to go far, go together.

That’s entirely true. Considering the team is a problem for many engineers who are frustrated by members of their team. It does take time to deal with people, and they are not as easy to understand as computers. However, in the long run, they are the best way to provide you with leverage to achieve amazing things. Maybe another secret of 10x engineers, who knows?

Therefore, you’ll need to understand the dynamics that make your teamwork. You have to make sure your work is not isolated and is not the only correct piece of code hidden in its own corner. You need to connect both your piece of software and your brain to other pieces of software and people. I know it requires a lot of effort for some people, especially because it can feel annoying and inefficient to talk or write things for other engineers to understand what you’re achieving.

But until we can all Neuralink, yes, you’ll have to pause and do something that seems like a waste of time: talking to your teammates, your manager, or customers.

Always remember: this is an investment. In the long run, it will pay off.

Conclusion

Those three aspects are always the ones that I use to drive my feedback on performance reviews to engineers in the team. Not everyone is always 10/10 in every aspect, so it eases providing feedback and drives them to where they should improve next. They are probably not exhaustive, but they are a great way to spot great and inadequate behaviors.