Are you a junior engineer with a hunger to learn? I certainly was, and recently I've been reflecting on the advice I might give my junior self if I was able to. In this article, I'll touch on an approach to thinking about solving technical problems and talk about some of the traps I fell into when I was learning this for myself.

Before we start, I want to emphasize that, as a junior engineer, I'd recommend you try to learn as much as you can. Seriously. Learn as much as you can. I'm not going to preach that you should spend lots of your spare time coding (unless you want to!), but you should try to make time within your job to absorb as much as possible.

Some managers might hate me saying this but, if you've finished your work quicker than what was expected, don't feel like you need to pull more work off of the backlog to fill the time you didn't think you'd have. Sure, that will help you learn, but you risk re-learning the same things, and not getting a chance to widen that knowledge.

Your first job is a good opportunity to be a little selfish and set yourself up for longer-term career success (which will benefit your employer in a more nuanced way than just "doing more work"). If you're looking for a job, finding one that includes learning as part of its culture is a big green flag in my eyes. There's a phrase that gets passed around that goes:

CFO: What if we train them and they leave?

CEO: What if we don't and they stay?

Which I think is a great perspective for employers to adopt!

---

I'm going to break problem-solving into three parts: "given a problem, apply one or several techniques to produce a solution". This lets me highlight the fact that as a junior I tended to focus more on the middle part (the techniques) and not as much on the value of the end result, a definite trap that others might fall into!

The Problems 🤔

Let's start with thinking about the problems you might encounter. As a junior developer, you may not get much initial autonomy over which tasks you're assigned. That's okay. Approach each one as a learning opportunity. As you get more comfortable, make sure not to shy away from different types of problems, even to the point of asking if you can work on certain things with certain people just to get that exposure. Don't shy away from database work just because you think it's boring (guilty - combined with an uncomfortableness from lack of experience).

It's also important to learn to ask questions, ideally to the people that are closer to the problem than anyone else. On an invoicing project early in my career, I was encouraged to spend time with our two members of staff that used the current system, and it was great to understand their existing workflows and specific needs. However, on a later exam results processing project, I spent most of my time talking to the developer of the previous system, and not the actual users. Post-launch, I remember the director of our department saying something along the lines of: "We built them a whole new system when all they needed was a button." (Ouch, that still stings). And while it may be exaggerated, I can't know for definite because I didn't make sure I fully understood the problem by asking the right questions to the right people!

Learning about different types of problems and how to understand them is crucial to picking the right techniques to solve that problem.

The Techniques 💡

Once you understand the problem, you can apply one or many techniques to reach a solution. This is the part that I found the most fun and devoted the bulk of my learning time to.

My first job was in a fairly standard Microsoft stack (C# .Net Framework, Razor Views, SQL Server). I found a wealth of resources via Pluralsight (I was fortunate enough to work somewhere that provided a subscription), which really let me learn best practices around SOLID principles and Clean Code. The ReSharper extension for Visual Studio also helped me learn all the various language features of modern C# via its hints and suggestions. I think it's great to learn the ins and outs of your company's tech stack...

... but it's also great to look around too! You'll quickly come to realize that the world of tech is vast, even within a specific discipline like web development. This can feel very daunting, but it's also exciting to embrace. I had a lot of fun reaching into modern JavaScript frameworks (Angular), non-traditional databases (MongoDB), and learning how to host my own hobby projects (AWS).

But is there any use in learning about tech that you're not even using in your job? Well, I can easily point to lots of examples where this experience has helped solve problems that future teams I've been in have encountered. "How can we make sure we don't accidentally push JavaScript like const that breaks IE11?" Oh, well we already have a Gulp file, we can throw in Babel and transpile our JavaScript to be more browser-compatible. "How can we store all these potentially unstructured messages passing through our system in a way that we can still query them?" Well, MongoDB might be a good use case for this due to it allowing schemaless collections with fast insertion. "Why is this codebase set up so that we rely on client-side storage in case of using the .Net session?" I imagine this gets deployed behind a load balancer so, without sticky sessions or a shared cache, client-side storage is the thing that will reliably persist between requests!

My advice to my junior self would be: don't be daunted by the vastness of tech options out there. Get a good grasp of your company's tech stack, and then find time to explore what else is out there - it'll pay dividends in the long run.

The Solutions 👌

The solution will depend on what techniques you choose to apply to the problem. Different solutions have different merits (scalability, reliability, browser compatibility, monitoring, performance, user experience, etc), and oh man, was junior-me easily led. What do you mean you don't think we should rewrite everything into microservices? Look, these two parts of the system can scale independently! Oh, we don't need that? And it would increase operations maintenance? Surely not, we got it working easily enough in containers on GitLab, though I suppose we currently deploy everything to on-premise Windows VMs, which isn't really the same...

I'm definitely not saying that scalability isn't an important part of a solution. But the context is important. How does the existing application scale? Are there any issues with that? If not, then it's likely new solutions don't need to re-invent anything. It's easy to go to conferences or read lots of tech articles and think that your small-to-medium-sized company is going to run into the same problems that Netflix does but (and sorry to be a fun-sponge) it likely won't.

I would remind my junior self that a good solution likely integrates neatly into the existing codebase (even if that code is "legacy") and that ensuring backward compatibility is a great advantage. Similarly, anything that is written from the ground up, or that reaches outside the company's existing tech stack, is likely a disadvantage. And yup, that's a big buzzkill after you've spent hours and hours learning about all The Techniques, but it's the truth. Every new solution should take the existing skillset of your company into account.

Let's expand on this. Early in my career, a technical director decided that the new project I was working on should use a NoSQL database. Why? I'm not sure (though shiny object syndrome comes to mind). I didn't stop to ask, it was obvious to me then: I had read all about how NoSQL databases were the future, and I was going to be part of the revolution. To be fair, we did a lot of things right: we sent developers to a MongoDB conference, we invested in training (in particular, I became a "Certified MongoDB Developer"), and we worked together to ensure at least 3 developers could query and work with the new database.

Eventually, I left the company, and the MongoDB project I had worked on needed periodic developments. From what I heard, it was a painful experience for developers to query and develop with this technology that they only occasionally needed to have experience with. There may even have been fists on tables and frustrated mutterings! I am a huge fan of MongoDB, and actually think it's a great database to work with in a lot of situations, but a company that only has SQL experience building a product that had no specific need for any of MongoDB's key selling points isn't one of them. Like a lot of projects, SQL would have worked just fine, and, if your company has already invested a lot in that skillset, a different technology should have clear and significant advantages (besides being shiny) to be considered as an alternative.

Thinking about the lifetime of a solution isn't something I spent enough time on when I was a junior. Naturally, your instinct for this will improve as time goes on and you see different solutions age (some less gracefully than others), but it's good to start thinking about it earlier rather than later.

---

So, let's sum up:

• If possible, prioritize a job that values learning as part of its culture.
• Don't feel guilty about taking as much time as possible to learn at work.
• Ensure you understand the problem (and the people closest to the problem) before rushing into picking what techniques to use.
• Make sure to prioritize learning your company's tech stack first, but definitely venture outwards into unknown territory.
• Different solutions have different merits. Not every recommendation you find online may apply to your context. Think about the lifetime of your solution.

I feel obligated to say that this post is heavily biased toward my own slice of experience. I was lucky enough for my first job to be at a company that really valued learning, and I had a great line manager who put me on a strong learning path and encouraged me to absorb as much as I could.

If you're a junior, how is your own learning going? What hurdles are you running into?

If you're a bit further into your career, what was your junior progression like? How do you think that progression influenced your future work? What advice would you give your junior self if you could?

If you consider yourself the employer in these scenarios, how much time do you think your juniors should spend learning compared to "getting work done"?