10 Qualities Every Great Software Engineer Should Have
When I started coding professionally I wanted to write perfect code because that’s what I thought a great developer was.
However, I quickly learned that there is more to software development than just writing great code. The question of “What makes a good developer?” is a subjective question and you will get different answers when you ask different people. For me, this is an opportunity to show others that there is more to just writing code.
In this article I will share my views on the qualities shared by great developers – inspired by my experience, things I’ve learnt and the books and resources I’ve come across.
They Appreciate Quality Architecture
Once you’ve learnt a programming language, understand the syntax and how to write a program in this language what else is there?
I could write something quick that solves the problem and ship it now. Or I could spend some time to think about good design and architecture before hastily shipping a solution.
If I return to this piece of code in a few months time will I still understand what it does? If I ship it today will the code have a memory leak tomorrow? If I wanted to extend this functionality, how easy or difficult will it be to add on top of this? If someone else had to fix a bug and looked at this piece of code, can they understand it? If I wanted to scale this, is it easily scalable? If I wanted to replace a technology (for example the data store) how easy is it to do so? If I wanted to deploy this seamlessly, how easy will it be?
There are lots of frameworks, design patterns (also anti-patterns) and architectural patterns that are out there. Choosing the best one for right now isn’t always an easy task, and sometimes you can get it wrong, but if you put the investment up front it will pay off later.
Don’t forget that infrastructure plays an important role here too. It’s good to keep in mind how the system will be put together, what will deployment look like, what infrastructure is required, when is it needed by, what networks will different parts of the system belong to, how will the infrastructure be monitored, how will infrastructure scale, any proxies or load balancers required, the list goes on!
I’ve seen infrastructure as an afterthought in projects when it is often quite complex and should be thought of upfront. It’s also important not to delay complicated or time-consuming aspects of the project in the beginning otherwise you’ll find yourself spending more time later dealing with issues than had you dealt with the component earlier.
Also keep in mind that there needs to be a balance between good design and over-engineering. Be pragmatic and find the balance for what is good for the problem you are solving.
They Understand The Importance Of Testing
Testing is not just for the QA team. The tech world is constantly evolving and moving forwards – and that includes testing. Developers used to (and some may still do!) write code then pass this over the wall to the QA team to test and report bugs. If you look around at the best engineering teams, they don’t really work this way anymore, they are very involved in testing (dare I say, even passionate about testing) to ensure a quality product.
There is a fine art to testing, you find that the breadth and depth of testing can be quite complicated. There are automated test frameworks, cloud-based solutions, different devices, different clients, different types of testing (performance, unit, integration, functional to name a few!).
The best developers I’ve worked with understood how important testing was and again it showed in their work because they cared about it.
Reflecting back on my career, I have been fortunate enough to work with some amazing software developers who have inspired me immensely. The biggest factor to me is that these people cared about their work.
There has to be passion and drive in what we work on, and eventually this is evident in the products we deliver. When I think of the products I love using, I don’t just see amazing product vision I also see great development, care and pride in the work delivered.
When you care about what you do, other people will see it too.
They Cultivate A Sense Of “We’re In This Together”
I’ve worked in different sized teams and teams that have consisted of a range of roles. For me, a perfect team is everyone, with a vested interest in what we are delivering, working together – be it product managers, designers, testers, customer service, whoever it is – the team that works on the project/product are all important and we need to work together.
It’s much easier to be on the same page and work together than butt heads and have a battle of egos. I would rather focus on what we’re working on, why it’s important and what value are we bringing to the users. If I can help my team then I’m helping the main objective.
If something goes wrong or someone is stuck, help them out and they will do the same for you. It’s also a lot more fun working in a team that respects each other and gets along than one that is disconnected. Some of the best friendships I have started from the workplace!
They’re Excellent Communicators
This point might seem pretty obvious, but you will be surprised at how many people (not just developers) struggle with this point. I am naturally introverted, so initially I had to push myself to get out of my comfort zone and reach out to other people, form good relationships and “talk the same language” with them.
We seldom work alone and can work with a range of people. I could be in a team where we each work on our own task, then a whole day later find we worked on solving the same thing. We could be in a meeting and at the end of the meeting nobody understood what each other were saying. I could be talking to customer service and we might not understand each other. I could be presenting to the CEO and they would need to quickly understand what I’m talking about.
Communication doesn’t just involve physically talking to someone either. There are teams which work remotely and need to communicate to make sure they’re on the same page, have regular updates and have a channel to get fast feedback.
Keep in mind that communication should be effective – remember who you are communicating with and why. What is the outcome you are hoping to achieve? Is it more effective to pick up the phone, walk over to someone’s desk or send them 10 emails? Does the person you’re communicating with prefer an email or a face to face chat?
They’re Able To Troubleshoot (Under Pressure)
Systems are never perfect. Things can go wrong and there will be times when we need to roll up our sleeves and investigate issues.
This again would seem obvious but you will be surprised that there are people who struggle with this or don’t realise how much of an important skill this is. If something is happening in production that is costing the business revenue you’re the one who needs to figure out WTH is going on!
For example, if there is an issue, how will I know where to start looking? What tools can I use? If something is happening in production right now, how can I work through the issue systematically, calmly and stay focused on the important details? How much time should go by before I inform others of my findings or progress? (Don’t forget they’re also waiting anxiously for updates). If another team is having a problem, do I sit back or offer to help?
As a developer the technical aspects can involve (and not limited to) – tailing logs, replicating the issue, looking at stacktraces, analysing metrics and graphs, looking at client-side errors, checking memory usage, thread behaviour, user behaviour or looking at what state the system was at when the issue started occurring.
This matters to me because I want to know when something is going wrong. I want the system that I work on to be stable, robust and awesome. I want customers to have a great experience and I want to be innovating not fighting fires.
They’re Comfortable Refactoring
This point complements the design and architecture point from above. When you work on something and make technical decisions about something you have worked on, you can get it wrong. The decision may have been a good decision at the time, or perhaps the old team made the decision that doesn’t fit with the product right now, so you will find that refactoring needs to happen. Remember this is a living product and things will constantly evolve.
I’ve come across legacy systems, code that is difficult to understand, difficult to extend or test. It feels like there is friction or there are too many places to change or overly complex that you get confused or lost keeping track. These are some symptoms of technical debt and the system got to a point where you need to rewrite/rebuild/redo. This is a scenario you want to avoid because whenever you want to extend the code it feels like a jenga puzzle and takes much longer than starting from scratch.
The trick is to refactor all the time. Anytime you touch something, leave it better than you found it. You will have less technical debt to deal with if you keep refactoring as you go. It’s also good to keep this in estimates of your work and always have time to refactor in projects (saves more time later down the line). It’s like keeping your house tidy 🙂
Bear in mind that you shouldn’t get too carried away with refactoring. Remember to be pragmatic about it and find the balance between time and return on investment.
They Understand Why
This one is tough to explain without sounding like an optimist. There are great resources out there, one of which is an excellent book by Dan Pink called Drive which talks about autonomy and mentions that the most motivated employees just get what the company is trying achieve. There is also a great TED talk by Simon Sinek that mentions how the best employees understand “why”.
In my personal experience I have worked with great teams and not-so-great teams and one of the things that sets them apart is that the great team understood “why”. What is the company trying to do? Are we trying to bring great experiences to customers (“delight our customers” as marketing say) and drive innovation? What you find is that teams that “just get it” will just work well and know what to focus on. There is an understanding and a synergy which is great to be in.
Personally I like feeling that I’m making a difference and I like working in an environment that allows me and my team to be a part of it. I like to see customers loving the product and being proud to be a part of it. If I wasn’t invested then I wouldn’t go the extra mile. I’ve found this to be true with the best teams I’ve worked in too.
Even when there are initiatives which require a lot of change in processes and how people think, I am actually energised by this and just want to get started. I can visualise the finish line and the benefits the journey will bring.
They Learn… Continuously
We’re constantly learning in our jobs and if you’re not learning then something is wrong. When I first started in my career I was keen to catch up with the senior guys. I aspired to be like them, be just as knowledgeable and know everything.
I asked them what they were reading, coding and videos they were watching in their free time. I felt like I had to know everything and to catch up quickly. Part of that was being junior and the other part of it was being a female in technology, not wanting to look dumb. I noticed that the best developers I had worked with put in the extra time to learn and I wanted to be just like them (of course it’s your free time, you’re welcome to do what you want to! Find what works best for you)
Another point is that learning can come from various sources, not just books. Blogs are great – many of the top companies out there have a tech blog which you can follow and learn from. Other things that are great are meetups, study groups, forums, online courses, twitter (and other social media) and videos. I’m sure I’ve missed something here, but you get the picture you can learn from many sources.
You have to want to learn. No-one can make you to learn if you don’t want to.
Learning about other technologies exposes you to other patterns, frameworks and ideas and keeps you current. By doing so you can bring these ideas back into your work, which could really bring more value into your work and drive innovation for example. Bear in mind that there is always the right tool for the problem – try not to get carried away with the next shiny new toy or choosing a framework that doesn’t quite fit or will cause problems down the line.
They Take Part In The Community
I am naturally introverted. I never thought I would be involved in the tech community, but I love it. What I find is that the tech community is inspiring and it is a community – we help each other learn and grow.
I have had the great fortune of attending and being a part of tech meet ups such as Women Who Code and Rails Girls (there are so many to list!) which have helped me grow as a person, helped me with self confidence and also let me help others learn technology. I love being a part of a movement to enable more learning, especially for women and students in technology. I love helping to create a tech community so that everyone enjoys learning from each other.
The attendees, coaches and facilitators gets a buzz, you feel the energy and enjoy connecting with others. It gets quite addictive after a while 😉
They Write Awesome Code (Obviously!)
I’ve saved this point for last because it is the most obvious. It is very important and also quite subjective. Common qualities would be that code is (again not an exhaustive list) – easily readable, concise, as bug-free as possible, follows some style guide, well designed, easily extensible, easily testable, has good test coverage, does something cool and so on.
How do you know you write good code? Apart from the pat on the back from your boss or team mates you kind of don’t. You look at other people’s code and choose to follow it if you think it’s good. You read books on good code and try to follow.
For me, what tells me if I’m improving is if I look back at my old code and want to rewrite it. That tells me that I’m learning and want to make it better, because I must be writing better code to realise that the old code I wrote wasn’t so great.
I’m going to end with this point:
There is more to just working in a 9 to 5 job, repeating this Monday to Friday. The best developers care about their craft and work hard, which reflects in everything they do.
If you're looking for your next job as a software engineer, have companies apply to you by adding your profile to Snap.hr.