I’ve noticed in some of Greg Young’s videos where he refers to less experienced developers on a team as “Juniors.” This actually isn’t a criticism of Greg nor necessarily of the use of the term; instead, it’s a note that there can be a mindset that can be damaging, which should be avoided.
I know this will shock many people, but when dealing with developers (or managers or executives, for that matter) who are ‘at my level’ or above, I can be pretty direct and demanding. When it comes to developers or support personnel at a lower level, either in terms of experience or on the org chart food chain, I tend to be, if anything, more protective and understanding. This is for a number of reasons.
It can be relatively easy for a person’s opinion to be dismissed by calling them ‘Junior.’ It can also be relatively easy to protect one’s own position by taking said dismissive attitude. I really hate this.
There are a couple of pretty basic examples that expand on the subject.
An overnight support person (a mix of developer and support work) sent an email to me (and others) about an overnight exception in a fairly important process. They performed a manual step to get around the exception, then sent an email with a bunch of screenshots and other information. First thing in the morning, I took a look at it and, not understanding the entire import of the information, basically said it wasn’t an issue.
End of the day, the support person came over to my desk to ask about it. “Look, I said it wasn’t a problem. Here, let’s look at your email. Take a look at this. I don’t see why that’s a problem.” He then calmly pointed out that I wasn’t interpreting his email correctly. “Okay. Let’s look at the code. I still don’t see the issue. Here. When the process hits this part of the code, it will hit this method and then….”. Long pause. Longer pause. He started to say something and I waved him off, “Yeah, hold on a second.” Longer pause. “Okay, right, this is a problem.”
It took two days to correct the issue since my first attempt to correct it produced another error the following night.
A person I’ve worked with has this habit that is really annoying. He asks me a code question, and then I answer it. 5-10 minutes later, he then asks a slightly differently worded but essentially equivalent version of the same question. I give him the same answer, annoyed. Depending on the situation, he does it again.
Now, 70% of the time (making up the number), it is because there is some piece of information he is missing. The other 30% of the time, it is because I am giving him the wrong answer, and his continual questioning is solving a problem I didn’t immediately see.
Create an environment that allows senior members to be questioned
The smart reader will immediately point out that both of these examples involve the fact that I’m an idiot. This is true, but not relevant.
Within any particular organization, based on the org chart, various people will be classified in terms of seniority (among other things). However, those classifications aren’t relevant when it comes to solving particular issues.
I think it is vital to create an environment within a software development team that allows every member, no matter their experience level, to give input, to press issues. Less experienced members are by definition less experienced, and the downsides of that are obvious, but they also can be free of blinders that is the downside of having more experience, if you know what I mean.
Linus Torvalds was once a ‘Junior.’ Take from that what you should.
It is also, in my opinion, very important, especially when you are in a position to do so, to highlight the efforts of less experienced developers when they go above and beyond doing their jobs, which from the outside, often looks like them ‘only’ doing their jobs. Positive reinforcement at an early stage of someone’s career, making note of their effort they put into what they do, means that you have a better chance of ending up with a ‘Senior’ who actually knows what they are doing, and cares about it.