DEV Community: thomaslanghorst

The Best Engineering Teams Use AI and Junior Developers Differently

thomaslanghorst — Sat, 22 Aug 2026 03:46:29 +0000

Over the past year, I've watched a lot of engineering teams go through the same adoption pattern with AI tools. They start using GitHub Copilot or Claude. Productivity goes up. And then someone in a meeting asks the question: "Do we still need as many junior developers?"

I think that question reveals exactly the wrong mental model.

The teams getting the most value from AI tools aren't the ones who figured out what AI can automate. They're the ones who figured out what AI should automate, and then designed their workflows around that distinction.

That sounds like a small difference. It isn't.

Most of the debate around AI and junior developers focuses on the wrong question: can AI do what juniors do? In a previous article, I explored why that question leads teams in the wrong direction. In another, I looked at what happens when organizations quietly remove the work juniors need to grow. This article is about what the best teams actually do instead.

They don't pick AI over junior developers. They redesign how work flows.

The AI and Junior Developers Debate Is Asking the Wrong Question

The argument goes like this: AI can generate code, write tests, and produce documentation. Junior developers also generate code, write tests, and produce documentation. Therefore, AI can replace junior developers.

This looks logical at the task level. But it misses something important.

Junior developers aren't primarily valuable for their output. They're valuable for what they become while producing that output. Every bug they debug, every test they write, every pull request they review is quietly building something that doesn't appear in any sprint metric.

You can automate a task. You can't automate the learning that comes from doing it.

That's where the replacement narrative breaks down.

What AI Is Actually Good At

After using AI coding tools seriously for a while, certain patterns become clear.

AI is fast and reliable for repetitive, well-defined work: boilerplate, standard implementations, documentation drafts, test scaffolding for known patterns, straightforward refactoring. The common thread is that these tasks have a recognizable shape. The output can be verified quickly by someone who knows what correct looks like.

What AI handles less well is anything that requires judgment about context. Ambiguous requirements. Organizational constraints that aren't written down anywhere. Tradeoffs that depend on what this codebase will look like in two years. Recognizing that a technically correct implementation is actually the wrong solution to this specific problem.

AI tools produce output confidently regardless of how uncertain the situation actually is. That creates a subtle but real verification problem. Sometimes the wrong answer looks almost indistinguishable from the right one.

What Junior Developers Are Actually Good At

This is where the comparison gets interesting.

Junior developers are slower at many of the tasks AI handles well. They take longer to write boilerplate. Their first test suite isn't always comprehensive. That's expected and fine.

But junior developers do something AI doesn't: they learn while they work.

A junior developer debugging a flaky test is building debugging instincts. A junior developer reviewing a pull request is starting to develop opinions about code quality. A junior developer working through an ambiguous requirement is learning how to ask the right questions. None of that shows up in velocity metrics. But it accumulates into something extremely valuable over time: engineering judgment.

Junior developers also surface organizational knowledge in ways AI can't. When a junior engineer comes back and says "I'm not sure what this requirement means," that's not inefficiency. That's a signal about unclear specs, inconsistent system behavior, or missing documentation. It's useful information.

And there's one more thing worth saying plainly: junior developers become senior developers. The pipeline matters. Teams that remove meaningful work from junior developers don't just lose short-term output. They slow down the production of the senior engineers they'll desperately need later.

What Changes for Senior Engineers

In AI-assisted teams, the role of senior engineers shifts in a specific direction.

Code generation speed increases. That means the review surface increases. There's more output to verify, more architectural decisions being made faster, and more opportunities for confident-looking mistakes to slip through. The most important senior engineer skill in this environment isn't prompt writing. It's verification: knowing whether the output is correct, safe, maintainable, and actually solving the right problem.

What doesn't change: architectural decisions still require deep system understanding. Debugging production issues still requires reasoning under uncertainty. Communicating tradeoffs still requires knowing what the real tradeoffs are.

In well-functioning AI-assisted teams, senior engineers end up doing more judgment-intensive work, not less. AI handles the pattern completion. Seniors focus on the decisions that require experience to get right.

Task Allocation Is the Real Problem

Most teams adopting AI tools aren't rethinking task allocation. They're adding AI to existing workflows and measuring whether output speed increases.

That misses the more important question.

Which tasks should go to AI? Which tasks should go to junior developers? Which tasks should senior developers actually be spending their time on?

Those three have genuinely different strengths and genuinely different costs.

AI is effective for repetitive pattern-matching work. It's fast, scales easily, and requires no management overhead. But it produces no learning, develops no judgment, and always requires verification from someone who can tell correct from almost-correct.

Junior developers are slower at pattern-matching tasks, but they learn while they work. They build judgment. They ask questions that surface important information. They become the senior developers the team will need in three years.

Senior developers are expensive. Their most valuable contribution is judgment: understanding what to build, how to verify it, and what to avoid. Work that doesn't require judgment is the worst possible use of their time.

In my experience, teams often get this backwards. They use AI for ambiguous architectural decisions and pull senior engineers into implementation details. Or they remove juniors from meaningful work because it's faster with AI, and then wonder why their engineers aren't growing.

The best teams assign work based on where it creates the most leverage and the most learning. That's a different question from "what's the fastest way to close this ticket."

Workflow Redesign, Not Just Tool Adoption

Teams that use AI well don't just adopt tools. They change how work flows.

In practice, this looks something like: senior engineers define direction, validate AI-generated output, and help junior developers learn how to evaluate that output critically rather than just accept it. Junior developers work on real problems with appropriate oversight, including learning to use AI as a tool rather than a shortcut around understanding. AI handles the work that has a recognizable pattern and can be reviewed quickly.

That's a different organizational design than most teams run today.

Most teams treat AI adoption as a tooling decision. The teams getting the most value from it treat it as a workflow redesign problem. Those aren't the same thing, and the gap between them compounds over time.

What Happens When Teams Get This Wrong

The most common failure mode isn't over-adoption. It's shallow adoption without workflow change.

That looks like hiring fewer juniors because AI can do their work. Shipping AI-generated output without a corresponding increase in review rigor. Senior engineers generating more code faster without spending more time verifying it.

The downstream consequences are predictable. The junior pipeline dries up. The senior engineer shortage gets worse. Technical debt accumulates faster because AI output goes in without enough scrutiny. Teams gradually lose the organizational knowledge that comes from people actually learning on real systems.

Faster output without stronger verification is just a faster way to create problems.

The Better Question

The teams doing this well aren't asking how to replace junior developers with AI.

They're asking: how do we design a workflow where AI, junior developers, and senior developers each do the work they're actually best suited for?

That's a harder question. It requires thinking carefully about task allocation, learning systems, verification processes, and long-term capability development. It requires senior engineers who understand not just how to use AI tools, but how to structure work around them.

The best teams aren't replacing junior developers with AI. They're using AI to remove work that nobody should be doing manually, and using the capacity that creates to do more of the work that actually requires judgment and experience.

That's a different kind of optimization. And it leads to better outcomes over time, both in what the team ships and in what the team becomes.

Practical Takeaways for Engineering Managers

If you're trying to apply this in practice, a few principles I keep coming back to:

Don't measure AI adoption by lines of code generated. Measure by whether verification processes kept pace with output speed.
Don't protect junior developers from difficult work. Protect their access to meaningful work that builds real judgment.
Give AI repetitive work, not ownership. Ownership requires someone who'll still be there when the system misbehaves six months from now.
Let junior developers evaluate AI output rather than just consume it. Reviewing generated code is itself a learning opportunity.
Optimize for learning as well as delivery. A team that only optimizes for delivery eventually loses the ability to maintain what it delivered.
Treat workflow design as an ongoing responsibility, not a one-time setup. AI capabilities change quickly. The workflows around them need to keep up.

The future isn't AI versus junior developers. It's AI working alongside junior developers inside engineering workflows that are actually designed for that combination. The teams that figure that out first will have an advantage that compounds.

The Hidden Cost of Replacing Junior Developers With AI

thomaslanghorst — Sat, 15 Aug 2026 05:57:27 +0000

Over the last few months, I started using GitHub Copilot for work. It took me quite some time (and a lot of tokens) to learn to use it properly. But once I knew what I was doing, it at least 10x'ed my work.

Until this day, I am surprised how well and fast AI models like ChatGPT or Claude can:

Scaffold CRUD endpoints
Generate unit tests
Refactor straightforward code
Debug simple errors
Document APIs or services
Explain unfamiliar code

With the help of AI, I feel way more productive and efficient than before.

Today, many senior engineers delegate these tasks to GitHub Copilot. And honestly, in many cases that actually IS the more efficient choice. But, if AI is increasingly becoming better at execution-heavy development tasks, what exactly are junior developers supposed to learn from?

Which creates an uncomfortable question: If junior developers stop doing this work, where exactly do future senior engineers come from?

Most Engineers Learn Through “Low-Value” Work

Throughout my career, I was able to work with a lot of very smart and very capable software engineers. And there is one thing they all had in common: they didn't become experienced by reading architecture diagrams or attending conference talks. They became experienced by spending years dealing with messy code, repetitive tasks, flaky tests, deployment mistakes, and occasionally even frustrating work. They all gained experience by working with real software systems.

A lot of this mentioned frustrating work early in my career was actually building a foundation:

Fixing bugs:

While I was fixing bugs, I was not just solving individual issues. I was slowly building debugging instincts. Over time, I stopped focusing on the specific problem in front of me and started learning how to investigate systems that didn't behave the way they were supposed to.

Dealing with flaky tests:

Flaky tests taught me more about reliability than many books or conference talks ever could. Every time a test failed for no apparent reason, I learned a little more about reliability. Eventually, I started recognizing how seemingly harmless decisions can slowly erode confidence in a system.

Maintaining "legacy" services:

A huge amount of my understanding of software architecture came from maintenance work. Reading old code, following dependency chains, and figuring out why a workaround existed taught me far more than architecture diagrams ever did.

Most of this work looks low-value from the outside because it is difficult to measure. It does not always produce visible features. It is often slow, repetitive, and operational in nature. But it's exactly where software engineers develop essential skills like:

pattern recognition
risk awareness
debugging intuition
systems thinking
operational judgment

Traditionally, juniors learned through an apprenticeship-like process inside engineering teams working on exactly those tasks with guidance from seniors. But this pipeline seems to change. Which brings us back to the question from before:

If AI absorbs all of this work, organizations may accidentally remove the environments where engineers develop those skills.

And if that happens, where do future senior engineers come from?

Senior Engineers Are Produced, Not Hired

When discussing AI and productivity, many people focus on the individual developer. How much faster can they ship? How many tickets can they close? How much code can they generate?

But there is a bigger organizational question hiding underneath all of this: Where do senior engineers actually come from?

When scrolling through my LinkedIn, I see a lot of open positions for senior software engineers. Companies seem to assume that senior engineers can simply be hired when needed. But, if every company wants to hire senior engineers, who is producing them?

In my opinion, every engineering organization should depend on internal talent growth. Because senior engineers are far more than simply better coders. They are engineers who have accumulated instincts and habits over many years of dealing with all the complexity that comes with real-world software development.

Today's senior engineers were yesterday's juniors. They are developed over time. And if engineering organizations start removing those learning opportunities, they are unintentionally weakening the system that produces their future technical leaders.

AI May Create Fragile Engineering Organizations

What makes this whole evolution dangerous is that the impact may not be visible immediately.

If a company starts using AI to handle more junior-level work, productivity might even improve in the short term. Features get delivered faster. Less time is spent on repetitive tasks. Engineers can focus on more complex problems.

At first glance, that sounds like a win. The problem is not the AI-generated code itself. The problem is what happens to the human systems around it.

If fewer engineers spend time debugging difficult issues, maintaining older systems, or investigating production incidents, fewer engineers develop a deep understanding of how those systems actually work.

Over time, organizations may find themselves in a situation where only a small group of experienced engineers understands the critical parts of the system. And this creates a subtle form of organizational fragility.

The codebase continues to grow. Development speed keeps increasing. AI makes engineers more productive than ever before. But at the same time, the number of people capable of understanding and handling that growing complexity may actually decrease.

And here is where it becomes interesting. AI makes it easier and faster to produce software. But it does not make it easier and faster to verify and validate it. The faster code gets generated, the more important verification and judgment become.

Every generated pull request still needs to be reviewed. Every deployment still needs to be validated. Every production issue still needs to be understood. Every architectural decision still needs critical thinking. And AI cannot fully evaluate those decisions within the broader context of an organization.

In other words, AI may reduce the amount of coding required to ship software. But it may increase the importance of engineering judgment, systems thinking, testing, review processes, and quality engineering.

And if those skills become concentrated in a small group of senior engineers, they eventually become a bottleneck for the entire organization.

The Best Teams Use AI Differently

After reading all of this, it might sound like I am arguing against AI. Well, I am not.

The question is not whether repetitive work should be automated. The question is how organizations can preserve the learning opportunities hidden inside that work.

In my opinion, the best engineering teams will use AI very differently. Instead of replacing apprenticeship, they will redesign it.

Junior engineers should still spend time debugging production issues, investigating flaky tests, maintaining existing systems and learning how software behaves under real-world conditions.

The difference is that AI can help them do those things more efficiently and learn faster.

Instead of spending hours searching documentation, they can spend more time understanding the actual problem. Instead of being completely stuck, they can get guidance and continue learning.

In other words, AI can reduce friction without removing exposure.

The same is true for senior engineers. Their role becomes less about writing every line of code themselves and more about reviewing, mentoring, and helping others develop engineering judgment.

Because the goal is not to protect junior work. The goal is to protect the pipeline that turns today's juniors into tomorrow's senior engineers.

Should I Use AI or Give the Task to a Junior Developer?

thomaslanghorst — Sat, 08 Aug 2026 05:49:12 +0000

Introduction

Last week, I had a moment where GitHub Copilot felt like a more rational choice than delegating work to a junior developer. I am slightly embarrassed to admit it, yet I still feel like it was the right call. But why exactly is that?

My task was to refactor a fairly complex API endpoint. The difficult part wasn't the implementation itself, but rather understanding the interactions between all involved systems and breaking down the work into manageable steps. After a few hours of anlysis, I had created a farily straightforward step-by-step implementation plan.

Seconds later, I caught myself asking: "Do I give the implementation work to the junior developer, or do I give it to Copilot?" I chose Copilot. And while it felt like the more efficient choice, it kept bothering me afterwards.

A few years ago, many of these implementation tasks would have gone straight to junior developers:

Adding CRUD endpoints
Generating unit tests
Refactoring straightforward code
Debugging simple errors
Documenting APIs or services

Today, many senior engineers delegate these tasks to GitHub Copilot. And honestly, in many cases that actually IS the more efficient choice. But it raises a deeper question: If AI is increasingly becoming better at execution-heavy development tasks, what exactly are junior developers supposed to learn from?

Where AI Coding Tools Already Outperform Traditional Delegation

Before we dig into this particular question, let's first look at what AI currently excels at.

When it comes to software development, modern AI coding tools like GitHub Copilot are extremely good at certain types of work. In particular, they excel at:

Pattern recognition
Syntax generation
Boilerplate production
Code transformation

This is especially true if requirements are clear, ambiguity is low and correctness is easy to verify.

What all of those tasks have in common is that they primarily focus on execution and require relatively little organizational context or domain knowledge. When dealing with implementation responsibilities, AI tools like GitHub Copilot have several structural advantages over junior developers:

They are faster
Have zero onboarding cost
Work instantly
Scale cheaply
Handle repetitive work effectively
Reduce human errors to zero

For senior engineers, this immediately translates into less delegation overhead, fewer interruptions, shorter review cycles, and ultimately faster delivery. In other words: AI significantly increases developer productivity for certain categories of implementation tasks.

And that raises an uncomfortable question: If AI is already better at execution-heavy development tasks, why not give every task to AI? That's why many, especially junior developers, are afraid to get replaced by AI coding tools.

Why Task Purpose Matters More Than the AI vs. Junior Developer Decision

The problem with the "AI vs. junior developer" question is that it assumes all software development tasks are the same. In reality though, they are not.

Over the years, while working as a software engineer, mentoring junior developers, and leading whole projects, I’ve learned that most engineering tasks fall into three broad categories:

1. Tasks that require ownership

The first category of tasks is tasks that require someone to take long-term responsibility for the system and its architecture.

Examples are:

Designing system architecture
Making security-critical decisions
Handling production incidents
Evaluating technical tradeoffs
Maintaining long-term system consistency
Coordinating cross-team integrations

These tasks usually require a deep understanding of the system, architectural judgement, and a solid foundation of the business context.

People working on them often need to evaluate tradeoffs, make long-term technical decisions with impactful consequences and coordinate requirements and decisions across multiple systems and teams.

In other words, these tasks come with real ownership and responsibility. That is exactly why they cannot simply be delegated to an AI, or handled independently by junior developers.

2. Tasks that enable fast software delivery

We've already touched on these tasks earlier, but let's make the category more explicit.

First, let's go over the examples again:

Generating repetitive CRUD endpoints
Writing straightforward unit tests
Transforming data between APIs
Scaffolding new services/modules

In my experience, tasks that enable fast delivery of software usually involve clear requirements, repetitive implementation patterns, low ambiguity and are easy to verify.

People working on them typically need to follow well established patterns to translate well-understood requirements into working code effectively and quickly.

These are exactly the kind of tasks where AI coding assistants like GitHub Copilot already outperform developers writing code on their own in terms of speed and efficiency.

3. Tasks that help people grow

This brings us to the third category: tasks that are intentionally delegated as learning opportunities.

Examples are:

Implementing a small feature end-to-end
Debugging a non-critical bug
Refactoring legacy code to learn architecture
Writing tests for unfamiliar business logic
Participating in code reviews

These tasks usually involve low levels of complexity, rudimentary domain knowledge, touch only non-critical code, and leave room for exploration.

People working on these tasks typically need mentorship, fast feedback loops, and enough time to not only understand the problem, but also why the solution is built that.

In the age of AI, tasks that are not primarily focused on speed or efficiency become even more important. Future senior developers still need opportunities to grow through real-world experience and take on more responsibility.

Where Junior Developers Still Matter

Up until this point, we've looked at the problem from a productivity perspective, focusing on the task-level. But the problem becomes even more visible once we start thinking on an organizational-level, where software engineering teams must make strategic choices about AI adoption.

Growing Future Senior Engineers

In any engineering organization, junior developers should not be seen only as current contributors, but as future senior engineers. Therefore, it's the responsibility of software engineering teams to enable growth and help them learn.

To accomplish that, organizations need to create learning opportunities. From my personal experience working with many junior developers, I've found that they learn best and gradually become mid-level and senior developers by working on real-world problems and taking on increasing responsibility and accountability.

Teams therefore need to support them by allowing juniors to make mistakes and by providing constructive feedback in short feedback loops.

Without those opportunities, teams sacrifice long-term engineering capacity for short-term productivity.

System and Domain Knowledge Compounds

Another argument why organizations need to create learning opportunities for junior developers is that, over time, developers accumulate something that is difficult to document and impossible to generate instantly: system knowledge.

Developers learn why systems were designed a certain way, what tradeoffs were made, how systems behave under production-like conditions, which parts of the system are fragile, and where complexity exists in the codebase.

Besides a deeper technical understanding, developers also accumulate knowledge about the business domain itself.

They learn why certain features matter more than others, which edge cases are business-critical, how real-world users interact with the system, and where technical decisions directly affect business outcomes and vice versa.

This technical and domain expertise is built through years of working on real-world problems, participating in domain discussions, and solving real production incidents. Without gradually exposing junior developers to those experiences, organizations slowly but surely lose the capability to deeply understand their own systems.

Software Needs Long-Term Maintainers

But understanding a system is only one part of the equation. Somebody also needs to maintain it long-term. In practice, systems need to be maintained, debugged, extended, migrated, and sometimes even completely rewritten later.

That’s why I think organizations need more people who can just generate code fast, they also need people who continuously maintain the system.

Investing in Future Engineering Capability

The goal for every organization should therefore not be to replace junior developers with AI tools like GitHub Copilot, but rather to strategically use them alongside human developers. Sustainable software development still depends on continuously developing juniors into engineers who understand, maintain, and eventually take ownership of complex systems.

A Better Delegation Question

In software development teams, the rise of AI coding assistants like Copilot has made delegation decisions more complex. Tasks are often evaluated mostly based on delivery speed, but sometimes the biggest long-term benefit is not the finished feature—it's the knowledge the person gained while implementing it. A junior developer working on a feature may gain architectural understanding, domain knowledge, and practical experience that become valuable far beyond the task itself.

Every delegation decision also shapes the capabilities of the engineering team, and even the organization itself. Teams that only optimize for short-term efficiency may ship software faster today, but they sacrifice the ability to develop future maintainers, domain experts, and system owners.

I believe this ultimately changes the question that modern software engineering teams should be asking. Instead of rushing into deciding whether a task should go to AI or junior developers, engineering organizations should first ask what the task is actually meant to achieve.

Is the task about speed -> give it to AI
Is the task about teaching -> give it to a junior developer
Is the task about ownership -> give it to a senior and include a junior developer

Conclusion

So, should you give the task to AI or to a junior developer?

In my opinion, the answer depends less on the complexity of the task itself and more on what the task is actually meant to achieve.

The future of software engineering will not belong to teams that replace developers with AI, but to teams that understand how to combine speed, learning, and ownership effectively.

AI may change how software gets written, but organizations will still succeed or fail based on how well they develop people. The real competitive advantage in the age of AI will not be to generate code faster, but to build teams that continuously grow people who can understand, maintain and eventually own complex systems. And that is exactly why junior developers still matter.

For more articles like that visit my blog.

Should you learn Go in 2023?

thomaslanghorst — Mon, 26 Dec 2022 04:45:42 +0000

In this article, I will be answering the question: to Go, or not to Go, with Go, in 2023? (sorry for the pun). If you rather want to watch the YouTube video, you can find it here. Now without further ado, let’s find out!

A little History

For those of you who don’t know what Go or Golang is. Here a little history. Back in 2007, Go was first designed by three google employees. As Rob Pike, one of the three authors of Go, wrote in an article:

“The goals of the Go project were to eliminate the slowness and clumsiness of software development at Google, and thereby to make the process more productive and scalable.”

Working with a huge backend codebase, mostly written in C++, Java and Python, the three engineers wanted to build a new language to help tackle the issues they had while working with the code at google, while also maintaining its effectiveness. Rob Pike said: “In short, development at Google is big, can be slow, and is often clumsy. But it is effective.”

So they wanted to take the speed of C++, the strict syntax of C and paired it with pythons simplicity and useful features of Java. And what came out was this new language called Go. The combination of these makes Go one of the most powerful and effective languages for large-scale codebases, while also being simple and easy to maintain. Later in 2009, Go was open-sourced and had its first major version 1.0 in march 2012.

Pros of Go

But what exactly is Go, and what are its main benefits? Go is an open-source, compiled, strongly and statically typed programming language. It was built to be readable, simple and efficient, while also being high-performing.

I will not go into all the pros and cons of Go in this article (you still have things to do today, right?). Instead, I will keep it short and focus on the three main benefits and drawbacks. If you want to see a full list, you can go ahead and watch my video on YouTube.

Concurrency
Go has an incredible concurrency support, which makes writing concurrent code as easy as it gets. The way how easy Go handles concurrency is probably one of the main reasons why people pick this language over others.

Toolchain
Go has a fantastic toolchain. Running, building, formatting, profiling, installing, testing, … all these, any many more commands are part of the integral Go toolchain. So there is no need for external tools.

Simplicity
One of the main reasons why people use Go is: Go is an extremely simple programming language. Without much syntactic sugar, Go forces explicit code. Which makes this language easy to read, easy to maintain and easy to learn.

Cons of Go

But it’s not all rainbows and unicorns in Go land. Go also has its drawbacks. For example:

Verbosity
Despite its simplicity, Go sometimes can be too verbose and too explicit. Functions ranging over several 100 lines of code are no exception. And don’t get me started on the gazillion if err != nil checks. Writing all this code can be time consuming and a drawback for teams rushing against strict deadlines.

No strict coding guidelines
Although there are some best practices and generally accepted rules, Go does not strictly tell you how it wants things to be coded. This lack of clear and strict structure leaves room for undisciplined coding and inconsistencies. Which can become an issue in larger projects.

Still feels young
Even though Go is more than 10 years old, it still is a seemingly young programming language. Sometimes, even big companies or projects are missing Go SDKs or clients for their products. So if you want to use them, you need to either rely on open-source projects or write them yourself.

These are the pros and cons of the Go programming language. But what is Go primarily used for?

Primary use-cases of Go

According to the latest Go developer survey conducted in 2021, Go is used in a variety of areas. Such as Technology, FinancialServices as well as Media/Gaming, to name the top three. Of those people who write Go code, almost 50% write backend API or RPC services. Leaving the rest far behind with data processing, web services and CLI tools with roughly 10% each. So if you work in one of these areas, knowing Go can be a huge benefit.

Job opportunities for Go developers

Now let’s have a look a the jobs for Go developers. The Go homepage gives us a list of many big tech companies, who are using Go. Among them google (obviously), but also PayPal, Meta, Netflix, Uber, and many many more. Go must be doing something right, if big tech companies are relying so heavily on it.

According to Hired, Go is the most in demand skill that companies are searching for in software engineers. The second year in a row by the way. So, the need for Go developers is definitely there. But how about the salaries?

Salaries for Go developers

If you have a look at the annual stack overflow survey from 2022, you can see that Go is among the top 10 of top paying programming languages. With a median of almost $90k USD, being a Go developer gets paid better compared to more popular languages like python ($71k), C++ ($68k) or Javascript ($66k).

If you have a look at the same tables from the surveys of years 2021, and 2020, you can see that salaries for Go developers have increased over the last few years. From $74k USD in 2020, to $76k in 2021, and now being at almost $90k USD in 2022, the average salary has increased tremendously. Which is also very positive for the Go language.

Conclusion

So, to answer the question: should you learn Go in 2023? If you are looking for a new programming language to pick up, or a new language to increase your chances on the job market, in my opinion, Go is a fantastic choice!