What makes you a good developer?
Hint: Not just your technical skills. There is a lot more.
After I finished writing this article, I realized what I discuss here is largely applicable to other roles like product owners, scrum masters, project managers and leads, as well as the developers. So don’t worry if you aren’t a developer and feel free to let me know below what you think. Enjoy!
Being technically good or better than someone probably matters less than many think. Yes, all other things being equal, better tech skills matter. But it isn’t the whole story, not even close.
So, who is a good developer? Who is the great one? What makes you one?
I’d a chance of working with so many people over the years, witnessing some who having genius-level coding skills but still struggling generally, due to lack of other essential skills.
Let’s see how these ‘good’ ones make a difference.
1. Loving the problem vs loving the solution
Experienced developers tend to focus on the problem itself, rather than the solution. That helps them to see the bigger picture, understand the problem better and be more creative when it comes to offering a solution.
Focusing on a problem is about constantly thinking how to deliver a better experience, which can be done through several ways. Solutions vary but problems and the experience our clients are having stays paramount.
Fixating on a solution, on the other hand, limits your options straightaway and narrows down your vision. Once you ‘decide’ the solution, it’ll get more difficult to be creative and be open to other ideas, improvements. Most people are carried away by the solutions and forget the value that a solution is supposed to provide.
2. Emotional attachment to the code / solution
That happens a lot — you probably have someone in your team that doesn’t like her code to be reviewed / changed / ditched. It is understandable, that one spends hours to create a piece of code which sometimes doesn’t make it into production.
Experienced developers though know that code is just a medium to deliver a value. It’s a ‘living’ piece of asset with a lifecycle. It can (and will) be changed, improved or deleted. So better not to get emotional with your code. It isn’t your baby. Write and forget it!
3. Not pushing back
When was the last time you pushed a requirement back? For experienced developers, pushing back is just a business-as-usual. Less experienced developers can be reluctant when it comes to challenging an idea or a requirement. That usually happens with good intentions. They just want to ‘get it done’. Not pushing back when you need to may open a can of worms. It may cause waste of energy and time of several people. Even worse, it may cause maintenance issues for years to come, being a headache for a team, department or an entire company.
So, better to challenge an idea or a requirement if you’re not convinced with the way it’s asked to be done, or even with the reason of its existence.
Talk to your lead, product owner, project manager, whoever came with the requirement. Don’t worry much about the conflicts, when handled properly, they help the team to save valuable time and resources.
4. Not knowing or considering the end user
Good developers, experienced or not, have the habit of considering their end user at all times. Typical questions asked are “Would our users like this?”, “Would they use it?”, “How do we A / B test this?”
On the other hand, most juniors tend to focus on the code they’re writing, or see the feature as a technical task only, not seeing or thinking about the connection to the end user.
5. Handling the pressure
Good and experienced developers do not give in easily. They don’t agree on unrealistic deadlines or requests — doesn’t matter if it’s coming from the lead or the CEO. If it isn’t doable, then it is not doable (well, you will need to support your arguments).
Saying ‘yes’ to unreasonable requirements only causes more problems down the line.
Less experienced developers usually say ‘yes’ too easily, then rush or work more (than they should) just to make it happen. That is not healthy because even if they manage to deliver what they promised in that particular case, there will always be more work and more ‘urgent’ requirements. One simply cannot live like this, so better start saying ‘no’.
6. Trees vs Forest
Good developers are more interested in the forest itself, rather than the individual trees. Forest here is the whole business, whereas the trees are the individual tasks or code. Juniors often get carried away with the task itself.
Who doesn’t like fully focusing on a piece of code, getting in the zone and forgetting what’s going on at the other side of the room right. Well, that’s exactly what’s needed, time to time, but not always.
Experienced developers are usually interested in all aspects of the software development. You can see them commenting on a testing strategy, branching strategy, which CI tool to use and so on. That’s who you would prefer to have in your team.
7. Cannot wait to jump on to code
Everyone loves coding (well, almost). But again, the problem itself is what really matters. Juniors tend to jump on to code as soon as possible whereas more senior developers tend to analyse more, challenge the solutions offered, designing the components or at least be aware of the tradeoffs, before writing a single line of code.
Difficult, I know, but you need to hold your horses when you’re on a task.
8. Teamwork & involving others
Good developers like team work. You can see them talking to the UX guy, then the QA lead, then the product owner. They’re aware of what’s going on around them. They like collaborating, pair work and sharing knowledge.
I’m not saying juniors don’t like these. But some tend to have more fun on their own. You can see them working heads down, not interacting much with the rest of the herd.
Bonus
9. Working late hours
I used to do this a lot, when I was young. Like a lot more than I should, working very, very long hours often without breaks. Most experienced developers do not do that, no matter how important the task is.
They know there will always be more tasks. There will always be urgent requirements. Working long hours is neither sustainable nor healthy.
It should really be an exception. Like once-a-year exception.
10. Definition of done
What ‘done’ usually means to an experienced developer is different than what it means to a less experienced one. Senior developers know that the definition of done is wider than just completing the technical task. There are other questions to answer like, did the CI build succeeded? Is the work covered with the unit tests? Is it tested and merged to the develop branch? Did product owner see it? Did design guys see it, if there is a UI element?
On the other hand, it isn’t unusual to see a junior jumping up and down in the corridor, celebrating ‘finishing’ her task (that’s completing writing the code). That’s only the half of the way.
11. Code reviews
It can be a bit subjective but I believe seniors take code reviews more seriously. The more junior the developer, the more difficult it is to have a ‘proper’ code review session.
Experienced people are generally better at seeing and understanding their mistakes or improvements needed. Juniors, on the other hand, are usually more defensive when it comes to amend their ‘baby’.
