As a junior developer, it's often difficult to feel useful: you are dependant on others giving you tasks, while simultaneously relying on them to help you complete those tasks. I have learned a lot about this conundrum in my time as both a junior developer experiencing precisely that, as well as as a senior developer seeing it happen. In this post, I will cover my learnings on how to excel as a junior dev from day one, and outline the steps I followed to overcome the challenges thereof.
I remember my first day as a junior developer quite clearly: It was at a small startup, and I was the first person they formally hired. I came in, greeted my bosses, and sat down in front of my new laptop. After some pleasantries, my team-lead came to sit with me and started laying out my task for the day. But as he spoke, words were rolling-off his tongue that made no sense to me whatsoever. When he asked me if I understood, I said yes (I obviously didn't), and I sat Googling for the next few hours. A little while later, when he came to check up on me, I had accomplished nothing.
I realised then, that what I had learned through online courses did not prepare me for the challenges I would face working in the real world. Luckily for me, my team-lead would eventually take me through exactly what he wanted, and I was able to finish the task. However, as I've progressed in my career, I've seen juniors making the same mistakes I did - and a lot of them are totally avoidable!
Below is a list of what I have learned through my career; although mostly aimed at new developers, I also cover what more experienced developers can do to help their juniors.
Be comfortable to ask questions that make you feel "stupid"
Later on in my career, I moved to working at a development house because I was looking for a new challenge. On my first day, I was pulled into a meeting room where a senior dev explained my first task. Once again, his explanation left me dumbfounded. I left the room without asking any questions and, instead, used Google as my retribution. I got nothing done, felt completely inadequate, and my "imposter syndrome" kicked-in.
Looking back, I could have avoided the embarrassment of ending the day empty-handed if I had just stopped the senior and asked what I thought were "stupid questions," like an explanation on some phrases and a clarification on the task.
Whether you're a junior or a senior, you are never expected to know absolutely everything. After-all, software development has a number of complicated domains: From databases and frameworks, to design patterns and best practices, it's easy to feel lost as a dev sometimes. As obvious as it seems, not being afraid to look ignorant and ask questions is the quickest way to gain an understanding of the subject, and learn something new.
Learn to work in a team
Although it might feel like it, your coding ability is not the only thing a company looks for in a developer: The ability to work with, and teach, your team is just as important as your ability to produce code: By upskilling team members, you help the entire team do a better job, and not just the person.
I arrived a little earlier on my second day of the new job and went for coffee with a developer that had been there for a bit longer than I had. After feeling a bit more comfortable, I opened up about feeling like I didn't know what was going on and, instead of helping me, he made fun of me, acting shocked and amused by my lack of knowledge.
Ashamed, I snuck back to my desk feeling like I should just beg for my old job back. Another developer noticed I wasn't happy, and asked how my day went the day before. Although I said it was OK, he could tell I was lying. Instead of mocking me, however, he pulled me aside and started teaching me about the platform. He taught me about the value that working in a team has for the "bigger picture."
I've found that the quickest way to deal with an less experienced team member is to focus on helping them rather than ousting them. As a team, you rely on one another to produce quality work. A team with mutual respect and professionalism for each other will always outperform a team of arguing developers.
Get a mentor
At one point, I had been struggling with a difficult problem for hours and plucked up the courage to ask a senior developer for help, one that I hadn't really spoken to in the past. I quickly latched on to them and started spending more coffee breaks, lunches and coding sessions asking them questions while observing their work. Eventually, I decided to ask them if the would be ok with helping me more regularly.
By doing so, my skill level and understanding grew exponentially. Not only this, but I also asked fewer questions, and started to enjoy solving problems on my own. I would try solve a problem to the best of my ability, show them my work, and they would provide feedback on what they liked, didn't like, and how they would improve my solution. Before long, I was spending less time at their desk and more time at mine.
A great way to find a mentor is by spending more quality time with your team. Coffee breaks, after-work activities, or even just water cooler chat can be a great way to become more familiar with the senior people in your team. If this doesn't sound like your cup of tea, or you work in a small team, finding a mentor online is also a great way to learn from someone. Personally, I follow Kyle Simpson. I try watch all his talks, and consume most of the material he produces through online courses or blog posts.
The ability to get your work critiqued by a senior while learning from them is invaluable. You will learn how to critique a peer's work, grow thicker skin, and improve your coding ability as you learn more complex problem-solving techniques.
Know your worth
A year in, I had become extremely proficient at delivering features on time while keeping the quality of my code high. Thus, I decided to take what I thought was a risk and ask for a raise. It was the first time I had ever asked for one, and the thought of it made me feel a bit sick. Regardless, I went into the office, letter in hand, started my negotiation and left with a raise.
Now, to be clear: I'm not saying that you should ask for raises on a regular basis. Unless you are extremely lucky, your boss does not wake up every morning and plan to pay you more!
But if you are given more responsibility, feel like you have been out-performing your role, or have been on the same salary for a few years, you might want to start thinking about approaching your boss. Even though knowing when you've outgrown your role could warrant its own blog post entirely, when you do feel the time is right for a salary negotiation, be confident; most bosses and/or managers will know your worth. Often, as a junior developer, you are either too scared or assume your boss will give you a raise when you deserve it; but this is not always true.
You should take time to learn what your skill set is (what technologies you are proficient in and what role you fill in the team) and match it to what the industry is paying developers with similar skills. Resources such as Glassdoor, Payscale and anonymous salary sheets are a great way to find what developers with similar skill sets are earning.
Build a side project in the technologies you are using
Creating side projects in the technologies you are already working in is a great way to develop a deeper understanding of the system - especially the parts that you might not touch on a day-to-day basis. After spending some time developing in popular frameworks at my job, a friend and I decided to build our first side project. What we didn't expect, however, was what it would entail.
The difference between working on an existing project and setting-up your own project, is the same as the difference between amending a chapter and authoring a book: I quickly realised that although I could easily add features to my existing projects, I had very little experience in setting up new projects. We needed a better understanding of the framework before we could progress.
In order to achieve this, I had to put time into research and learning, which really helped me with the core understanding of the technologies I was using. My feature turnaround time and bug-fixing skills quickly improved as I began to understand the flow of the framework and where the various concerns lived within the codebase. Having to setup and connect the database, routes, controllers, services and views was something new for me. Having to do them myself really helped me see our projects from a more holistic viewpoint.
I've found that the best way to avoid being overworked is to partner up with like-minded developers. This helps to split-up the workload and time, while keeping each other honest with the work being done. Before long you will have a working product that you have learned from, and you can now use as a way to show future employers what you are capable of.
There will never be a "silver bullet"
All of that said, though, I wish I could tell you that following the steps above will mean your journey is going to be a smooth one. Starting out in the software industry is daunting, and you are bound to face many challenges along the way - not just what I've spoken about. What I have covered is simply what I think are important learnings to help you excel.
If you are able to effectively ask questions, work in a team and receive mentorship, you will quickly become a valuable player to any company. Knowing your worth and building side projects will also help you upskill yourself, and improve how you view your own self-worth. If you can become good at those things, then you'll be ready for any other challenge that gets thrown your way!
"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay
Useful links:
-
Glassdoor - https://www.glassdoor.com (company review and salary)
-
Zatech - https://zatech.github.io (local community, mentorship and salary)
-
Pluralsight - https://www.pluralsight.com (upskill and mentorship)
-
PayScale - https://www.payscale.com/ (salary review)
Noel Kriegler is a South African software developer who grew up in Cape Town, but now resides in London working for Brolly (a personal insurance startup). He has worked in a wide range of teams from small startups, to bigger corporates in South Africa, and believes that everyone should learn to code. (Why not? It's fun!)
