fbpx

Not A Subscriber?

Join my newsletter to receive insights, findings and tips that I've been discovering. All from creating a set of digital products and building an online business.

The Truth About What Junior Developers Actually Get Wrong

I’ve got sympathy for junior developers and other roles in the tech industry.

Not only in the developer and software community. But with the office world at large. The “knowledge” based roles.

Even though we don’t have true “AI”. Things like ChatGPT, Gemini and Claude AI are advancing so fast. That entry and junior roles are getting wiped out.

The Truth About What Junior Developers Actually Get Wrong

So, if you are in a junior role, have you applied for a job and it’s early in your career?

If so, the thing to focus on is to “climb the ladder” as fast as possible.

After 20+ years working as a developer and in the software space. Here are 5 mistakes I made in the early days. And what I still see junior developers doing.

My goal is to help you stand out.

To help you reach a level in your career, of relative safety. To help make you unsackable.

Trying To Do Things Quick

I see this all the time.

And not only from junior developers,

We want to get things done. To get that feature built and into production. To move the story on the board to “closed” or “done”.

But in this rush to complete a story or bug. We introduce other bugs, that may not be visible straight away. It can take months for them to raise their ugly head.

Also, I find things that make you a “professional” developer get overlooked.

To write those TDD/BDD tests. Make sure the code coverage doesn’t drop. To update the documentation to reflect the new changes. Automating part of the build and deploy process. To apply clean code principles and the Boy Scout rule. Knowledge sharing with testers and other members of the team.

These are things I’ve listed off the top of my head.

And I get it.

You want to look competent. You want to show the business how awesome you are. Prove that you’re a good developer and that you bring value to the business.

That can still be true, even if you take more time on your work.

It’s better in the long run. It sounds counterintuitive but you will make fewer mistakes. You’ll stop overlooking things. Which will prevent fewer bugs from going to production.

So what can you do about this?

“Slow Is Smooth, Smooth Is Fast”

I’ve stolen the quote “Slow is smooth, smooth is fast”. From the amazing Derek Sivers. Check him out. A great thinker and self-taught coder.

He has a story about his daily exercise routine. Where he cycles along the coast to a certain point. Then turns around and cycles back.

Each day he would pedal as fast as he could, head down, pushing all the way.

One day he decided to slow down. To enjoy the ride. He noticed far more things on his daily cycle. Things he missed on all the other days. It was far more enjoyable too.

But the crazy thing was when he checked the time of his ride. There was only a few minutes difference between pedalling flat out and slowing down.

That’s my recommendation for coding.

To slow down.

It may take you an extra day or two to get that story done. But you won’t feel as burnt out. You won’t miss things. Either from an understanding of the story. Or other tasks that you need to do to deliver the code.

And the best part! The quality of your code will go up.

In turn, reducing errors and bugs. This means less time on rework and bug fixing, saving you time in the long run.

External Pressures

This can be a tough one to deal with.

Product Owners or Project Managers asking you for time scales. Scrum Masters asking you to give daily feedback about how the story is progressing.

Senior management and the “C-Suite” putting pressure on. Because they have targets to meet.

I know, I’ve been there.

For junior developers. One phrase I want you to keep in mind. Which you won’t be able to say to people. But the principle is valid, is:

“Do you want it right, or right now”.

So, if you are getting pressure to deliver a story faster. You can say to them:

“I’m taking my time with this story. I want to make sure I don’t overlook something. Miss something from our definition of done. I’m focusing on code quality so I don’t introduce other issues”.

I could break this statement down into so many layers.

What you want to do is show that you take your role seriously. And that you have standards you want to adhere to and produce the best quality code you can.

Most software teams will appreciate this and should support you.

If they don’t and still feel pressured. Are they worth working for in the long term?

Create Your Own “Checklist”

There’s a book I’ve read, that I’ve seen recommended a few times. It’s called “The Checklist Manifesto”.

I won’t bore you with the details. But it’s filled with great examples of businesses that have implemented checklists. That ticks off parts of a process and its improved quality.

A lot of software teams have “Definition of Ready” and “Definition of Done”.

But they don’t support developers in being able to tick off, or check against, a list of things to do. It’s left to the developer to remember to do this.

That’s why creating a checklist for yourself is important.

First, you take responsibility for you. And in turn your career long term.

Second, it makes sure you are focusing on code quality. And the quality of the software you’re writing over everything else.

Last, which is a weird one. You’ll develop a habit of doing this. The tasks on the list will also become a habit. You’ll do them without thinking. Again, this will make you a better developer, long-term thinking here.

Worrying That They Don’t Know What To Do

I’ve chatted with many developers. Both junior and higher up the “food chain”

Many worry that they don’t know what to do. Or that what they’ve been doing is wrong.

But that’s why you are a “junior developer”.

You don’t have the experience yet. The knowledge that can only come with time and doing the work. There isn’t the familiarity of “Oh, I’ve done/seen this before”.

And that’s OK.

You aren’t expected to know everything or be able to figure it out.

If you find yourself worrying you don’t know what to do. This isn’t a bad thing. Yes, worrying is a bad thing. But not knowing isn’t.

How do you overcome the worry?

Educate Yourself

For me, the best way would be to do a bit of research or reading. Maybe start playing around with some new tech or a framework.

Good software teams should give junior developers access to training platforms, such as Pluralsight.

There are so many good resources out there, both free and paid. As I said, if the business you work for takes software development seriously. They should support you.

Also, this shows a business you’re self-sufficient. You can take responsibility for yourself and get the work done to a high standard.

If you say “I don’t know what to do exactly on this story. I’ve started watching a run-through of solution X, to help me understand what I need to do”.

Any good software team will support you in this.

The downside is you may need to ask to get support. To get access to some training and the time needed to upskill yourself.

Ask People More Senior Than You.

That’s what senior and lead developers are there for.

So you can ask them for help.

It may sound strange, as you may think they are there to get shit done.

True, but it’s their job to support you too. The team is responsible for delivering high-quality software. Any good senior-level developer should be on hand to help junior developers with this.

More so if you have a knowledge gap.

Don’t worry if you do, that’s OK. That’s the game, you haven’t been in the role long enough to have the experience to “bridge the gap”.

And I’ll let you into a secret.

Most senior and lead developers have this issue too.

The only difference is they have the skills and experience to overcome the gap.

This is why asking them for help is so important. They can help you get over the current issue you are facing. As well as pass on how they think about doing this. So you can also learn how to put this into practice in the future.

So to end this section. What I’ll tell you to do is ask.

Ask the business for training support. Ask the senior developer for knowledge support.

Asking Others First

Now, you may be thinking “This is the complete opposite of what he’s just said”.

And yes it is.

But there is a reason for this.

I was working with a junior developer a while back. He messaged me asking if I could help because he was stuck. I jumped on a Teams call to offer my help.

He said: “I’ve picked up story X, what do I do?”

After asking him a few questions. He’d spent zero time looking at the existing code. He’d not spent any time trying to understand how the current software solution worked. He hadn’t spoken to the product owner or testers to figure out some scenarios to give him a starting point.

He hadn’t even Googled anything related to the tech or potential solution.

Look, asking for help is a good thing.

But in this ‘ask’. The developer was asking me to do it all for him. Not for help, but to think for him.

Get “Stuck” First

I’m going to be harsh here.

In the above example, he may have been “stuck”. Or he thought he was, stuck. But he wasn’t. He hadn’t even tried.

In this case, I didn’t know what to do either. I told him “I don’t know”. I could have helped, but I would have only done the steps that he should have done himself.

Then, if in a few days, after going through some options and still feeling stuck. He should have reached out and asked for a bit of support.

Asking for help is fine. But you need to help yourself first by putting in some effort. Maybe a bit of learning. Or maybe a bit of “domain knowledge” from working and reaching out to other parts of the business.

A good example of when to ask for help came from a senior developer.

He had been working on a story for quite a while. Spending a lot of time researching, and implementing a solution. Then thinking through different scenarios to cover as much as he could.

Again, he messaged me asking for help, even though he was very senior.

In this case, it was a bit of reassurance that he needed. To have someone else make sure his thought process was correct, that it made sense. Then to see if they have a different viewpoint. To see if they noticed something he had missed.

And that’s the point of asking for help.

To get the feature or solution moving forward and to try to do it “right”.

Not to do zero work, to not move it forward at all. But ask others to do that for you.

It comes back to educating yourself. Then get the support when you need help to do that.

Dropping Tasks Because Someone Asks You

Now, this is a tough one. Very tough.

If you are working on something, on a story.

Then someone senior, at the management level or even higher asks you to do something. Your reaction is to drop everything and focus on supporting them.

And to say “no” is hard, even impossible to do.

Even now, after 20+ years as a developer, this still happens to me.

And it makes my piss boil.

In your early days, you won’t know what the best course of action will be.

What Is The Priority

I say this a lot to the businesses I work with and for. More so when we have multiple projects to work on. Each with a deadline.

“What is the top priority? Which one is the most important? What should we focus on?”

Most of the time I get back “Well they are all important”.

My reply: “Well if all are a priority, then none are a priority”.

I try to make people aware that if a development team’s focus is spread across projects. And they’re expected to flip between them. The speed of getting those things delivered will drop. And more important, so will the quality of the code and the chance of future bugs occurring.

More often than not. You won’t be able to influence decisions or get people to commit to a single task or project.

All you can do is make aware to the person ask that you are already working on something. And to get them to decide if the ask is more important.

Communicate The Ask

If this happens. If someone “higher up the food chain” asks you to do something.

Before starting the task, let other people know.

My recommendation here would be to let your scrum master, product owner/project manager know. And the team leader/development manager know as well.

This lets people know that you are no longer working on something. To make them aware that someone has broken your focus.

Depending on your team structure, or the structure of the business. This could look different. But communicating that this has happened is key.

Now, there might be nothing anyone can do to resolve this. You may have to suck it up and do the task. That’s fine.

By communicating that you are no longer doing what people think you are doing. It may uncover other process and relationship issues within the business.

As junior developers, it’s not your job to fix these or even push back.

All you can do is to make people aware of what’s going on.

Your manager may pull rank and say “Don’t do it, leave it with me. What you’re working on is far more important”.

Other people in the business may know the “bigger picture” and be able to prioritise things.

That will only happen if you communicate requests with them

What I’m getting at is communication is key.

Relying On Technical Jargon

The tech industry loves an acronym.

I don’t get it though.

It’s another thing that pisses me off

Why name something, or make it sound complicated? Take NFT for example. This stands for ‘Non-Fungible Token’. In other words, it’s unique, it’s not replicable. Why not make that more obvious?

Junior developers may think that knowing these things makes them sound clever. Makes you look like you know what you’re doing and that you’re getting better at your job.

Maybe.

Albert Einstein once said, “If you can’t explain it simply, you don’t understand it well enough”.

In the software space, this has two meanings.

First, do you know that thing? Or do you know the acronyms, what they stand for and the principle behind them?

But do you understand it?

Second, you will be dealing with people who aren’t technical. And if you start spouting jargon, you will make them feel stupid and make yourself look arrogant.

Again, It’s About communication

I was going to give lots of examples of tech folk not communicating complex things to non-technical folk.

But I’ve too many examples.

Too many stories. It annoys me too much to think back at what other developers do. And what tech support engineers said, the way they acted.

What I will say is modern software development. In the teams that you work in. And the wider business that you work for. The majority of the people won’t be technical.

Yes, they may be able to use software and live in a digital world.

But they don’t understand the “invisible”, nor should they. That’s your job.

Don’t try and look smart and show how well you understand the tech.

Most people you work with will be thinking WIIFM – “What’s In It For Me”? Yes an acronym, I know, but at least it’s a simple phrase.

You need to be able to explain something to someone. In a way that they can grasp the concept. They won’t need to know how things work from a coding or technical viewpoint. But will need to know whether it helps them either solve a problem or help them do their job better.

The better you can get at this. It will make you look “smarter” than shouting jargon at people.

It will make you more valuable to the business. In turn, less likely to get sacked, and more likely to get promoted.

And that’s the goal.

To jump from the junior role as quickly as possible.

“AI” is coming, and it’s after your job.

Conclusion: What Junior Developers Get Wrong

Junior developers, you’re going to make mistakes.

You’ll introduce bugs into the software. You’ll miss updating documentation or writing those unit tests. And that’s OK.

It’s part of the learning process.

But there are 5 mistakes junior developers should try and avoid above all others.

  • Trying to do things too quickly
  • Worrying that they don’t know what to do
  • Asking others first
  • Dropping tasks because someone senior asks them to do something
  • Relying on technical jargon

These are the ones I recommend you focus on first. Ones that will help you develop your skills quickly.

Not only that, they will give you other “soft skills” that will make you look smarter. In turn, helps you get that promotion,

And keep your job. For junior developers, that’s the game

Oh, just one more thing.

We are getting busier than ever.

If you find yourself struggling to get through your workload and are looking to be more productive?

I’ve put together a course for other developers called Productivity Bootcamp. I run through how I manage my workload using things like checklists and templates.

As well as techniques to improve your focus.

Check it out: Productivity For Developers.

Wait, want more tips & tricks? Yes, please!

Who Is Phil Hughes

I am a coder, content creator & software consultant for start-ups and FTSE 100 companies. I am obsessed with productivity, self-improvement, and building a lifestyle business.
You can work with me to transform your business! Setup a recurring revenue model designed for growth.

When You’re Ready, Here’s How I Can Help You:

10x your productivity with this one simple hack
10X Your Productivity
Discover this simple, yet effective technique. which helps you be ultra-productive and get shit done!
Notion Habit Tracker
Habit Tracker
A personal tracking system that helps you create better habits.
GTD Framework Template using Notion
GTD Notion Template
A timeless framework that helps you get clear, organized, get more done and free up your time.
Online Business Systemization
Online Business Systemization

Learn how to systemise and automate your online business. Free up your time so you can focus your energy on growing your business.

Productivity Bootcamp Course
Productivity Bootcamp
Productivity Bootcamp is a 4 part course, that helps you to get more done. Spend less time on the mundane. And more time doing what you love.

Press S to subscribe

Tap to subscribe

Join my email list for insights, tips and more