Archive for May, 2016

Another post on being senior

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.

Taking the initiative

I came across an article by Vaggelis Giannikas about the 3 stages of being a Ph.D. student. Each stage involves taking more initiative and responsibility, and they lend themselves to comparison with what it means to be a mature software developer. Here are the 3 stages, reworded slightly for the non-academic world:

  1. I expect my boss to tell me what to do.
  2. I do my own research on the different options and go to my boss for advice on which one to pursue.
  3. I decide what to do and persuade my boss if s/he has any doubts.

Adapted from: XRDS Vol. 21, No. 3, Spring 2015, “The PH.D. Journey: Tips from somebody who managed to defend his thesis”

Growing as a software developer means moving from stage 1 to stage 2 to stage 3. In each stage, the software developer takes more initiative and also bears more responsibility for the outcome.

For example, in stage 1, a junior developer expects his boss to tell him what bugs to work on, and might throw in a few small features. The junior developer is mostly responsible for asking for more work, and the boss is responsible for reviewing what was done and making sure the right work is being done.

In stage 2, the boss has given a developer a larger feature, and the developer goes and researches 2 different solutions that would implement it. If the options are different technical choices, she might go to an architect for advice. If the options would have different product/user experience implications, she might go to a product manager for advice. The stage 2 developer is more proactive in getting the necessary information to make the decision.

Stage 3 represents someone who is an architect or product manager. They decide what to do and persuade the rest of the organization if they have doubts. Persuade is a great word here because it’s saying I can be a stage 3 developer without actually having the title that goes with that. In other words, even if I’m not a manager on the org chart, I can have that kind of influence on others. The stage 3 developer bases their decisions on their experience and expertise, and is responsible for impacting the organization in a positive way.

In conclusion, I liked this outline of what it means to grow as a Ph.D. student because it can be applied to becoming a mature software developer. As I grow in my ability to write code, I want to grow in my ability of seeking advice, making decisions, and persuading others.