What makes a good developer?

Juhani Lehtimäki
Nov 20, 2019 · 6 min read

There are many different types of developers. I’ve encountered and had the pleasure to work with a hugely diverse crowd of people with varying skills and experiences. Different people have different goals in life and career. Some people in tech have drive to move forwards, become a better developer and to take the next step in their career (no, I don’t believe that a developer should become a manager if they’re great at their job). This post is written with people with passion in mind, to possibly help them to move forward and to focus on their career. However, if you are OK to be writing code in a comfortable environment you’re now and do this just for the paychecks, that is all OK, and a perfectly valid career approach, but this post is probably not going to speak to you.

Image for post
Image for post
Photo by Jungwoo Hong on Unsplash

I’ve been a software engineer for 20 years now (holy cow, I’m old). I did struggle to take the steps beyond “senior developer” for a long time. It wasn’t obvious what was required from me. In this post I wanted to take a look at my past and look at things I wish I would have known or realised earlier. Many of the points below are obvious to most readers but I hope that most of you might find one or two of the points waking up some thoughts or discussions about your role in your current or future organisation.

Many of the points below are anecdotal. They’re based on my past roles in organisations, experiences with people I’ve worked with and to my current role as a company founder.

So let’s dive in on concrete things I think are important for good developers. If you disagree with the list or think something essential is missing please don’t hesitate to comment, ping me on twitter! I absolutely love to have a discussion about this topic!

Driving informed decisions

In the Android world good examples of information every developer must know and understand is Google’s position on programming languages on Android. For example, starting a new project in Java is likely going to be a disservice to your customer unless there are some strong reasons to do so.

Another example is AndroidX. What is it, what does it mean, should you use JetPack?

I recently (only a few months back) had a short discussion with an Android developer about our project and whether or not we should already migrate to AndroidX. The response I got was “what is AndroidX?”. This kind of a situation is a huge red flag and I’m less likely to include that person into decision making in the future. Their knowledge just isn’t up to par to drive a discussion about the future.

If you’re Android developer, make sure you catch up with, at least the most important, Google I/O sessions.

It is impossible to know everything. Choosing your field of expertise is important. It is equally important to understand what you do not know as what you do know. Building software is almost always a team effort. Each developer complementing the knowledge of their peers forming a solid unit of knowledge together.

To support the team effort it is important to communicate your strengths and admit weaknesses. Pretending to know, when you don’t, can be very harmful. Networks are built on trust. In a team knowledge that is communicated usually doesn’t have to be evaluated as sceptically as knowledge from outside the team. That said, a question about “why” is not a challenge to your knowledge or an insult. It is a genuine request for more understanding. When faced with the “why” be ready for open discussion, not an argument trying to defend your position.

Attention to details, beyond the spec

A good developer pays attention to details, even if the details weren’t defined by designers, POs, etc. Maybe obvious things like touch feedback are missing in the design spec. It’s on the developer to add any such missing details.

As an example; If you’re implementing a clickable item and there is no touch feedback, add the default one — in case of Android, ripple foreground. It might be that the designer wants to change details later but “nothing” is certainly a wrong solution.

As a platform expert, a good developer adds “quick wins” to the product when they make sense. Understanding which tasks are easy and quick to add without external dependencies comes from the experience working on the platform.

Result oriented

Image for post
Image for post
Photo by Annie Spratt on Unsplash

A good developer spots issues that might make the product worse, when launched. A good example in the Android world is use of standard platform assets:

For example, if the design says that I should use iOS back arrow on Android design I probably should not. There might be a miscommunication where wrong assets were exported or the designer simply wasn’t aware of the mistake. This is when a developer must spring into action and suggest an alternative. Simply changing the design might not be the right thing to do but a developer should bring it up in the form of a suggestion. Just make these suggestions constructive, not attempts to point out mistakes!

Communication, respect, open to critique

Communication is always a two-way stream. Being polite and respectful in the message you want to get out is something we all understand. But that is not enough. A good communicator is also open to receiving comments, ideas and even critique.

Receiving critique is not easy. Developers put a lot of effort into their work. When someone, especially from outside, comes in and put your efforts into doubt it is very easy to become defensive and even offended. In moments like this it is good to take a step back and separate your person from the solution and look at it objectively. Maybe your solution is the right way to go and all that is missing is explanation. Maybe you missed a point of view and something needs to be changed. In both situations the end result is stronger and the team’s understanding has increased. It’s easy to say that “don’t take critique personally” but much more difficult to follow. But: don’t take critique personally.

Push the boundaries

Image for post
Image for post
Photo by Perry Grone on Unsplash

Developers are creative. Developers need to be creative.

Our role, as developers, is to push the product to become something more than just-another-product. We support POs and designers in their roles by complementing their skills with the technical opportunities they might not have heard about. Bringing up possibilities that we heard about in a tech talk, or experimented with in our hobby projects can fully change the trajectory of the whole product. Think about adding a fluent nearby-API experience into a product that would otherwise require complex manual tasks. When combined with skilled designers, technical opportunity can end up creating truly magical moments in the products we create.

Snapp Mobile

Snapp Mobile Engineering and Design Blog

Juhani Lehtimäki

Written by

Founder and Android lead at Snapp Mobile. http://snappmobile.io/ Co-lead of GDG Android Munich. Author: Smashing Android UI. Android GDE.

Snapp Mobile

Snapp Mobile Engineering and Design Blog

Juhani Lehtimäki

Written by

Founder and Android lead at Snapp Mobile. http://snappmobile.io/ Co-lead of GDG Android Munich. Author: Smashing Android UI. Android GDE.

Snapp Mobile

Snapp Mobile Engineering and Design Blog

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store