Embracing the Learning Journey: A Guide for New Software Engineers

A comprehensive guide for new software engineers to navigate their learning journey and embrace continuous growth.

Introduction

Embarking on a career as a software engineer is an exciting endeavor, filled with opportunities for growth and innovation. However, the initial stages can often be accompanied by a significant amount of anxiety and pressure (and this can also follow us throughout our careers).

New engineers may feel overwhelmed by the sheer volume of information, the complexity of projects, and the expectation to contribute meaningfully from the outset. I recall when I began this journey many years ago, in 2010… The quantity of content was impressive compared to years past, such as when I started learning Linux in 2007.

To give you a bit more context, I started my career in technology as a system administrator, working with bare metal servers, and later transitioned to software engineering. So, when I started searching for content about what I should learn or where to invest my time, I got stuck. Many people said that I should invest in C#, others said Java, Python, PHP… I couldn’t choose. So, I understand when you’re lost in the many paths of the programming universe.

It’s crucial to acknowledge these feelings as a natural part of the transition from academic learning, self-learning, or a career change into the professional software development world. Common anxieties can include impostor syndrome, fear of making mistakes, and the pressure to quickly master new technologies and methodologies. Recognizing and validating these pressures is the first step towards fostering a more supportive and effective learning environment.

This post aims to provide clarity and encouragement for those new to the field of software engineering. Its primary purpose is to demystify the often-unspoken expectations of the industry and to actively encourage the development of a healthy and sustainable learning mindset. By addressing common misconceptions and offering practical advice, this article intends to alleviate some of the initial anxieties and empower new engineers to approach their learning journey with confidence and resilience. The goal is to shift the focus from immediate perfection to continuous growth, emphasizing that learning is an integral and ongoing part of a successful career in software engineering.

Embrace continuous learning

Software engineering is always changing. It is nearly impossible to stay up to date with everything.

I was learning Java when Python gained traction in the web development world. It happened because of the ease of starting a software project with the new tool of that time, Django. After that, I worked with PHP, because it was what gave me a job in my city. A few years later, I would hear about the new silver bullet of web development, Node.js.

At that moment, I was really confused about where I should invest my time. The thing is, if you learn the basics of software engineering, it doesn’t matter. We can learn new technologies when we face a problem that requires them.

For me, the most important thing you can invest your time in is understanding how you learn. Do you learn more when you’re doing practical projects? Do you learn more when you’re listening to someone talk about it? Do you learn more when you’re reading a book? Understanding this will be very important to continue learning.

And, in the midst of all this work, understand that it is impossible to learn everything. There are many programming languages, many cloud providers, many operating systems, many platforms… You don’t need to master everything. If you understand the core concepts of one technology or theory, you can easily move from one to another.

Stay updated about new things, but don’t try to master everything at the same time. Try to truly understand something before moving on to the next.

Taking time to learn

It’s normal to try to impress our managers or team members in our first job. We want to get the task done as fast as possible. So, the faster I finish, the more expert I seem to be, right? Nope.

When you finish a task faster than you need to understand what you’re doing, you miss the context of the issues you’re solving. You miss the time to learn the job you’re doing. The next time you do the same thing, you’ll need support with the same doubts, the same issues, the same errors. This is not as efficient as you think.

If you take the time to understand what you’re doing and why you’re doing the job, the next time you’ll be really fast. And the next time you’ll be faster, and so on. It’s not about burning a ticket today, it’s about mastering what you do to be better at your job.

Don’t miss the opportunity to ask how things work, why things are done this way, and why people decided to do what they did in past projects. This context is more important than moving tickets to done now, and you will not have time to learn in the future like you do at the beginning of your career.

As you grow in your career, people will demand your time. You’ll need to be at some boring meetings, read documentation and approve it, teach others, and do more tasks at the same time you need to learn new things.

So, enjoy this moment!

Questioning and Collaboration

You don’t know much yet, and we, as your colleagues, understand that.

We like it when we help you understand something or help you finish your tasks.

If you fear asking for help, use the time box rule to help you overcome that. If you take more than 4 hours to understand something or to fix a bug in your own code, please raise your hand for your colleagues.

This time box can help you avoid spending too much time doing the same thing, and also not be a problem for your friends who are working on other tasks at the same time they help you. I promise you, in four hours I’ll need some time to think about something else when I’m doing my tasks—if you ask me for support, you’re also helping me.

And, remember, collaboration is part of our job as software engineers. You can request pair programming, schedule meetings on our calendars, and request code reviews before opening pull requests (yeah, you can do it to create more confidence before showing your code to everyone). You can also request learning support… We can do study groups, reading clubs, or anything else that could help you, and also make us take time to study.

It’s OK to say “I don’t know”, “I’ve never done that before”, “I’ll need some time to learn more about it”, “I’m not confident if I can do it alone, could anyone help me?” And no matter the career level you are at, you will always need help with something.

Just a tip before going to the next point: using the calendar instead of notifying in Slack or in the message chat you use in your job is better to avoid distracting people with a lot of notifications.

The “Expert Knows Everything” Stigma

Something nice that I learned in the beginning was that seniors don’t know everything. Some of them don’t even know why they are seniors.

Sometimes you’ll ask for support, but the more experienced developers don’t have the answers to your questions and you might think that they don’t want to help you. That’s normal. Don’t take it personally. They would like to help you, but they can’t. And it’s normal when you know something new that the expert developers on your side don’t know, because you’re new to the area and you’re learning the cutting-edge technologies. You can also share your knowledge.

I remember a time when I was learning about Node.js, and my colleagues only knew C# and didn’t have time to learn something that could be the future of our job or not. It’s always a bet when we invest our time in something new in this area, and not everyone can bet their precious time. But, instead of sharing what I’d learned, I just said that they were too old to learn new things. What a mistake that I regret. I could have just shared something with my friends and helped them instead.

Remember: when you teach, you’re learning even more. If you don’t want to teach to help others, teach to be better at what you’re doing.

Tracking your progress

You’ll face the sensation of not making progress many times in your career. Sometimes you’ll be doing things fast, and other times you’ll be stuck with some task that should be easy to do. This fluctuation in performance makes us think that we’re not progressing in our knowledge or that we’re not having a good experience to be better at what we’re doing.

To avoid this, I like to track my progress. Today, sometimes I track more, sometimes I don’t think about it. But, in the beginning, it’s important to track your progress, because it’ll help you not only to see your evolution, but also to enumerate your contributions to your job to apply for a promotion.

There are a lot of ways that we can track our progress. I tested a lot of them, but, in the end, the simpler ways make me more efficient, because some templates or techniques for doing it require too much time thinking about my tasks and I don’t like it. But you can find techniques that can help you with it. I’ll leave some resources at the end of this article.

How I track my progress

I have a folder in my cloud drive where I keep everything related to my current job: contracts, salary increases, payslips, and also the brag document. The Brag Document is a common practice in our area. It’s the document where we can track our contributions and achievements over time.

My document is really simple, I just copy the template below and fill in the information when I have something interesting to save.

Template:

**Date: <YEAR>/<MONTH>**

**Achievement:** the goal we reached, the task we finished, something important we learned
**Hard parts:** the challenges we faced to reach this achievement
**Learnings:** some words about what we learned while working on it
**Resources:** links with proofs about what we're saying (in case of using it to enumerate for a promotion), links with resources to remember what we learned, etc

- - -

Example:

**Date: 2025/March**

**Achievement:** Launched my English blog to share my thoughts and practice my language skills.
**Hard parts:** Deciding what framework to use to generate the static files was really challenging.
**Learnings:** I learned how to use Astro, Svelte, and a lot about the workflow with this tool.
**Resources:** Some links about Astro and Svelte.

- - -

You can use it in a Doc, in a Sheet, or even in a Text Block.

Conclusion

Navigating the initial stages of a software engineering career can feel like a labyrinth, marked by anxiety, a deluge of information, and the constant pressure to perform. However, by embracing continuous learning, understanding your learning style, and dedicating time to truly grasp concepts rather than just completing tasks, you lay a solid foundation for sustainable growth.

Remember, the journey is not about immediate perfection but about consistent progress. Lean into collaboration, ask questions, and don’t shy away from admitting when you don’t know something. Challenge the “expert knows everything” stigma by recognizing that even experienced developers are continuously learning, and your fresh perspective can bring new insights. Finally, diligently track your progress to visualize your evolution and celebrate your achievements, no matter how small.

By adopting these principles, you’ll not only mitigate common anxieties but also cultivate a resilient mindset essential for a successful and fulfilling career in software engineering. Embrace the learning, embrace the challenges, and enjoy the ride.

Resources

• Get your work recognized: write a brag document
• With a Google Docs template: Why I Keep a Brag Document — and How It Can Help You
• A Notion template