On occasion, as part of my role as one of the organisers for JuniorDev Melbourne, I have been asked to provide some advice to up-and-coming developers on how to navigate their junior developer journey.

Since I'm approaching five years of being paid full-time to write code for a living, I thought this would be the perfect opportunity to write about what I've learnt during my formidable years as a junior developer at two companies (more on that later).

I should stress that what I've written down are not the lesson every junior developer experiences. Each junior developer will have their own unique experience. These are the lessons that I learnt on my journey and what I did. If you encounter something similar during your journey, then I hope that what I did helps in some way.

Lesson #1: It's very easy to burn yourself out

Like all industries, there will always be some level of pressure when working as a developer. Everyone's level of what is an "acceptable" amount will differ.

But everyone does have a breaking point.

There will be days where you feel emotionally drained; where you don't want to get up and go into work; where you rather hide in the toilets to get a five-minute break away from reading logs before putting on a fake smile and dealing with the next issue.

Sometimes the feeling lasts a day or two; sometimes it can last even longer.

But either way, it is burnout.

You don't have to be in a toxic workplace to reach your breaking point. It can be as simple as being in a constant repetitive cycle with a lack of variety - such as working on new features or roadmap islands.

For me, there were a couple of times where I felt burnt out after being in a long cycle of bugs being reported, then for us to issue a fix, only to have another bug reported. And if there was a critical bug that landed within that cycle, there was added pressure to resolve it at a break-neck speed because you want to minimise as much loss in your employer's reputation and revenue.

(On a side note, this is why I am super thankful to all QA people in our industry - they do the hard work to ensure we're not stuck in that particular cycle of despair.)

This section feels quite apt given many people are now working from home because of a pandemic, and the clear line between work and home life is now blurred. It's very easy to fall into the trap of working even longer hours - even if your employers have outrightly said that you shouldn't do that.

And yes, I have fallen for that trap too.

If you need to take a break, take a break. Back when we had an office, during the pre-COVID days, I would get outside and take a coffee break (and, if I didn't want coffee, get a hot chocolate instead). I used the walk to my favourite coffee shop to clear my head, and made small talk with the barista and talk about anything other than what I was doing at work. If my colleagues were there, we'd also talk about their side projects or what they did that weekend. Just anything other than shop talk.

But if you feel emotionally drained or burnt out - take some time off. If you have some annual leave, use that to travel somewhere (if you can - please don't break lockdown rules). You might feel guilty about putting on additional work on your colleagues, but do not let that stop you from using your leave. Put your well-being first.

Lesson #2: Sometimes, growing means doing something scary

I find public speaking absolutely terrifying.

Every single time when I have presented a talk or acted as an MC for an event, I go through the same routine. I'm anxious and twitchy. I feel my heartbeat fast, my throat dry up. In my head, I envision the many scenarios on how I could fuck it up and say the wrong thing, or embarrass myself by saying off-key.

I hate the sound of my own voice, and I still cannot watch myself presenting without cringing. I notice my flaws instantly - perhaps I shouldn't have worn that shirt to that convention, or I should enunciate my words better.

Turns out, I'm not alone. A 2014 survey done by Chapman University found it was the most common out of their respondents - with a quarter of them saying they feared speaking in front of a crowd.

Despite the fear, I still push myself to do it.

And I love it.

I could say it's for career development - and that's partially true. It's the easiest way to stand out amongst your colleagues - especially since, according to one author, it's done so badly that it is "an easy place to shine". And according to this BBC article, if you want to move up the ranks into some form of management, public speaking is no longer an optional requirement for your professional life.

The main reason is more selfish: I just want to travel more - and in a way that doesn't break the bank account since travelling internationally from Australia is super expensive (especially when you factor in currency conversions). So why not be one of those developers that get invited to speak at conferences.

Of course, I am not expecting it to be an overnight success. It takes years to build up a profile and get noticed, and you have to do a lot of conference talks - according to some of my friends who do this for a living. But you have to start somewhere - even if your public speaking experience includes an incident in high school where I managed to screw up a small announcement by reading it so fast and so mumbled that no one could understand me.

In 2019, as a New Years' resolution, I said that I would do more public speaking opportunities. And before a pesky pandemic put a halt to my plans, I was pretty happy with what I managed to achieve - starting small, local, and with what you know.

As such, I did several talks about React Native at several conferences and meetups - including DDD Brisbane and /dev/world in Melbourne. I also managed to convince a conference in Tokyo - DevRelCon Tokyo - to let me speak about hackathons. Other opportunities also included hosting a panel at DDD Melbourne, and being an MC at YOW! Melbourne (for two sessions) and a hackathon.

I haven't fully dived back into public speaking at conferences this year since I reorientated my priorities slightly. However, that doesn't mean I've fully dropped it as a goal. I am still doing little bits here and there. For example, I recently did a lightning talk within my team at Atlassian.

But to the same extent as what I did in 2019? No.

Though, next year? Maybe.

Lesson #3: It goes both ways

When I speak with recruiters, I always made sure it was a two-way conversation. Yes, I have the technical skills that you want, and can "fit" with your company culture. Yes, you can give me this amount in salary and these perks.

But I'm more interested in how I can grow inside your company. Most importantly: how can I grow into becoming a better developer; and how can I grow to become a senior developer.

As a junior or someone just entering the industry, you should be looking for a place that helps you become a better developer. They should have a plan to make you reach the next career milestone. Their working environment should be nurturing and supportive. And they should at least give you a corporate buddy to navigate your way around the office.

Basically, what I'm saying, it should be the opposite of where I went for my graduate role.

In hindsight, I should have seen it from the beginning. There was a lack of communication or coordination. I had zero support system when I first joined, and when I first joined my team (three weeks into my role) I felt more like a burden to the team than being part of one since I was effectively placed in a corner and "build dashboards".

Being a junior, I didn't voice any of my concerns. I thought it was better to shut my mouth and continue doing until I get rotated out. This turned out to be a huge mistake, and I stress now to all junior developers to always voice their concerns as soon as possible so you can rectify them.

However, I did ultimately find my way into having a support system. A couple of senior developers in my team noticed I was struggling and reached out. Without them, I wouldn't have been able to build my confidence and get the right mentoring to become a better developer.

Ultimately, the reason why I left was that I felt they weren't interested in helping me become a better developer. They pushed me to be in an entirely different field even though I told them that I wanted to be a full-stack engineer. I also think they were happy to keep me stagnating if it meant they can still pocket the difference between what they were paying me as a salary and what they were charging me to their customers.

So naturally, there was only one thing I could do.

I had to leave.

If I stayed at the boutique consulting firm, I knew I would be miserable. I was in a role that I did not want. The friends that I had in the company had already left or were making plans to leave. And I disagreed with the company's direction - to put simply: it was the opposite of what made me apply to be a graduate.

I also knew that if I left the company, I would effectively be restarting my junior developer journey again. Not many people jump from a junior role to another admittedly junior role at a startup.

However, if it meant that I get to be where I wanted to be - a software engineer - then so be it.

I was lucky that I found a company that not only took a risk on me but also allowed me to grow and gave me the necessary support to become a better developer. They were also super accomodating with my community work with UNIHACK and JuniorDev Melbourne.

Now, admittedly, I only got the job because I also knew some super talented developers at said startup. But without their references, I wouldn't have joined and had the best three years working there.

As I said at the beginning, everyone's junior developer journey will be different - and each one will encounter different challenges as part of that journey.

If this blog post did help, feel free to let me know by sending a message on Twitter. And if it didn't but still need some advice, my direct messages are always open. Alternatively, you can reach out on the Junior Developers Slack community where other junior (and not so junior) developers can help.