How to become a good software engineer

9 min readApr 22, 2017

Since I went back as a solo consultant, people contact me to help them in their development adventures. One of the most frequent question is “How do I hire a developer or how do I know if he/she is good or not”.

It’s a vast question and in my past years working in the web industry, I can guarantee there are no clear answers. I always advice to make a trial period and see how the person fits into the team. But this is the easy answer, the full version is more complex and full of variations.

Developer is not a job anymore. It’s a status, a mindset, a combination of skills and a wide variety of opportunities. I want to share some important criteria to look at when hiring a developer.

Empathy with people and passion for the product

A developer needs to feel the passion for the product he/she is building because there will be so much energy invested into making a great product. Non-Technical people always underestimate the time and energy necessary to make top notch products but developers are fully aware of the constraints.

If a developer is working for a company building a product that doesn’t actually excite him/her, the speed of building it is exponentially slower. From my experiences, the two main reasons for a developer to work on a product he doesn’t really like are:

Money and security: the job is stable for the moment, salary is not so bad, the team is ok and the risk is low.
He doesn’t feel confident enough or doesn’t think he/she has the necessary skills to work an a more interesting product.

One more time: The gap between a passionated software engineer pushing his limits to make a product and a passive one is huge.

This is one reason why we sometimes call them “10x developers”. It’s not because they code 10 times faster. It’s because they find solutions and ideas 10 times faster. The implementation becomes a detail because they are able to make choices upfront and being confident about them (more on that later).

Communication

Code is just a tool to create a product or a service. Unless you’re working on a scientific paper involving code that will never be deployed, you will at least communicate with one person. The way you communicate information and problems immediately puts you in a different category. Because:

Developers who communicate actually care about what they are working on.
They want to learn fast. The communication opens channels of transparency between team members and this is when unexpected conversations happen.
You will be able to understand others if you communicate more yourself. Social skills and communication are not so random. There are plenty of patterns you can recognise and leverage to empower yourself and people around you.

Discipline

The biggest mistake is to translate discipline into working hours. Discipline is about being an example for the other ones. This role is not constant and inspiration, efficiency, and achievements are not always optimal between 9am and 5pm. Development is not a linear activity but you can be applying discipline at each step of the process.

As a developer, you can be structured and disciplined without having fixed working hours. Why do you think freelancers earn very decent money and build reputations while working in pyjamas? Because they have the flexibility to execute a task at the best moment and optimise their energy level without external constraints. One experienced freelancer can achieve the work of 3 passive developers without any problems or tensions.

Discipline means a lot of details put together: code quality, good commits/branch habits, good naming conventions, efficient documentation, good communication, automating tasks, setting up guidelines, and so on. This is real proof of discipline.

Visualisation

The vast majority of software today are about managing data. One user can create a profile and send data via a form, an API request, etc. Your job as a developer is to take care of this data through the whole application.

It’s an over simplification. But how the data flows into your application is the number one problem junior developers face. For a web application it could be as simple as: browser > network > http server > application > router > controller > models > database. Or it can be more tricky when you have proxies, external services, cache, background workers, API calls, etc. Developers need to visualise this data flow in their minds and understand each step.

Good developers are able to keep the big picture in mind while diving deep into the code.

A good software engineer can close her/his laptop, take a paper and a pencil, draw the whole system with simple arrows and spot the potential problem without reading the code. Then he/she will dive into the code and make a first assumption. If it’s wrong, do another try until the issue is solved.

Visualisation is tided to debugging and the way developers approach debugging can vary a lot. This mostly comes with experience and failures (more on that later).

Good visualisation can be demonstrated with hand drawing. Ask any developer to draw a system and check how clear the end result is. If something is not clear or takes time to draw, it’s because the person might not have sufficient experience in this specific part of the system. It’s not a big deal: at least you know what you don’t know. Which is the number one goal of clear communication.

Automation

As soon as an experienced developer spots a pattern, he/she will try to replicate it by creating tools. Open source is a great way to understand automation because most developers want to leverage the experience of others by using open source libraries. Reusing a library is a form of automation: you don’t want to repeat yourself.

Automation can also be done on a smaller scale like being able to create the perfect combination of tools to do one specific job. You can recognise experienced developers by talking about tooling. The tooling and the level of automation they try to reach tells a lot about their understanding of software. They want to remove the maximum pain points and focus on what really matters for the end user (UI, speed, business, marketing, customer support).

Junior developers on the other side will see the benefit of automation but not at 100%. The first reason is because they haven’t pushed their limit too much to actually fail hard and understand that good automation is the only way to create quality product and scale a team, even a small one.

You can also include testing and continuous deployment in the equation. They all matter to experienced developers.

Stay up to date

One of the first question I ask during job interviews is: “What do you read?”. It can be a wide variety of books, blogs and papers. The sources of knowledge are directly correlated to the curiosity of the person and their understanding of the world.

Technical survey is such a big part of a developer’s time. As a non-technical guy, you need to understand that reading 3 technical articles in 3h can actually make you gain 30h of development.

The second step is to organise the way you read and use what is best for you. Personally, I’m subscribed to 20 weekly newsletters, it’s about 200 articles a week, I don’t read everything. I do my survey in two steps: scan and bookmark (morning), then read (night and weekends).

Autonomy

One discussion I often have with experienced developers is “When do you consider a developer mature”. Meaning they are not juniors anymore.

And we mostly agree on one point: they are very autonomous. They are able to take any open ticket by themselves, estimate the complexity and people involved to achieve this feature, organise the workload, code, test, and deploy without waiting for “approval” from all the team.

As a developer, this level of autonomy is a combination of the experience of your team, your own experiences, and the relationship you’re able to create with your peers. Reaching complete autonomy is a critical milestone for any developer in their careers.

Pedagogy

At some point, after working on your hard skills, soft skills, discipline, and autonomy, you will be in a position to manage people.

Management is often misunderstood by developers because they see it as useless steps in the process of making a product. But I don’t want to talk about middle management by non-technical guys, I’m talking about leadership.

Good leadership is a result of the way you’re able to teach people how to be better at their job.

Other developers will trust you if you’re able to explain everything you do. As a developer, it’s dangerous to think everyone is on the same page. You always need to repeat and demonstrate your progress to actually be sure you’re on the same page. Good pedagogy and patience are key ingredients in the process.

On the other side, experienced developers will be in charge of explaining technical choices and limitations to CEO’s, managers, stack holders and many non-technical people relying on their expertise.

Failures

There are different levels of failures in development. If you combine them, you will realise they fit in one of these categories:

Applications crashes: You deployed bad code and broke the entire system for a significant period of time. This is a hard one because everyone will see it and it’s like an ocean of problems right in your face.
Data loss: probably the worst. At some point, your backup systems were not hardly tested and you lost critical business data. It’s less common today because most hosting providers have automatic backups. But you will be crushed by the whole team and probably be fired if it happens.
Bad technology choices: You were super optimistic in learning XYZ and wanted to applied it in production, then realised it was a nightmare and that was slowing down the whole team.
Bad hiring choices: As a developer, you’re often in charge of validating the people your company will hire to work with you. Because you’re lacking in empathy, passion, and experience, you might not be able to have a clear point of view of the person in front of you. And you will say “Okey” by default.

You can spot other kind of failures of course but any experienced developers went through all of them to be good and fully understand why empathy, passion, communication, discipline, technical survey, automation and pedagogy are very important.

Conclusion

It’s difficult to “conclude” on the topic because the development landscape is changing a lot. We will see more and more junior developers joining the web industry and creating new products. The emerging countries also leverage remote working and create new opportunities for developers. But even if the technologies are moving fast, the various variable in the “Good developer equation” can be summarised with this: