A couple of weeks ago a colleague of mine wanted some advice. The question, which we should all ask ourselves, was “How can I become a better developer?“. I am a front-end developer, and will speak from my experience, but my goal with this post is too be as general as possible. Since I believe that libraries, framework and languages are just implementation details (more on that later), even if you’re not a front-end developer, you might still learn something.

Communication

We talk a lot about soft skills, but there’s nothing more important than communication with your teammates, managers, product owners, etc. I’m probably not the best person to give you advices on this topic since it’s something I’m actively working on, but work on your communication, please. Most developers I know have some issues in their relations with the other members of their team. Here is what I’d recommend:

• Give feedback. I know it’s hard, but most of the times, people you’re working with are not aware of their shortcomings. But be careful, giving feedback is not always easy, be sure that the person is willing to accept it, and don’t phrase it too negatively. You don’t want to sound rude.
• Request feedback. That’s the other side of the coin. You might be aware of some things you could do better, but there are no better people to help you than the ones you work with. You presented something? Ask for feedback. You ran a meeting? Ask for feedback. And even without specific example, ask for feedback.
• Don’t keep people in the dark. Many developers work on complex topic, for days/weeks, submit a finished version, and then wait for a review. This is especially true when this work has been requested by a manager or product owner, and is not a group decision. First of all, it’s important to keep your colleagues in the loop, so they can more accordingly plan their work. If you’re encountering difficulties with your task, seek help, your ego is not important! And too often, what you deliver is good, but if you asked for other opinions from the start, you might have done something better. And after all the time spent, it’s often not worth it to start over again for what would only be a minor improvement.
• Make sure you’re on the same page. Don’t assume. This is somehow related to the example I just described, when someone works on a solution, without checking that it’s also what the others have in mind. But you can extend this reasoning to a lot of other things. For instance, you’ve been asked to improve the tests of your application. Does this mean that you should work on the testing infrastructure? That you should mentor people that are not good at tests (and yes, testing is a different skill, you can write good code and bad tests)? Or that you should rewrite the poorly written tests? Add more tests? Before starting to work on one of these topics, why not just check what your teammates have in mind? Keep a public roadmap, share your progress. It might also help to you to better organise yourself.

Get in the correct mindset

In French we say “La curiosité est un vilain défaut”, meaning that curiosity is a shortcoming. We could argue about the veracity of this quote, but in development, I’d say that curiosity is, on the contrary, a needed quality. You need to understand why, and how things work. Be careful, I don’t think that to be a good web developer you need to understand low level details, like how your servers work, the complexity of the CSS rendering engines or else (you’ll learn that when needed). I’m talking about this if check in the function your working with. It has obviously be written for a good reason. Perhaps by someone who’s not working on this project anymore. And to fix the bug you’re working on, you don’t have to understand why there’s this check. But I believe that you should spend the time to understand why it’s here.

• You’ll discover new parts of your codebase, will discover obscure domain rules, or better understand some constraints of your app. This is the kind of knowledge that’ll help you to have more impact in your daily work.
• You can stumble upon interesting problems (and solutions). Everybody agrees that reading code is a good way to learn, but some of the most interesting code I’ve read was related to these weird constraints. Most of day to day code is not that interesting.
• You might clean up dead code (it happens more often than we’d think). Or update it, because, there might actually be a link to the bug you’re fixing.

This idea of checking what is happening around your code also relates to a concept popularised in The Pragmatic Programmer, i.e. programming by coincidence. Too often when coding we assume too much. We assume that what we wrote will work. We assume that this piece of code we just read is important (or unimportant, it works both ways!). No surprise, but that’s not a good practice. You need to be methodical, systematic. Apart from spending more time to understand the code you’re working with, don’t forget the usual candidates, tests (unit, integration, e2e, whichever you believe in), static analysis (linters, type checkers). These are essentials, forcing you to consider cases you did not check.

Another thing that helped me to grow as a developer, was to rethink the best-practices that have been thrown at me. All the patterns, the wise knowledge. What I mean by rethinking is not being the obnoxious newcomer who challenges everything, not taking the time to consider why some things are built in a certain way. Firstly, not all practices are good. Some were, but are not anymore. Things change, and sometimes, the code or the practices are not modified. It’s only logical, software engineering is about tradeoffs, you don’t have the time to do everything, and people also forget (or quit). This means that by asking the good question at the right time, you might trigger something positive! Another strong incentive to ask yourself those question, is to learn. A lot of patterns are there for a good reason. By following them, you don’t take too much risk. But understanding the reasoning behind these decisions might teach you something!

Dive deep in some topics

I’m a front-end developer working with React. At my current gig, I use GraphQL and Flow. I don’t have to understand the way they work, their constraints, the reasoning of their author to use either of them. But doing so taught me so much. Obviously, it helped me to be more proficient with these tools. But with Flow, I learnt a lot of type theory. With GraphQL I discovered things such as cursor based pagination. This is knowledge that I’ll be able to reuse, independently from Flow or GraphQL.

Sadly, diving deeper is not always straightforward, there’s no clear way to do it. Blog posts, presentations, or closely following GitHub issues/pull requests are a good start.

Things that are actually less important than you think

When you read about advices about things to learn to become a better developer, you’ll often find some advices that might help you when applying for a developer position, but I think won’t actually make you a better developer. Knowing how to use libraries or frameworks (some might even argue languages!) doesn’t make you a better developer. Knowing React/Redux/Webpack/React-Router and so on will help you when applying for some positions. But these are things that can be learnt quite easily, and that you’ll simply learn with practice. You’ll actually observe that offers from big tech companies are usually fine with “experience with a JavaScript framework such as React, Angular or Vue”. They don’t require specific frameworks. On the same level, knowing the newest patterns doesn’t help. For instance, in React, at some point many people moved from HOCs to render props. And it’s not because you’re using render props that you’re a better developer. Even if it might be a better pattern. Or moving from unit tests of components to snapshots, or integration tests. On the other hand, these changes of patterns can be interesting to follow, because of the conversation they tend to trigger. We come back to the curiosity thing that I recommended earlier. You don’t have to use render props instead of HOCs. But understanding the benefits and drawbacks of both is actually a good thing.

If libraries are not important, at least I should know perfectly the standard API of my language, right? Wrong! Who knows which method is Array.prototype.slice and Array.prototype.splice? Of course you should know that there are functions on the prototype of Array, that’ll help you to know what to Google, but docs (and search engines) are there for that.

Side-projects are overrated. They can give you visibility when applying, they might help you to learn a specific library that some company posted on its job listing. But most of the time, you won’t dive deep enough to learn something meaningful. Software engineering is so much more complex than learning APIs and libraries (and is mostly related to people difficulties you often won’t encounter on side-projects). Most of what you’d learn in a side-project won’t help you. The exception being side-projects that teach you concepts rather than libraries.

TL;DR?

Keep an open mind, ask yourself why, communicate with your teammates, and don’t follow the hype!

I'm Augustin Le Fèvre. I work for Klarna in Stockholm, Sweden. I mostly do front-end development. Here's my Twitter.