My advice to a new Junior Frontend Developer

Two months ago, I started my first engineering role as a Junior Frontend Developer. So far, it has been everything I thought it would be: exciting, stimulating, challenging, and with lots of learning and growth.

In this post, I reflect on my journey settling into my new role and key takeaways I've learnt during this time. I discuss:

• Getting comfortable with being a junior as a career-changer

• Communication in a remote environment

• Getting comfortable with tooling

• Developing programming skills such as pseudo-coding and reading code.

The beginning

I don't come from a traditional CS or tech background. In my 'previous life,' I was a Science Editor concerned with communicating science using accessible and inclusive language in women's health. Making the switch to a field almost entirely unknown to me was intimidating, to say the least. However, after a part-time Bootcamp and lots of self educating, I was lucky enough to land my first Junior Frontend Developer role seven months later. My confidence was boosted - for the moment at least!

Being a beginner all over again can be a scary place to be. But with the support of highly talented and encouraging colleagues and the right learning mindset, my transition into the engineering team and company was very smooth.

I was provided with a clear learning roadmap and the opportunity to get stuck right in immediately.

Working in agile sprint cycles, I got the opportunity to dive right into fixing bugs. Adding new features and enhancements to the company website within my first two months. In an attempt to capture and reflect on all the things I have learnt in this short period, here are some of the key learnings I've made in the last two months.

Allow yourself to be a beginner

Central to being a junior is the space to make all the small stupid mistakes you can think of. Go ahead and make as many of these now! You'll find that most of your colleagues are patient and eager to help you develop.

Make the most of being at this level. Ask those obvious/stupid questions.

Even if you think you vaguely know the answer, ask anyway and get clarification. It's better to have asked and received an answer than to maintain gaps in your knowledge, which will only increase with time, creating problems for you in the future.

Communicate, communicate, communicate

An excellent approach to communicating correctly is to try to over-communicate. Communicate everything you're working on, share progress, and reach out to fellow colleagues when you reach a blocker and need help.

At Elsewhen we have daily morning standups, in which we discuss what we're each working on, any challenges or blockers that we may be facing, and the following tasks we're planning to pick up. These morning briefings serve as a great communal accountability activity. It allows a structured approach to problem-solving and encourages colleagues to step in to help or advise on time-consuming or complex tasks. I found it extremely useful in helping direct my focus and keeping track of my day-to-day tasks, including recognising achievements and highlighting areas for improvement.

Other communication tools I commonly use include Slack, Github Project Boards, and Figma. Slack provides various communication methods to suit your preferences or for when you just want to switch things up a bit. It can get a bit mundane using the same format all the time.

Remote working can come with many challenges, particularly when it comes to communicating with colleagues. You no longer have the option to just turn around and ask the person behind you a question or bump into someone while making tea and just have a chat. Many of these natural interactions have had to be created by scheduling meetings, making them feel more enforced.

Tools like Slack make it easy to communicate with colleagues daily via messaging, video, or audio calls with screen shares when discussing work and sharing different media formats. I also find Github Project Boards and Figma very useful in documenting comments for particular work projects. The comment functionalities on these tools help record conversation trails that can be easily accessed for all the team to keep informed.

Making time for training

When I first accepted the offer as a Junior Frontend Developer, the plan was to spend most of my time training and learning by working primarily on the company website before progressing to client projects. Before starting, my new manager and I had discussed plans to put a learning roadmap to help guide my learning and development.

I would encourage every junior developer to chat with their managers/senior colleagues about putting a structured learning plan in place. It helps track the trajectory of learning and development and manages the overwhelming amount of possible content that is out there to help you learn.

Although I had a learning roadmap to follow, I hadn't considered the time for training once the sprints had started. The suggestion to block some time for training actually came from my project manager. Like many junior developers, I was keen to get stuck in writing code. As much as getting stuck right in is potentially satisfying, blocking time out to continue learning and development is just as important. After all, an essential part of being a junior developer is making sure that this period is spent building a solid understanding of the programming fundamentals of the requisite language(s).

There are also great online resources that provide industry-standard learning pathways, such as the Frontend developer roadmap from Developer Roadmaps and structured courses. At Elsewhen, engineers are supported with an annual learning budget to support their development, including subscriptions to leading course providers such as Frontend Masters.

Find the right setup

Customising engineering tools creates more productive workflows and makes for a more pleasant experience for us as developers. After all, writing code shouldn't be a daunting process. It needn't be complicated and can even be fun.

Searching for the correct setup online can be overwhelming. I'd suggest starting small - by approaching fellow colleagues and finding out what they use. I reached out to my manager, who pointed me towards some resources to help me get started.

Configuring the default terminal

The first time I opened the terminal on my laptop, a blank screen with a blinking cursor stared right back at me, and I had no idea what to do!

The terminal can be a scary place to be, yet it is an essential part of a developers workflow so getting comfortable with it is really important.

During my Bootcamp, I learnt enough command line to navigate the essentials. However, up until recently, I had only used the default macOS terminal. So when I was introduced to the iTerm2 terminal, I was pleasantly surprised by some of its great features: autocomplete, the ability to search, easy readability, and navigation - especially when working with git branches. I also configured my command line to Zsh. I added the Powerlevel10k theme, which allowed me to personalise my terminal - making it faster and styled to ease navigation. As developers, we spend a considerable amount of time working on our terminals. It's only right we set it up for a smooth experience.

Setting up the code editor

Together with the terminal, your code editor is your home. A lot of time is spent here writing, editing, and reading code. Most importantly, a lot of debugging happens here, so easy navigation between and within files/folders and code readability is crucial. This is where choosing and customising an editor to create the perfect environment for your workflows is essential. This includes installing various extensions like prettier and ESlint, which makes writing code and debugging easier.

There are loads of options available out there. Again, I suggest approaching colleagues or searching in developer forums for recommendations. Just bear in mind that you don't want to lose too much time on this, as getting a basic customised environment that eases your daily workflows is enough. With time you can add further personalisations such as themes/colours etc.

Get comfortable with Git ​​

As a junior developer, if one thing is etched in our training, version control systems like git are essential. Git is everything! And the more comfortable you are with it, the more confident you are working with it in projects.

There are basic git commands that junior developers are expected to know how to use correctly. These include cloning a repo, creating a branch, committing and pulling requests, etc. Although I was familiar with some of the core git concepts, some commands - like the infamous git rebase - required a refresher and some help because I hadn't applied this command before. Knowing git is an essential first step, but understanding and using it correctly is a skill beyond reading about the different commands and knowing what they do.

Make sure you are comfortable knowing what's happening under the hood with these commands. If you're not entirely sure how to run a particular command, reach out to someone senior and confirm it with them. It's better to catch any errors at this point rather than messing up, or worse - deleting the codebase. You really do not want to be that person!

There are plenty of resources on git, including an excellent course breakdown of git on Frontend masters by Nina Zakharenko.

Reading > Writing

I feared I would get the developer's equivalent of writer's block and not write any code when I first started. The following weeks and months later, I quickly learnt that far more than just writing code, I would be spending more time reading code. To solve a problem, you must identify the causes before anything else. Firstly by examining the existing code, and secondly by figuring out a solution that will integrate well (which involves reading a lot more code to see how it all interplays).

Luckily, the hard work has already been done in most cases, so it's a case of reimplementing existing logic in a different context. But to understand this well, you must first become familiar with the codebase, understanding what each line of code is doing. If you don't understand it, reach out to a colleague and ask for a few minutes of their time to help you know. This goes a long way!

Reading code also allows you to get familiar with your colleagues' coding styles and become more familiar with the programming language. While training in typescript, I didn't feel comfortable with the language enough. However, seeing it implemented in the codebase, I was better able to appreciate and understand what was happening and why it was being implemented.

Pseudo-code

Coding may come across as a daunting process. A blank editor may seem like a scary place to start. This is where pseudo-code comes in. Pseudo-coding is the art of turning a problem into code without actually coding. How does that make sense? I hear you say. Bear with me. I recently worked on adding a minor new feature to the company's website homepage showcasing featured videos. To break this task down, I identified the following logical main steps:

1. Fetch videos with metadata

2. Determine featured videos by identifying relevant tags in metadata

3. Pass video information to existing video tile component

The most challenging part of coding is primarily complete by breaking the problem down into smaller subtasks: identifying the coding logic. All that's left after this is replacing the pseudo-code with the syntax of the programming language being used.

Here are some of the top benefits I've found with pseudo-coding:

• Helps direct focus - when you know what you are solving, it becomes easier to direct all your focus on all of the parts that need to be considered.

• Track and measure progress easily - bugs and features can be pretty meaty. It helps to record progress and the steps you've attempted so far, allowing you to track how much of the work is done and what is left. This is very important to know how much time and work there is left and in total.

• Gain a better understanding of the problem - problem-solving is all about breaking down a problem into the smallest possible constituent part. Understanding how the smallest parts work provides a clearer picture of the larger issue at hand.

Wrapping up

To recap my journey in the last few months:

• I've gained more confidence starting out as a junior

• Learnt how to strengthen my communication skills, mainly working in a remote environment

• Learnt the importance of blocking time for ongoing training - learning and development are part of the job!

• Become more comfortable with tooling and setting up a productive workflow

• Become better at reading code and discovered the benefit of pseudo-coding when writing code.

These are just some of the key takeaways I have learnt as a junior frontend developer in the last two months. You might be surprised that I have not included a list of all the technical skills I have been learning. Yes, technical skills are essential. After all, it is core to the work we do as developers. But I've learnt that that will develop along finely and fall into place once the right mindset and soft skills relating to how you work are cultivated from day one.

If you're a junior developer starting out your journey, I'd love to hear from your experiences so far - what has worked/not worked for you? What are your key takeaways?

Likewise, I'd also love to hear from those of you more experienced - what main lessons do you remember from your time as a junior developer?

Let me know on LinkedIn or via Twitter