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.
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
A big part of developer’s job is to stay up to date with the latest and upcoming changes on the platforms they work on. This doesn’t mean constantly riding the hype train or jumping on every new library that becomes popular in the blogs or social media. A good developer is informed, making informed decisions and guiding project towards correct and future-proof direction.
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
Design spec, tech spec, <any other> spec is just a starting point. Developers aren’t there to replicate the spec in code 1-to-1 even when it doesn’t make sense or if something is missing.
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.
The Goal of any project is to create great products, not great code. Often, great code leads into great products but code alone isn’t enough. A developer is responsible for the results as much as any other role in the project.
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
In the end, very few products can be built with just the skills of an individual. Great results are created by teams of mixed knowledge. Transferring this knowledge inside the team is probably the most important task towards a great end result. Being great at communication is much more important for a developer than being great at writing code.
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
I worked in a company that separated developers and designers into roles described as “creatives” and “technologists”. What a failure!
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.