What Makes A Good Developer
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 what I see contributes to being a good developer — inspired by my experience, things I’ve learnt and the books and resources I’ve come across.
You Care
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.
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. Also it’s 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 :)
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 teams work together with QA, understand what to test and the most effective way to test. Most good developers understand and appreciate that QA provide an invaluable insight into scenarios by approaching problems from a different perspective than developers. They also test often and try to get fast feedback so that features can be adapted quickly and bugs fixed quickly. Especially today where more and more companies move towards Continuous Integration AND Continuous Deployment.
The best developers I’ve worked with understood how important testing was and again it showed in their work because they cared about it.
Communication
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?
Design and 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. For example, if it takes 5 weeks to configure environments, then another 2 weeks to test and ensure the network and various other configuration is setup correctly you really don’t want to be dealing with this at the end of a project (or worse in production!) instead of working on this up front and ensuring that everything is ready infrastructure wise before deploying to production!
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.
Troubleshooting and Support
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.
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.
Understanding 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.
Learning
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)
What I have learnt is that this is a continual journey and you will never know everything. Just keep learning that’s the fun part :) The Programatic Programmer (another great book!) also talks about continually learning something new and how it helps you grow as a developer.
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.
Learn when you can and when it’s the right time. Nothing is worse than trying to cram something in your head when you’re tired and would benefit from taking a break instead.
Learning is fun and inspiring. If you are feeling bored, maybe it is because you aren’t learning anything anymore. I have felt like this at times and get a burst of energy learning something new.
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.
There are so many great resources out there, but this link is a great article on recommended books to check out — http://www.nomachetejuggling.com/2014/02/05/top-10-career-changing-programming-books/
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 ;)
Awesome Code
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.
One of the greatest compliments I received (when I was still a junior) was from a senior developer (who I still look up to) was that I was one of the best developers he’s worked with. That meant a lot and still means a lot to me. To hear that from someone I looked up to really helped me gain confidence in myself. I’m by no means the best developer but I am always striving to be a good at my craft and hoping to inspire others. I hope this article has helped to inspire you.
Backstory:
This story originally appeared on snap.hr as they had approached me to write a piece (edited on their site). I’ve also spoken about this at Skillsmatter FullstackCon 2016 https://skillsmatter.com/skillscasts/8445-what-makes-a-good-developer (archive: https://web.archive.org/web/20191105114412/https://skillsmatter.com/skillscasts/8445-what-makes-a-good-developer).
Who Am I?
I’m a Tech Lead at Expert360. I’ve been in tech since 2006 and I’m constantly learning, being inspired and hoping to inspire everyday.
