3 Career Mistakes New Go Developers Should Avoid

A few years ago, at the GopherCon UK conference, I asked three programming instructors and mentors a straightforward question:

What early career mistake will you never make again?

I walked away with a head full of thoughts and a handful of notes, a completely new, simplified way of seeing the IT world, and a list of mistakes everyone should avoid in their career.

Let’s dive in.

Mistake 1 - Writing before reading

Regardless if you are new to programming or have some experience with it, coming to Go from another language, you can make the same mistake.

Too often, programmers rush to solve a problem as fast as possible. They don’t pause and look at the problem from the Go creators’ perspective.

They think in their previous language grammar. They approach problems from another language perspective. Only to end up with a mess. Poorly performant and over-complicated code, crashing readers’ heads with the cognitive load.

Instead, Go newcomers should read the standard library. Like a book. One or half a package every day. They should invest 15 to 20 minutes daily studying how Go authors approach and solve problems.

This is what ends up leading to writing maintainable, easy-to-read, and easy-to-understand Go modules. On the other hand, this means delighting users and other developers with high-quality tools - software products.

Mistake 2 - Seeing channels, goroutines and concurrency as a remedy for every problem

Don’t get it confused: Go concurrency tooling appears to be simple. But it’s complicated under the hood and requires an experienced designer mindset to get it right to benefit programs.

You can make your Go journey bumpy and frustrated if you throw goroutines on every problem too early. Then, after a while, you realise that most of your code works perfectly without goroutines. It’s easy to understand and fast enough.

Becoming a conductor in the orchestra takes time and a lot of practice. First, you compose songs and play one instrument yourself. Then you learn how to manage tens or hundreds of artists to play together.

Mistake 3 - Not designing a safety net with tests

Don’t take your eye off the ball until you’ve mastered designing software with tests and decomposing large problems into smaller ones.

Debuggers don’t find bugs, they only show them in slow motion.

To this day, I hang this quote on a sticky note on my monitor because it reminds me of days I spent, sometimes weeks, in the debugger world.

Traditional wisdom says to know how your program behaves and what it does under the cover.

But that’s only true if you don’t do three things correctly:

• Decompose larger problems into small, tiny problems you understand.

• Know what data transformation you need for each tiny problem to solve.

• Knowing the required data transformation, design tests that prove your hypothesis and show working software.

This is your safety net. Then, you see that knowing your program inside out is not rocket science, and you understand each debugger step. Assuming you need a debugger at this stage.

We all think we can solve problems immediately and start typing right after reading incomplete specs.

We all think we have unlimited brain capacity.

We all think we are immune to making the program crash or building something nobody understands.

But the truth is, we’re not.

This is why it’s much better to operate from first principles, be humble, and learn Go fundamentals from the very beginning.