When you’re just starting as a software developer this might be a good metric, though the more you advance in your career, other things become important. What kind of things are these? More languages? More libraries?
Kind of. But that’s only half of the story. When you’re learning your second programming language, other developers oftentimes say that you’ll hate the experience. Hating it, because everything is different from the first language you’ve ever learned. With the third language, at some point you experience that it becomes easier. The syntax might be different compared to the other two, but oftentimes underlying concepts are similar. And that’s the important part: You learn to abstract from the specific language to a general concept.
I started out as a .Net developer to build desktop applications back in 2007/2008. In the beginning I used WinForms, later on then WPF. The technologies are different but it wasn’t too hard to learn WPF where before I only knew WinForms. Some years later I got introduced to React in another client project. After the first examples and exercises with it, I felt quite comfortable because in the end it’s not so much different from WPF. “But WPF is desktop software and React runs in the browser!” — Correct! Though in both cases the underlying problem to solve is the same: You have data which needs to get rendered and you need to react to user input. The way React.js handles state (especially together with Redux) is not so different from the MVVM pattern. You change data and this causes a re-render of the user interface.
So, how can you get there? Handling all these technologies, programming languages?
There are a few things. And while I am writing this, I am aware that these are written from the perspective of a cis, white man, I’ll come back to that point a bit later.
In order to move forward you need to be curious and ask questions. First of all, what does being curious look like? It means always staying up to date on what other developers are doing. For example, attending user groups in your town or reading news sites such as lobste.rs. The important thing is: You don’t need to understand everything that is happening. It’s like a giant puzzle. When you’re starting out, there are many different pieces which don’t seem to fit together and don’t form a full picture yet. Though over time, you learn more things like “there’s version control”, “there are search engines like Elasticsearch”. Things that when you hear them for the first time don’t make any sense. But these things will come back at some point and it’ll become more concrete what these things are doing and how they all fit together.
The second part to moving forward in your career as a developer is asking questions. This can be problematic because if you’re not a cis, white man there is a risk in getting classified as incompetent. Oftentimes, this risk is caused by cis, white men. I don’t exclude myself here. If everyone can’t ask questions because others tell us we’re incompetent, it’s impossible to advance.
So, what can we do to create an environment where it is okay and actually encouraged to ask questions?
What I learned for myself is: It’s a lot about patience. The fact that we as cis, white men understood something and can apply it doesn’t make us superior in any way. We also didn’t learn how to program over night. Maybe we have started earlier than others, but that’s all. Not everyone has the privilege to start learning it as a teenager or spend lots of time in the evenings and weekends in front of the computer to practice it. It takes time. This means that we as more senior developers need to sit down with juniors, explain in their language, and explain it again. Again and again. While we’re doing that, words like “easy” or “just” are a no go. Why is that? Because if you say something like “Oh yeah, building this API was easy”, for yourself it might be the case, but you’ve also doing this already for some time and it’s most likely not the first time you do it. However, for somebody who’s doing this the very first time there are a lot of unknown unknowns. They have a lot of questions in their head. There is a lot of uncertainty about many things like “How do I validate my input?”, “Why do I need this API actually?”, “Why is data formatted in this JSON format?” etc. Now, when you say “Oh, that’s easy” for them this means “I am missing an obvious point here when it’s supposed to be easy”.
Therefore, in order to not get into that situation, it’s important for us as more experienced developers to not assume anything. Don’t assume that the junior developer knows about everything what we’re talking about. We need to find out where they are in terms of knowledge and start from there. If this means that we have to explain more because of that, yes, that’s part of the deal. See it like this: When you’re explaining something to a junior developer, you’re finding out for yourself if you actually understand it.
Another thing is: we as more experienced developers don’t know everything. That’s okay. However, we’re oftentimes not transparent about that. This reinforces the “It’s not okay to ask questions” situation. Not knowing something is actually a great opportunity, especially when you’re working together with a junior developer. When you get into the situation of not knowing something about a certain topic, actually say “Oh, I don’t know how this works”. This is so important. Then, together you sit down with them and find out how to solve it. For the junior developer the interesting takeways are that they learn something about this particular problem you’re working on right now, but more importantly how you as a more experienced developer approach this situation. This is the really valuable skill.
To conclude, yes, there are many more things to programming than writing code. In fact, writing code is only one tool in the developer’s toolbox. For a successful career other things like general problem solving skills are important but also how we train people who just started.