The Knowledge Gap
I doubt that this will come as a news flash to anyone reading this, but starting your first job in tech is hard. Really hard.
There are a lot of reasons for this but for most people I think it comes down to the fact that there are just so many things to learn. If you're like me, and your first job was building apps for the web, not only do you need to learn the foundational technologies you'll be working with, like HTML, CSS and JavaScript, but you need to learn about the platform itself! The web is so idiosyncratic that it's tough to translate a lot of knowledge from desktop and mobile development.
So learning the tech can be a bit of an undertaking but, all in all, I think it's manageable, especially if you enjoy the work. The problem is, you'll have to learn a lot more than just the tech. Companies are complex, even small ones, and there's often a lot of 'tribal' and company specific knowledge that you're going to have to pick up in order to solve certain problems. That may not sound as difficult as learning the tech, but I would argue that it is because at least with tech you have documentation. Company knowledge isn't gained through study like tech knowledge. Often, you just pick it up over time and through conversation, which makes finding a piece of knowledge way more challenging.
As you go through your first couple of weeks on the job, it won't take long for you to realize just how much knowledge you need to gain in order to catch up to the people around you. This is a pretty overwhelming feeling, to say the least.
I felt completely out of my depth when I first started, which may sound like a bad thing, but on reflection, there was a positive aspect to it. It gave me a purpose, and made me incredibly motivated. I was motivated to make sure that I caught up as quickly as I possibly could. Despite my lack of knowledge, I desperately wanted to prove myself to my team and have an impact on the project that I was working on.
The Emotions
Wanting to have an impact is great and all, but I quickly realized that doing so was going to be a serious challenge.
On my team at GoDaddy, we follow a pretty close interpretation of Scrum, and we have a board in JIRA where we keep track of all of our pieces of work that we want to get done during a single sprint. For about the first half of my internship, which was a solid month and a half, I would look at the JIRA board and not have any idea how to do well over half of the work. That left me with one viable path forward; pair programming. I'm a big fan of pair programming, it's a great way to learn and build up a team. That being said, the early pairing I was doing at my internship felt less like I was pairing to learn and more like I was pairing to survive. I didn't like being so reliant on my teammates.
Meetings were also rough in their own way, because they were often just full of conversations that I couldn't participate in. Odds are, I just didn't have enough context about a particular product, team or technology in order to contribute. I was constantly encouraged to ask questions, because I had good teammates, but I was often reluctant to do so. If I was present for a discussion involving a particular technology I didn't know anything about (which was fairly common), the only question I could really ask what that technology was. That would probably lead to five more questions in order to get enough context to be able to participate. So, I didn't end up asking questions like that during meetings. I would just wait until I could ask my teammates the large-scale questions later.
Over time, these day-to-day feelings started to wear down on me. I began to feel like I was a complete burden to my team. From my perspective, I was just absorbing knowledge and resources without providing anything of value in return. I wasn't really helping anyone with their problems, I wasn't going and making big, productivity-boosting changes to the codebase, so as far as I was concerned, I wasn't really doing much of anything. I absolutely hated this feeling.
The Plan
Like feeling of being overwhelmed I discussed earlier, this feeling of being burden had a plus in that it was a huge motivator to perform as well as I could. For me, the one thing that could prove that I was really contributing to the team and was worth the effort that my teammates were putting into me was to make a big contribution in code. That felt real to me, it felt tangible and it was black and white. With something in code, I felt like it would be impossible for someone to say that I hadn't played my part appropriately.
Now, this isn't a bad idea on its face. I think that being motivated to make serious code contributions is good thing, and making those kinds of contributions should be a goal of every new developer. That being said, I was very caught up in this goal, especially considering I had only three months to accomplish it. To me, if I couldn't achieve this goal, my internship wouldn't have been a complete success. It might've been good, but I would've left feeling like I left an opportunity on the table.
So, I got incredibly impatient. Like I said, I had only three months, so I had to go from knowing practically nothing about the web to making a serious code contribution to a React project in three months. That's no easy task.
I decided that I would make a trade off. Mind you, I wasn't really thinking it through that much during the internship itself, I was just doing what I thought I had to do, but it was a pretty serious trade off. I decided to play the short game instead of the long game. Rather than spending the better part of my time and energy learning about React and the fundamentals of the web, I would focus on learning something really niche. My theory was that by focusing myself I could become hyper productive in one particular area in a relatively short period of time.
For my internship, I decided that Redux was going to be my niche. Reach may seem like the logical choice, but React just seemed like too much of a behemoth to me at the time. Three months didn't seem like enough time to be able to become truly productive, so I learned a passable amount of React and went all in on Redux, which was much more approachable.
The Result
Shockingly enough, I was actually able to accomplish my goal. Towards the end of my internship, I had made a pretty large impact on my team's codebase.
As far as I could tell at the time, the decision to play the short term game seemed to be working out in my favor. I was quite productive that summer and pushed out a lot of code. Most of it was pretty good, but there was one notable exception.
I don't think it's uncommon for a developer to push out some code that they once thought was good and then cringe at later. In fact, it's probably a good thing that you look back and cringe; that means that you learned something. Unfortunately for me, the one piece of code from my internship that really sticks out to me as being particularly egregious is the code that constituted my big contribution. The biggest mark that I left on that codebase also happened to be the worst, in my opinion.
That's bad enough, but after my internship finished I realized that playing the short game impacted negatively in another way. It sounds so obvious when I write it down, but I just didn't think of it at the time. When you play for the short game, you reduce your chances of succeeding in the long term, and that's what happened to me. By ignoring the fundamentals and the knowledge that I would gain from focusing on them, I was basically ensuring that it would take me much longer to get to the point where I could actually help people and be a good teammate in the way that I envisioned.
It wasn't until after I left my job and took a real, deep dive into React that I gained enough knowledge to feel confident about helping others.
The Revelation
Unfortunately, by that point, the knowledge wasn't useful to anyone (besides myself) because the internship was over and I was back at school. Getting the chance to take a break from work was really beneficial for me. I hadn't taken much time to reflect during my stint as an intern. I was so consumed by actually doing the work and trying to get things done, that I never took the time to just chill and think.
I mean who knows, if I didn't have a full gap year between my internship and starting full time, I probably would've had to learn the things that I'm articulating in this article the hard way, through some major mistake, rather than through reflection.
So what exactly did I reflect on during my time at school that enabled me to write this post? There were a lot of things, but the most important thing was a point that both my mentor and manager made to me during my internship. I was just too busy being in my own head to listen to them, but it was easily one of the most valuable things that they expressed to me.
They told me that junior developers, like senior developers, have inherent value.
It's just different and more subtle than than the value of senior developers. That doesn't make it any less important, though. Senior developers provide a value that is very out there, very in your face. They make big, architectural decisions that affect an entire project, they have some in depth technical knowledge that they share with another team to help out their project, they make big code contributions that make a project noticeably better. I could go on, but I think you get the point. Senior developers have an obvious value.
Junior developer's value comes from the nature of who they are rather than the extent of their technical knowledge. Junior developers provide value by partaking in the team building and knowledge sharing processes of a team. They keep a team flexible by bringing on a fresh perspective and encourage the team to be better by their mere presence and engagement. Now, that all may seem a little less exciting depending on what you're into (I know it was for me at first), but I would argue that these contributions are just as important as the technical ones.
If you find yourself not unconvinced, allow me to attempt to persuade you by further discussing the virtues of junior developers, and hopefully demonstrating how they seem to be so well disposed to participating in the process of team growth. I think that if I had truly paid attention and understood everything I'm about to share here, I wouldn't have made the same, impatient mistakes that I made during my internship.
The Perspective
The most valuable thing that a junior developer can do is to show up, be engaged and be yourself. That's it. That may not sound like much, but the things that happen when they're engaged can be truly beneficial to the team and the project they're working on as a whole.
The biggest thing that junior devs bring to the table when they're engaged is a fresh perspective. When you're in any industry for a significant period of time, it's pretty easy to get cynical. I actually think that cynicism is particularly valuable in software, but it can become a problem if it is the ubiquitous mindset on a team. Juniors haven't accumulated enough experience or baggage to become cynical, and will often have a sense of optimism (some might call naivety) that probably isn't shared by many others on the team. Maybe that optimism or naivety isn't valuable in it of itself, but it's helpful when it comes to bringing ideological balance to a team.
Not only that, but that kind of optimism brings a certain level of flexibility to a team. It's super easy to waste the time of a senior developer. If they do some piece of work and it doesn't pan out as anticipated, a senior developer could easily turn around and say that their time could have been better spent elsewhere. This creates an aversion to experimental and potentially nebulous pieces of work. Junior devs don't have this problem. It's incredibly hard to waste the time of a junior developer, so having them work on stuff that's a little bit more risky is a win-win for the team. Worst case scenario, the junior dev will have a positive learning experience. Best case, something new and different will get brought into the team or project; something that probably wouldn't have made it in if you didn't have a junior dev there to do that work. That right there is enough to make junior devs valuable.
The Status Quo
Junior devs are also in a unique position to be able to challenge the status quo of the team that they join. The obvious reason for this is that the status quo doesn't apply for them because, well, they're new. Not only are they new to the team, they're new to everything, which makes them doubly effective at this.
One of the big ways that the status quo can often get challenged on the team is by people asking, "Why"? Asking why is dangerous, because sometimes, there isn't a very good answer. This is conjecture on my part, but I'm willing to bet that most teams are doing something in-optimal. Whether it's in code or in process, there's always something that can be done better. There are a couple of possible reasons for this. One is that the team isn't aware that they're doing something in-optimal. This kind of assumes the worst though, and when the why question is asked in a way that makes this assumption, the person asking probably won't make many friends (so don't do that).
The alternative, which I've found to be the case most of the time (during my six months in the industry), is that the work to make things optimal isn't prioritized very often. You did some work to get a feature out there, and to make it work you had to cut some corners. The team knows there's a better way to do it, but the feature is out there, so the work needed to fix it gets moved to the back burner in favor of new features. Once people get used to working around the fact that this feature wasn't implemented in the best way possible, the work to fix it becomes even less important than it already was.
As long as the person asking isn't being an ass about it, the why question can bring much needed attention to decisions that led to an in-optimal process or piece of code. It can also be useful in determining whether any logical decision making went on at all. Maybe the answer to the why question is nebulous, "Well, that's just how things have always been done." As I write that sentence, I realize that I've said this to a new hire within the last week. So it definetily happens, and when it does, that's probably an indication that something is up.
Junior developers aren't the only ones that can challenge the status quo this way, anyone can really. New hires are also in a great position to do this kind of thing. But, junior developers are probably going to be asking more questions than anyone else, so I think that that makes them particularly good at this.
The Code Review
Having junior devs do code review is also a win-win situation. Worst case, the junior dev doing the review asks a bunch of questions about what's going on and get's them answered. Great, they learn some new things. Best case scenario, they end up making the codebase significantly more maintainable.
Maintainability is obviously very important in any codebase. I think code complexity is one of the biggest blockers to a codebase being easily maintainable. If they're bold enough, junior devs can be a great check on code complexity by inserting themselves into the review process. Over-engineering is a thing, and if a piece of code flies over the head of a junior dev, it's probably not going to make it into the codebase without being simplified. By inserting themselves into the review process, the junior dev has basically created a bar of complexity that the code is allowed to reach.
This can obviously be abused, but as with anything, there's a balance. Junior devs need to be bold enough to participate whenever they understand a piece of code and are aware of a simpler way to do the work, but not arrogant enough to block any pull request that they don't understand. As long as the junior devs in question are balanced, they can be a great tool for keeping things simple and readable.
By keeping your code simple enough for your junior devs to understand, not only are you doing them a favor, you're doing a favor for everyone on your team. In fact, it's even more than that. Projects and teams are fluid over time and maybe one day, some other team be working in your codebase. Would that team rather be reading through code that only senior developers could understand, or would they rather be reading through code that a junior dev could understand? My money is on the latter.
The Conclusion
What I've been trying to say throughout all of this, in a very long-winded way, is that junior developers matter. I didn't recognize this during my first couple of months as a junior developer, and ultimately my team and I were worse off for it. If a junior developer can embrace their role rather than resent it, they will ultimately be able to act as a building block for the rest of their team. Then, in a year or two, as everything settles down, maybe another new dev will join the team, and cycle will continue. The team will continue to grow, the new developers will grow and the entire industry will prosper as a result.
So, if you're a junior dev (or about to be one), don't get in your head, and understand that you bring something truly valuable to the table. If you're a senior, make sure that your juniors hear it from you, I'm sure it'll be far more meaningful coming from you than another junior dev on the internet.
Top comments (0)