Five years ago, during a job interview, an engineering manager asked me: "How do you define a good developer?". I took some time to think about it, and I answered that a good developer fully appropriates its tools and understands them well to use them the right way.
I said, "for example, a React developer should read React's code so he would understand the mechanism under the hood so he would implement the patterns the best way possible." Then the manager asked me if I had already read React's sources. I said, "no." And so, I just explained that I wasn't a good developer according to my criteria.
It was embarrassing.
It was that much embarrassing that I kept thinking about it. Since then, I have become a lead developer and an engineering manager, and so my point of view about this job changed a lot. And today, I know how much I was wrong about the question "What is a good software engineer?".
Why are software engineers hired?
At the first point, you have stakeholders who want to deliver a product to a market. A product goal is to solve some users' issues so that the stakeholder could benefit from it. Like any product, it won't be produced just by itself. It needs people to build it!
If the product is software, it will be built and delivered through code. And so, stakeholders hire software engineers to write this code that makes this product available to the users.
What expects a stakeholder from an engineer is to solve the users' issues delivering a product. In other terms, it means to create a good user experience, to make the product valuable.
Every job is about the "why" not the "how"
The code is not an end in itself. Instead, the code is a way to make a user experience available. The users don't care about how good your code is; they don't care if you follow the best practices and implement the latest technologies. They want a piece of software that will help them ideally.
You don't expect a pastry chef to mix flour and butter perfectly. No, you wish the pie to taste good. That's the same for software! If the pie is not good enough, you won't repurchase it. And if a user experience from software is not good either, the product won't be good, and the users won't use it.
The "how" (the code) is not supposed to be the engineer's target. The "why" (the user experience) should be. For an engineer, the most critical questions are: Why are we doing this? Why will this feature help the user? Why do those specs exist?
If the answers to those questions are clear, the "how" should be easier to solve.
So, what is a good software engineer?
A software engineer's job is to provide a user experience, and so, the best engineers will provide the best user experience possible.
It means providing pleasing software to use, being performant, accessible, reliable, beautiful, etc.
The good engineers will consider the user experience as their focal point. It means having empathy for the people using their product. And for every technical tradeoff they face, they solve it while choosing the solution with the best impact for the users.
The "user experience" is a complex question. Most companies have UX/UI designers who try to solve it. But the software engineers are dealing with technical tradeoffs to transform UX/UI designers' work into an actual product. So to adequately solve these tradeoffs, engineers need to consider UX; otherwise, they will advantage the best code over the best product.
But about the technical skills?
Of course, the code quality is critical. It is nearly impossible to do a great product with harmful code. Our pastry chef makes amazing pie because he masters flour and butter mix.
But a great piece of code will not necessarily result in a great experience. That's why we should differentiate "technicians" from "engineers." Great engineers are always great technicians, but great technicians are not necessarily great engineers.
Sometimes, fantastic product ideas will lead to significant technical flaws like performance issues. And so, this is where engineers must have a leadership posture. They must talk effectively with product managers and designers, exposing the technical implementations issues and their impact on the product.
More and more dev tooling is focused on user experience metrics, like lighthouse from google chrome. Those tools promote technical "good practices," improving the user experience. It shows that engineers cannot just execute but must have some leadership on the product they're shipping because they have a specific point of view that can improve the user experience.
Excellent products come from the interaction of product managers, UX designers, and engineers.
Keeping in mind both user experience and technical challenges is only the way to find the best solution as an engineer. If an engineer is involved in the product design and the technical implementation, understanding that the goal is the outcome experience, he is a great software engineer.
The code is not an end in itself, but what the user will experience from the code is. That's my mantra since this failed interview, and I am so thankful to the person who asked me this tricky question.