DEV Community

loading...

Becoming a Junior Developer

Greg Thomas
I write a lot of code. I've also written a book on developers becoming leaders/managers called Code Your Way Up.
・4 min read

That title might sound a bit weird. I've been a junior developer, have hired and lead many junior developers and when thinking about it, you don't start out as a Junior Developer but rather at some point become quite good at it that you keep growing.

I.e., in having setup coop and intern programs, I wouldn't classify all of these students as Junior Developers but as Coops and Interns - they are in a different stream varying greatly from that of a Junior Developer.

When I look at what it takes to become a solid Junior Developer that is contributing to the team, delivering, and growing, here's what I generally think of.

My First Developer Job

I was one of 6 developers in a small App Service Provider building e-commerce websites and applications. I was the newest and greenest developer. I had just graduated from university with a BCom where I supplemented my income with coding contracts that lead me to wanting to be a software developer full-time. I taught myself everything - JavaScript, HTML, SQL, Cold Fusion (not much right, BUT it got me in the door and that was key).

Start Small

I remember during all of my various job applications, it was the small companies that were getting back to me over the big ones. Perhaps I wasn't good enough or didn't have that safe "paper" they wanted. Regardless, going small was the BEST decision, because through working with smaller companies, I got to touch a lot more. Over the years I've heard the same thing from Coops and Junior Developers that we have hired that have said the same thing - we do more with your team in a month than we did with a large team over the last four months. The bonus here is that small companies will always need extra hands to get projects done so the amount of new stuff you can touch is unparalleled.

Read Everything

Whatever you are working on, you know the industry, and after a few weeks, you know what your team is using - Node, React, Angular, C#, AWS, GCP, Azure, etc, etc - you know the platforms and the big heavies that are in use. In my case, we were using ASP and some early days CSS and were just starting to get into Java and .NET. I wasn't being asked to work on any of these projects (YET) but knew that if I wanted to get onto them, I'd have to learn these technologies on my own. So I did, I spent time with copious books and blogs figuring out what was and prepared myself for what I wanted to get into.

Volunteer for any Project

Yes, volunteer.

If you see a new project coming down the pipe, put your hand up.

If there is a problem in the latest build, put your hand up.

If there is a process that is taking too long, put your hand up.

This isn't saying that you will have to be the one and only person to solve the problem, but you will be the one that is now running with it. What I always find is that the rest of the team is always happy to help the person who volunteers to own and run with a problem. I volunteered for problems I had no idea how to fix (corrupt logs, broken javascript, dll mismatches) - things I had no idea how to fix, but by volunteering to do them, they gave me more opportunities to talk with more of the team and grow.

Grunt Work

It was at least six months before I started getting projects and features to run with on my own. For those first six months, I was doing bug after bug after bug, I got all the work that no one wanted to do, I got the Grunt Work.

Not the pretty work, or the cool work, but the monotonous and painstaking work that needed to get done.

That's okay, embrace it. Through doing that work I was able to suggest changes in code that would prevent us from ever doing this grunt work ever again. Translation: I found a way to save us time that resulted in the bugs never having to be dealt with again that enabled me to get better Grunt Work to work on.

Keep it Humble

You get to the point as a junior developer where you think you are too big for what you're doing. Maybe you have reached that final apex, but from my own experience and from what I've seen, we all think we've made it far too early. I had a number of humbling moments where I accidentally overwrote a customer's site or took down a server. It's life, it happens, if it doesn't, don't worry, it will.

The key is to admit when you've made a mistake and work with the team to figure out the solution. You're not alone, you might be the only junior on the team, but you've got a team and/or a community to help you, but not letting your head swell up is key to being successful.

You'll figure out the technology, the patterns, the languages, the syntax, the best way to catch errors, performance and everything else along the way.

I wrote a book about being a Developer and Leading Software Teams - Code Your Way Up - available as an eBook or Paperback on Amazon (CAN and US).

Discussion (0)