Avoid these 7 mistakes I made as a Junior Developer
Beginning your career as a junior developer can be scary. There will be many unknown challenges, things to learn, and difficult choices to make. And sometimes, we get these choices wrong. It’s only natural, and we shouldn’t beat ourselves up when it happens.
What we should do though, is learn from this. As a senior developer, I’ve made my fair share of mistakes. Here are the 7 big mistakes I made when I was starting out as a junior developer, and how to avoid them.
If you’re teaching yourself to code, or coming to the end of your university degree, getting your first job will be one of your main goals. It’s the light at the end of a long tunnel.
And getting a job is not easy. There are more people than ever trying to get junior developer jobs. You need to write a killer CV/Resume, make it through many rounds of interviews, and the process can take forever.
Which is why it’s understandable how tempting it can be to jump on any job offer you get with both hands.
Yet, this can be a bad move. My first job was far from ideal, from a learning and enjoyment perspective. The developers had a “meh, it’ll do attitude” and often did things half-heartedly. There was a culture of blame, and I was often required to cut corners to meet tight deadlines. Worst of all, I wasn’t learning anything.
I ignored the warning signs in interviews because I was blindsided by the opportunity of getting a job. Any concerns I had were thrown out the window when I received the offer with a**nice salary to boot.
Your first job is important. It gives you a taste of being a true developer, and the experience and mentorship you receive will set you up for the rest of your career. Which is why you should thoroughly do your research on the role and the company before accepting any job offer. The last thing you want is a bad experience or bad mentors!
So, before applying or accepting any job offer:
Search for the company on glassdoor, the internet, their website, and read the reviews. This will give you a good feel for if the company is suited to your goals and needs.
If anyone in your network has worked there or knows anyone who works there, have a chat with them. Find out what they like, what they don’t like, and generally what their experience was.
The interview is the best chance you have to learn about the company, so make sure you come armed with a set of questions to ask the interviewer. A few things you can ask are:
- Ask about the development process (what methodologies do they follow? Do they do code reviews? branching strategies?)
- Ask about testing (what sort of testing do they follow? do they have dedicated test engineers?)
- What is the culture like (is it a relaxed environment? what is the support like for junior developers?)
No doubt the path to becoming a fully fledged developer can be a confusing one. There are many languages, frameworks, and tools available. A mistake I made at the beginning was trying to learn everything. Funnily enough, I ended up not learning very much.
One minute I would try and learn Java, then JQuery, then C#, and then C++ …
Instead of focusing solely on one language at a time, I was jumping between things depending on how I was feeling that day. And trust me, that is a very ineffective way to learn.
So narrow your focus, choose your path, and create a plan to become a pro in your chosen path (here’s a roadmap that will help you map out your path)
So you’re preparing a project to show the interviewers, or landed your first job and working on your first task. You are trying your best to impress. What’s the best way to do that? Show off this super fancy coding technique you learned to complete the task, right?
This is a major mistake I made and a mistake I see junior developers do too often. More often than not junior developers will try and reinvent the wheel, or use some complicated solution in a bid to try and impress.
The best approach to writing code is the K.I.S.S principle (“keep it simple, stupid”). By keeping things simple, you’ll reap the benefits of *easy to read, maintainable code *(the next developer coming along after you will appreciate it!).
An early bad habit I ran into was not learning to switch off. I would often bring my laptop home with me at the end of the day. I would sit for hours trying to complete a task or bug that could have waited until the next day. This unsurprisingly, left me feeling burnt out and stressed.
Part of the reason I did was this because I felt an urge to complete everything as soon as possible. Whereas, in reality, I should have realized that work is an ongoing process, and it can more often than not wait until the next working day. It’s important to switch off and remember the other things in life. Friends, family, hobbies, and having fun. Of course, if you like to stay up until the early hours writing code, by all means! But when it is not enjoyable, consider stopping and doing something else.
There is always tomorrow!
It’s easy to get stuck on a problem or task you are trying to complete, it happens all the time, even to the most senior developers. A mistake I made whenever I was a junior developer was not saying “I don’t know” enough. If management asked me a question I wasn’t sure about I would bluff an answer instead of saying “I don’t know”.
I felt if I said “I don’t know” people would think I didn’t know what I was doing. The reality is that this is not the case. Nobody knows everything. So if you’re asking a question and you don’t know the answer, say that. The benefits of this are:
- You’re being honest and not misleading the person who is asking the question
- You’ll learn something new when it’s explained to you
- You’ll gain respect for saying you don’t know something. Not everyone is capable of admitting they don’t know something.
I’m sure you’ve heard the saying, “you have to walk before you can run”. Never does this saying have more relevance than in the field of web development. When you start your first job as a junior developer, you’ll be eager to hit the ground running, and get your hands on nice big coding tasks. You’ll even be thinking of how to get a nice promotion to the next level!
Whilst ambition is good, the reality is that these sort of things will not come straight away for a junior developer. At the start of your career, you will more than likely get the smaller, easier tasks and bugs to work on. These might not be the most exciting things in the world to work on, but it’s necessary. It allows you to put one foot into the codebase and get familiar with the process. Secondly, it allows your team and managers to gauge how you cope with working as part of the team, and where your skills lay.
I made the mistake of getting frustrated at these smaller tasks, and I let this frustration get in the way of my work. Have patience, perform every task you get to the best of your ability, and the more exciting work will come!
The development community is great. The community is always willing to help, provide feedback, and can even help with motivation. Being a developer is tough, and can sometimes take its toll. As a junior developer, the tough times would have been easier if I had got involved in the community earlier.
Getting involved is also a great way to learn. You can contribute to open source projects, see how other’s write code, and see how developers collaborate on projects together. These are all skills you can bring to your day job and will make you a better developer in the long run.
Find communities that interest you — freeCodeCamp, CodeNewbies, 100DaysOfCode are some good ones — and get involved! You can also get involved in local meetups in your home town or city. Check out meetup.com for this.
This also lets you **build a network. **A network is basically a bunch of people you know in your industry. Why is a network important? Let’s say you are looking to move into another job. By reaching out to your network, someone may be able to recommend a specific role, or even refer you to a company. This gives you a solid advantage going into the interview, as you’ll have someone to vouch for you, and will no longer be another “name in the pile of resumes”.