You've got this: become a confident developer
I've never liked the title Junior Developer. I much prefer Less-Experienced Developer. It doesn't imply age. It just says "you don't have the knowledge yet".
Being a Less-Experienced Developer is where we all start.
We might be less-experienced in software development as a whole. Or we might be less-experienced in a specific programming languange. Or a specific domain. Or testing. Or in front-end skills. Or databases. Or infrastructure. Or tooling. And so on...
It can be overwhelming to think of all of the software development concepts that you don't know. I've been a professional software developer since 1994 and I have a list as long as my arm of all of the things I don't yet know. And I like that. I'm always learning so it gives me something else to look at when I feel I've gained enough experience in the current technology I'm investing my time in.
But it can feel too much at times. You might think that being a software developer is too formidable and you don't know where to start. As I say to the less-experienced developers on my team:
“Be confident. You've got this!”
You are eventually going to be the biggest asset to your team and company. It'll just take a bit of time.
So how do you help to keep up that confidence?
Ask all the questionsPermalink to "Ask all the questions"
We have a phrase in my team: "there's no such thing as a silly question". I love it when the team ask questions. It's a chance for more-experienced team members to step up and share what they know. Or for another less-experienced person to share what they've just learnt in that area. Asking questions is the key to learning. You're not expected to know everything so ask away!
Hopefully you're working in a team with a positive culture where senior engineers or managers don't disparage others for not knowing things. If you're a team lead, it should be your job to enable a culture of openness. If a less-experienced engineer is under confident, and perhaps isn't understanding something, why not try to open the discussion for them by asking someone to explain the concept. Be their advocate. Not everyone is comfortable in asking for help.
Understand the team's applicationsPermalink to "Understand the team's applications"
Every team will build their applications in a different way. There will be technology decisions which have been made many years ago. There will be specific tools that the team use. Their will be team understanding around code design patterns. The folder structures and testing methods will have been chosen for a variety of reasons. It's time to dig in and start to understand why they've been built in this way.
Try and get a high level overview of the applications that the team owns, what they do, and how they work. You won't be expected to know everything, especially in a large codebase, but having a basic understand will really help to build your confidence. Once you've learnt a little bit about the systems, why not share it with others?
Communicate with your team and find their superpowersPermalink to "Communicate with your team and find their superpowers"
You should get to know your teammates. Each of them will be different and have expertise in various technical topics. There will often be someone on the team who ends up being the most knowledgeable about specific applications or technologies. Another might be the expert in your tooling and continuous integration servers. If you're feeling stuck, then work out who has the superpower in that area and chat to them.
In my experience, the best developers are born out of great communicators. Building a great working relationship with the right person, and asking for their help at the right time, can really help you to grow as a developer. Pay attention to what they're helping you with and how they're explaining things. Reiterate the information back to them to clarify your understanding. They are there to help you. A good senior engineer should be a good mentor to those with less experience.
Document all the thingsPermalink to "Document all the things"
Documentation is the thing that most developers are the worst at. It should be part of the product that we're developing but we often leave it as an afterthought. When you're learning from others, always make your own documentation. Some of the less-experienced developers on my team keep a developer diary of what they've learnt each day. They then use that to confirm their understanding at the end of the week. Suggest to the team that you document what you're learning for everyone. Update the project's README file with what you've learnt and raise a pull request. Doing so will really help everyone but especially you.
Your notes can be a list of the concepts you've learnt during the day. It could be those pesky
git commands that you need to learn. It could be links to online resources that you've found helpful. I've always liked to keep my developer resources in a GitHub repository which I can add to. By using version control, you can keep a history of what you've added and why. It also helps you to learn how a tool like
git and GitHub works. If you don't want to use version control, then you can keep your notes in your favourite note-taking application. I love Obsidian but it could be Evernote or another application.
Set solid learning objectivePermalink to "Set solid learning objective"
One of my team used to be a primary school teacher and is one of the fantastic developers on my team. She's taught me that having a good learning objective is the key to learning a topic. Understand what you want to learn and why. This could be learning how to create a unit test for your code. Or how to store some state in a database.
Decide on what you want to learn and focus on that for a period of time. Don't jump from one language to another or from one new library to the next. This is very easy to do and won't help to build your confidence in your ability. You don't have to become an expert in everything overnight so having a single, focused learning objective will really help.
Help others once you knowPermalink to "Help others once you know"
Once you've learnt a technological topic, teach it to someone else. Being one step ahead of someone else, and teaching them what you know, will really help to solidify your learning. I always like to build a culture of lifting the team up and this should apply to everyone and not just the team lead.
Help to lift your colleagues up by running your own learning sessions for the team.
Be excellent to yourself and each otherPermalink to "Be excellent to yourself and each other"
Finally, please remember that you deserve to be a software engineer. You might be early in your career, and feel like there's too much to learn. Just remember that you'll definitely get there but it takes time. You probably don't remember how much you have already learnt. Look back at your notes and rediscover what you learnt last month, 3 months ago, or even a year ago.
Celebrate your wins, however small they are! You'll have come much further than you think. 🎉
Don't forget to be excellent to yourself. You're doing great!
And in the words of Bill and Ted, "be excellent to each other!"
I'm Marc Littlemore.
I’m a Software Engineering Manager who works with high performing development teams and loves to help to grow other software leaders and engineers.
Want to learn more about technical leadership and intentional remote working to grow your career?
👉🏻 You should sign up for my weekly newsletter here.
Want to read more?
Easily Create Gravatar Images With Eleventy
If you're moving your Wordpress site to Eleventy, you will want to convert your Gravatar images too. Find out how easy it is using an Eleventy shortcode.
Streamline Your Workflow: Automate GitLab Releases with Semantic-Release
Revolutionise your GitLab workflow with automated releases. Discover how to use semantic-release for seamless deployment.
Writing great pull requests
Collaboration with other software developers is the key to great software. How do we make sure our code is merged into a project? By writing great pull requests.