Learning at work: common obstacles and how to overcome them

Every developer I’ve met during my mentorship sessions was striving to learn. Yet, many felt stuck in their careers. When debugging growth obstacles with them, I always start by exploring “learning at work” opportunities.

It’s common to treat learning and working as two separate activities. First, a developer invests time in acquiring missing knowledge. Then they go and happily complete their task at work. Ideally, others only witness the latter part and perceive them as an expert.

Reality is different, though, and I often hear developers complain they can’t learn at work:

• “I don’t have time to learn at work”
• “I work on a legacy project”
• “My company doesn’t use technology I want to learn”
• “We don’t have a learning culture”
• “I’m the only frontend developer in the team / I have nobody to learn from”
• “I don’t have a side project”

These are all common circumstances for many of us. I have experienced all of them myself, and will address each later in this article. But first, let me name a few benefits of learning at work:

Benefit 1: Focus

For over two years, I was learning TypeScript in background while still writing production code in JavaScript. Then, I threw myself in a 100% TypeScript project at work and mastered it within a couple of weeks. My work environment helped me radically focus on what I wanted to learn.

Benefit 2: Real-world problem

Back to my TypeScript example, I had practical problems to solve, and they served as real-world exercises to test my new skills.

Benefit 3: Deadline

Working in short sprints introduced internal deadlines that forced me:
a) to be realistic about what I can achieve
b) to finish at least one task per sprint

Benefit 4: Supporting network

When I got stuck, I could ask more experienced developers for help and fast-track my learning (or learn together if my question puzzled them too).

Benefit 5: Healthy dose of discomfort

Not knowing where to start felt shitty. I was willing to go the extra mile to overcome this discomfort. The term “hardworking” is out of fashion these days, but that’s often required to learn topics deeply.

Benefit 6: Time

I spend 8 hours every day at work, 40 hours per week. With a bit of effort, I can balance productivity vs challenge in my workload and keep learning organically.

Many employed developers can access all those benefits at their jobs. I learned to appreciate and use them to my advantage.

Now, let me go back to the list of common obstacles and share how I think about them now:

⏰ Obstacle 1: I don’t have time to learn at work

For me, developer efficiency is not about working faster. It’s about doing repetitive chores and basic tasks faster so that we can spend more time on difficult ones.

Everyone’s favourite example is unnecessary meetings. But it can also be a buggy dev environment that slows down every code change, broken communication between dependant teams, or gaps in business domain knowledge. If basics are broken, everything becomes more difficult.

Another source of time is personal budget. I don’t mind borrowing a little if I’m passionate about a task at hand. I never regretted late evenings debugging an intriguing issue or polishing documentation for a new feature. I have only warm memories of those occasional spikes of energy and dedication. I wouldn’t necessarily recommend this approach to everyone, but it feels necessary to mention it in this article.

But my primary source of time for learning is hidden in this quote:

Software Engineering is a learning process, working code is a side effect (Alberto Brandolini)

As software engineers, we learn 100% of the time at work. You may be learning 40 hours/week without even realising it. It’s a good idea to regularly reflect on your past experiences and uncover any hidden learnings. In practice, deep work on any engineering task brings me new insights.

💩 Obstacle 2: I work on a legacy project

Due to frequent job changes, developers often depart from a company before their code becomes an unmaintainable ball of mud. Instead, they join a new company where they have to deal with someone’s else ball of mud.

When I think of my past struggles with legacy projects, two issues stand out:

Slow. They all were very slow to run, to build, to test. Such projects tend to have hours-long testing pipelines; otherwise, it’s too risky to implement any changes. As a result, even a minor modification can take days to release. I believe it’s never too late to optimise performance, particularly if you plan to support the project for awhile.

Complex. Legacy projects encapsulate tons of undocumented business logic. Developers often have to start making changes before familiarising themselves with all project features. Sometimes, it’s just too much to fit in one man’s head. Other times, people with knowledge may have already left the company. Either way, I’d spend more time watching how others use the project, reviewing git history, and asking around about the most confusing features. Nobody will be excited to talk about a legacy system. At the very least, I try to keep the conversation tone neutral.

Other common issues with legacy projects are spaghetti code, outdated technology, poor UX, lack of structure, low test coverage, inconsistent documentation. Finding your way through all these issues is a great software engineering lesson. It’s extra effective (and painful) if you were the one creating the mess several years ago.

⚛️ Obstacle 3: My company doesn’t use technology I want to learn

First of all, your tech stack of preference must intersect with the one of your employer. It’s heartbreaking to see JavaScript developers fighting with PHP (and vice versa). If you find yourself constantly battling against the tech stack, I recommend switching jobs.

Now, let’s consider a less extreme example. Imagine that I want to learn Clojure. It’s a respected language with a high developer satisfaction rating. I have a friend who happily transitioned from PHP to Go to Clojure, and I believe I can too! As a Full Stack developer, I’m easily attracted by this kind of thing! However, to be honest, I don’t have a lot of tasks at work that would be a good fit for Clojure.

In such a situation, I would question why I want to learn Clojure when several other opportunities are available at my current company. Depending on the answer, I might decide to explore Clojure in my spare time or choose another language to feed my curiosity.

As a side note, I’ve never experienced disgust towards any particular technology. Clojure is cool, and PHP is cool, too.

👺 Obstacle 4: We don’t have a learning culture

The mindset I describe in this article doesn’t require any specific culture. Thinking in such bold terms can create unnecessary frustration. Instead, I would begin by adjusting my own approach to learning at work, and see if others want to join me. It’s perfectly okay if they choose not to; it shouldn’t change my plans.

🐺 Obstacle 5: I’m the only developer in the team / I have nobody to learn from

Junior developers often find themselves in smaller companies with just a few other developers. In a similar situation, I doubled down on learning from a local web community. It was different from working in a strong dev team, but still very fruitful. Many autonomous full stack developers have grown up in such environments.

🧶 Obstacle 6: I don’t have a side project

I don’t have one, either. I’ve made several attempts but quickly abandoned them. I genuinely admire developers who build side projects, commercial or open source, practical or crazy. I’m not one of them, and that’s fine.

I’m more driven by the idea of contributing back to the web community. Nowadays, I write articles and provide mentorship.

Go discover what works for you; it doesn’t necessarily have to be a side project.

To summarise

If you are willing to find learning opportunities, you will find them in almost any company. Working environments create perfect conditions for learning:

• 🎯 focus
• 📊 real-world problems
• ⌛️ deadlines
• 🤝 supporting network
• 🤪 a healthy dose of discomfort
• ⏰ time

With the right attitude towards common learning obstacles, we can continue growing without side projects, frequent job changes, or expensive training sessions.

I will conclude with one of my favourite quotes:

“Software Engineering is a learning process, working code a side effect.” (Alberto Brandolini)

I hope you enjoy the never ending learning curve and get the maximum out of it!

A little promotion: If you need a hand on your journey, I’m offering both free and paid mentorship sessions.