What makes a great software engineer great

Today I woke up wanting to start a discussion about what it takes to be an awesome software engineer. I constantly see recruiters evaluating candidates solely based on their programming skills. Hence, most developers focus only on learning the latest programming language out there. Is that all it takes? Here's my two cents on the matter.

First, I’d like to mention that I have 12 years work experience and over those years I’ve moved from developing software, to mentoring others, to hiring new candidates, to coaching those people on how to form high-performing teams. What follows is based solely on my experience; it's not my intention to present this outline as the only way to succeed. Heck, I still have a lot more to learn and might just change my perspective next month!

When I started my career, I was passionate about technology. Read tons of books about different programming languages, even more about abstract concepts like design patterns, and countless blog posts about specific subjects such as identifying the best approach for testing external services. You know how it is. There came a day when I felt pretty comfortable with coding and addressing the different problems I was facing and, even though I knew I still had a long way to go and a lot to learn, there was this small internal voice telling me: "You rock, man, you could even be considered a senior dev anytime now." Little did I know that was only the beginning.

Once the technical aspect of my job was under control, so to speak, I started noticing problems impacting my day-to-day in other areas. Those included things like discussing possible architectural solutions with my teammates; helping clients manage the product and negotiate requirements; worrying about the process and the many features that were already implemented but not yet deployed to production for some reason; and a myriad of other things. Once I started to pay attention and care about doing those things well, it didn't take me much time to realize the huge amount of value this could add to the end goal: being a very instrumental part in helping stakeholders achieve their business objectives. That right there was one of the first major breakthroughs I had in my professional career. Many of my colleagues work hard to achieve the best code the world has ever seen: shiny, maintainable, and bulletproof. Don't get me wrong, that's amazing and all of us should definitely aim for a codebase like that. But that alone, I realized, is a more selfish developer-centric goal, which falls short when we're looking at the whole picture. At the end of the day, the reason you're getting paid for is to make a successful product.

So, what makes a great developer great, then, besides programming?

A hungry mindset

This means being hungry to do more, to do what you already do even better; hungry to continuously improve oneself. This attitude will push you to always be on the lookout for more.

More things to learn and establish a wider spectrum of knowledge. In the software business, there are a lot of things you should have a handle on, from abstract concepts to specific skills. Having a broader range of understanding will help you pick the right tool for the job ahead of you. And this hunger should never be satisfied, since new things come up every day.

People who continue looking for more things to do almost never have to be pushed to do something because they are self-motivated and diligent. They are proactive and constantly thinking about next steps.

This mindset is key to becoming a knowledgeable person who always seeks to improve their environment and the way they work, creating efficiencies wherever possible.

Being a team player

There's a lot to being a good team player. But, if I had to sum it up in one sentence, I would say that it's about acting in a way that allows you to always put the team before yourself, constantly aiming for the greater good.

This means being humble, leaving your ego at the door. Not being too much concerned about your own status lets you share the credit with your team. When this happens, you start defining success collectively rather than individually, and the team as a whole becomes a unified, unstoppable force.

It's also crucial to be empathetic, in order to understand your teammates’ and clients’ feelings. This will allow you to better detect the nuances of group dynamics and care for those around you.

Acting as your client’s business partner

Yes, you were hired to program. You are indeed a technical person and that's your forte.

But as it happens, sometimes the biggest bottlenecks have nothing at all to do with coding, but rather the inefficient way you and your team gather requirements to build certain features. Lots of back and forth can be avoided by suggesting changes to how requirements are delivered to you. One small suggestion could save your client hundreds of dollars a month, and a lot of time.

Clients always request that features be released as quickly as possible (yesterday, even). That's just how the market works. When you focus on programming alone, it's easy to fall into the "if everything is urgent, then nothing really is" train of thought. In turn, that causes you to minimize the importance of time and build the features in the best possible way according to all that you know about good coding practices but, at the expense of everything else. That right there is a dangerous zone to be in. I honestly can't remember how many times I had to change my priorities because I wasn’t concerning myself with the business. That meant asking the right questions to better understand the purpose of what I was being asked to build. By engaging in those discussions, you actually come to understand why it's critical to release some features ASAP. Maybe the smartest move in those cases is to forget about clean code, make it work, and put it out there for users to buy. You can come back and clean up the mess later. In other cases, during those discussions you and your client realize that the best course of action is actually to never add that feature in the first place, saving everybody weeks of development time and costs.

As you can see, there's a whole other level of value you can add when creating a healthy feedback loop between the dev team and product people. That happens when you care about the business as a whole.

Having good communication skills

You work with people. In order to do your job, you need to communicate effectively with people. Period.

The sorts of discussions that you'll hold inside that feedback loop I previously mentioned require outstanding communication skills. You'll need to be proactive, ask the proper questions to get the right information, be able to even say no in some situations, negotiate possible alternatives, and so on. That might sound easy, but in all these years I've only seen a handful of people handle that level of communication with grace, especially when things don't go as planned.

You'll also need to communicate with the rest of your team, of course, in order to set clear expectations regarding your progress and sort out dependencies, to review someone else's code, as well as to ask for help or to help others. Communicating well plays an important role in bonding with your team and earning their trust. Once trust is in place, you can start having honest conversations about the best way to collaborate and how to address everyone's concerns.

To achieve this, the first step is to become aware of the impact your words and actions have on the people around you. Trust me, with good communication skills you can bring a lot more to the table.

What does this all mean, then?

I usually smile when I see people evaluate candidates based mostly on their programming credentials, side projects, or coding achievements. A solid programming foundation is essential of course, but based on my experience, programming is only one component of being a great software engineer. A much bigger skillset is needed in order to become a well-rounded professional.

Finding people with the right mentality is actually the hardest part. With that in place, any developer can learn whatever technology they encounter. That's why, time after time, I'd take a team of average coders that knows how to work well together in a healthy environment and has the right mentality over a set of individual coding ninja rockstars any day.

What does your experience say? Do you also find these things significant? What other skills or aspects do you consider important?