5 Habits of Great Software Engineers

I first started my journey as a software engineer back in 2008 when I joined ADP, building software for building merchants. This was my first experience working at a tech company, and as someone new to the industry, I couldn’t tell the difference between what were the good habits I should be picking up from my colleagues and what were their bad habits.

Since that first role, I have worked at 7 different companies across a variety of different industries, which as a result, gave me the opportunity to work with some incredible engineers that I have been able to pick up some good habits from.

Today I want to share with you some of those habits, focusing on the five habits which I believe all developers could benefit from having.

1. Admit when you don’t know something

Photo by Jon Tyson on Unsplash

The first habit it is important to instil in yourself is to admit when you don’t know something and accept that you can never know everything.

To give you some perspective on this, if we take a look at Wikipedia, we will find it lists over 700 programming languages alone, and when we consider that each will have its own frameworks and languages, it is clear that no one could be knowledgeable about everything.

Instead of pretending you know all the answers, you should instead admit when you are unsure and feedback to the team that you will need to take the time to learn and research about the area your exploring. Besides allowing you to get help when you need it, being known for admitting when you don’t know something can instil trust within your team that when you say you know something, you actually do.

2. Learn from your team’s mistakes instead of assigning blame

Photo by Sarah Kilian on Unsplash

As software engineers, we are often building complex systems and solving complex problems on a daily basis. Inevitably sometimes we will make mistakes; however, the focus shouldn’t be on blaming the individual who made the mistake, but instead on identifying what we can learn as a team from the mistake to prevent it from happening again.

The way in which I do this in my teams is that for mistakes that result in an incident that affects our users, we will write a post mortem. In this post mortem, we will document what happened, what was the cause, what was the impact and what the actions are to prevent this from happening again.

In other cases where the mistake doesn’t impact our users, we will normally talk about it as part of our team retrospectives, where we can safely talk about what has gone wrong and the learning we can take from it.

This approach means we spend our time focusing on team growth rather than assigning blame to whoever made the mistake. As a team, we get to share the learnings and as a whole, the whole team has much better morale.

3. Put your user’s needs above your own

Photo by Taras Shypka on Unsplash

As software engineers, we often need to make decisions about what technologies we use. The choices we make every day have an impact on both our experience as developers and the experience of our users using our products. This means we should always consider the user cost of the decisions we make.

Let’s take the example of delivering a new feature for our users. As part of the research into developing the feature, we find a library that will enable us to deliver the feature faster. At first glance, this is a win for both the user who will benefit from the feature being ready sooner and the developer who is building it. To validate this, it is important to consider the cost of using the library, this could result in a couple of scenarios:

• Perhaps it is a 1KB library that will have a negligible impact on the user’s experience of the application.

• Alternatively, maybe it is a 1MB library that will negatively impact the performance of the application.

If it is the first option, then choosing the library might have a net benefit to both the user and the engineer, however, if the latter is true then only the developer sees the benefit of using the library. In this example, I would always prioritise putting the user first to ensure they have a great experience even if it means it will take me a bit longer to deliver the feature.

4. Have strong opinions, but hold them weakly

Photo by Steve Johnson on Unsplash

In your lifetime, you might have come across the phrase, “Strong Opinions, Weakly Held”. The phrase originated from a post written back in 2008 by Paul Saffo regarding how he approaches writing long-term technology forecasts, wherein in the face of uncertainty, it’s important to form an opinion on something even if that opinion is later proven incorrect. The post itself can be found on Paul Saffo’s blog.

While it originated in technology forecasting, it has quickly been applied as a framework for thinking.

If we apply this to software engineering, you might propose a solution you believe to be correct for the problem at hand. Further down the road, you might then find your original solution will not work; however, with the additional information you learnt, you then can get to the correct solution to solve your user’s problem.

5. Listen first, speak later

Photo by Brett Jordan on Unsplash

There is a common misconception that software engineers are shut-ins that don’t like to communicate with others. The reality of being a successful software engineering is quite the opposite; we work in multi-functional teams bringing together people from different disciplines, and we work together to build great products for our users.

When working in this way, communication between everyone in the team is incredibly important so that everyone has a good understanding of what the team is trying to achieve. This communication must be 2 way, with an emphasis on listening first to all the opinions in the team and then giving your input.

This becomes even more important as you grow into a more senior engineer, where your words will carry more weight, making it difficult to not sway the conversation. Listen to your colleagues, they will have great ideas that as a team you can build on to build great products.

Conclusion

It goes without saying that there is much more to being a great software engineer than the five habits I have written about here. Software engineering is a broad complex field and what works at one company might not work at another.

These habits came from my own experiences and I would love to hear about your own experiences, what habits do you think make a great software engineer?