Last week I wrote about how senior developers take the initiative instead of waiting to be told what to do and how to do it.

Sarah Mei had a great series of tweets on the differences between junior developers, mid-level developers, and senior developers.

• Junior developers need help figuring out how to do things. They don’t have the research skills to get things done on their own.
• Mid-level devs have figured out the how and are starting to get the why, though they don’t communicate their ideas very well.
• Senior devs long since figured out the how and the why. They have their own ideas and can get other people to go along with their ideas.
• There’s a limit to how much impact one person writing code has. Senior-level impact is when you can change how other people write their code.

Tweets: 1, 2, 3, 4 (edited slightly since I don’t have a 140 character limit and I can add formatting)

I’m going to piggyback off what Sarah Mei wrote and add my own two cents.

First, the how. How is the basic mechanics of getting your job done. Say you need to fix a locale bug. The how is figuring out which source code is causing the behavior, and finding the file and line of code to modify. It’s also reading the docs to understand how locale is supposed to work.

Sometimes you get stuck. For example, you realize that in Electron, the renderer processes have access to navigator.language, but the main process does not. How will you make sure that the main process gets the correct locale?

I heard a rule of thumb that you shouldn’t let yourself be stuck in the how for more than 15 minutes. If you get stuck too long, you should ask for help. This is where the rules for asking questions can be helpful: provide context to what you’re trying to do, explain what things you tried, and show a concrete example. Eric Raymond has a great document “How to Ask Questions The Smart Way,” of which I would point to the “Be precise and informative about your problem” section.

As you grow your expertise, you won’t get stuck as much, or (more likely) when you do get stuck, you can get unstuck after doing a little bit of research on your own.

One time I asked a coworker how Java handles integer overflow. He said, “I don’t know, let’s try something,” and proceeded to write a quick unit test and used the IDE’s debugger to show the result. I felt sheepish because I realized I could have done this experiment on my own.

Programming can be a lot of fun when you can quickly write some code to prove/disprove a theory of how something will work.

Next, the why. I think a good example of this is clean coding. At some point, somebody wrote a bunch of spaghetti code, so now we have a best practice of writing modular code with loose coupling. At some point, somebody wrote the entire system using singletons, but then when it came time to maintain it, it was like dealing with a bunch of global variables, and nobody wants that. Now we know why injection is a common practice for dependency management. A mid-level developer understands clean coding and uses it in their own code, and a senior developer can get other people go along with clean coding practices.

In addition to the why of certain programming practices, there are processes or business decisions that it is helpful to understand the reasoning behind. For example, understanding the product vision. Who is the target audience for a particular feature? Are we trying to expand our product to new customers, or retain existing customers? When you know what lies behind the decisions that are handed down to you, you are able to make sense of the priorities of the business.

Sarah’s point about being senior is that a senior developer understands the why and is able to persuade others. To put it another way, it involves leadership. It’s not enough to have the right idea, you have to be able to motivate others to go along with you. It’s not enough to have the technical skills to write code. If you want to stand out as a senior developer, you need the soft skills to work with others and persuade them.