Advice to a Junior Developer

This is the next instalment in a series of articles offering advice from the members of the Capgemini Microsoft Team to Junior Developers. The advice I give in this post is applicable to any member of a typical software delivery team.

My personal experience has given me the opinion that becoming a well-rounded Software Engineer is equally as important as becoming a good Developer.

I started my Software Engineering career by joining Capgemini’s Degree Apprenticeship programme in 2012 and completed it at the end of 2017 with a First Class Honours Degree. I currently have the title of Software Engineer Lead, but I’m in a good position to construct this article given that relatively, it wasn’t too long ago that I, myself, was a Junior Developer.

First Projects

The first day, on your first project, can be a daunting prospect, but my advice is to try not to worry about it. Everyone will know that you’re junior, and they’re not expecting you to be an expert. Try to take in as much as possible and value the experience you’re gaining.

There is no stupid question; stupid people don’t ask questions

Never worry about asking questions, whether you’re junior or senior. I personally enjoy being asked questions, as it gives me chance to pause and question my own thinking, and often, I can learn something from it as well.

If someone has difficulty explaining something to you in a way you can understand, it’s more than likely a sign that they don’t fully understand the topic themselves rather than a fault in your own ability.

If you can’t explain it simply, you don’t understand it well enough

Albert Einstein.

Commitment is key

You can’t be a technical expert straight away, but you don’t need 5 years of experience to be punctual and committed. I’ve not yet met a senior colleague that has been frustrated with a junior team member due to their lack of technical ability, but I have met plenty that have been frustrated by a lack of enthusiasm or problems with time management.

If you’re young, it can be especially difficult to transition from college, university or less regular work to a 9–5, but ensure that building a strong work ethic is a priority.

A goal without a plan is just a wish

Come up with a Career Development plan. Include short and long term goals, break them down into achievable steps. Agree your plan with a team lead, manager or reviewer and try to stick to it. If you find yourself doing something that you don’t believe is helping you to grow, raise it with your manager, citing your plan.

When you know where you are heading you can get to your destination faster and in a more direct route. Once you have identified your career goals, you can align your objectives, training and experience to help you to make progress.

There may be times where you find yourself in a less than ideal role or you’re asked to do something that is outside of your plan, but try to agree that these are only temporary. In your plan, don’t ignore building on your soft skills as well as your technical skills. Software Engineering requires a whole host of communicative and team working skills that are just as important as becoming a coding Jedi.

Impostor Syndrome

As you progress and get given more responsibilities, you can sometimes fall into the trap of feeling like an impostor and that you’ve got to the position you’re in by luck, that you’re not as good as your peers, or that soon you’ll be exposed as a fraud. This is well documented and is called Impostor Syndrome, more information can be found here.

Often just knowing it exists and talking it through with your colleagues is enough to prevent it. I thought I’d include it here after it came up in a conversation where I was surprised to hear that a small majority of my colleagues had experienced some form of it in their careers.

If you wait until you are completely ready to make the next step in your career, you will be waiting too long. Pushing yourself to achieve more will take you out of your comfort zone, but this will also make you improve quicker.

A few points on Coding

• When it comes learning to write code, Google, other search engines and websites like Stack Overflow are your friends, but always make sure you understand what the code is doing, never blindly copy and paste. You’ll never learn anything that way.
• Readability, maintainability and supportability counts. It is easy to slip into the trap of thinking less is more and trying to squeeze five lines of code into one, but each time you do, imagine yourself as a support engineer looking at this piece of code for the first time, trying to fix a bug, when you’re long gone and on a new project. If it takes a couple of attempts at reading a block of code to understand what it’s doing, it either needs splitting up or simplifying.
• Use comments on complicated sections to try to describe their purpose, but don’t feel the need to add comments to code that is self-describing.
• Pair programming can be a good method for a junior developer to learn from an experienced developer, or two junior developers filling in the gaps in each other’s knowledge and learning together. Code reviews help everyone in the team.

And that’s that. Some advice that I’d have given to myself if I could of 6 years ago! If you’d like some more, please check out Zoe Dawson’s excellent article if you haven’t already, which was the first in this series.