Senior Go Programmers & the 5 Things They're Always Thinking About — Are You?

As a Go programmer, it’s easy to get caught up in the day-to-day tasks of writing code and solving problems.

Ever wonder what’s going through the minds of experienced Go developers as they write code and build teams? You know, the stuff they’re thinking about that total beginners probably aren’t?

Photo by bruce mars on Unsplash

In this post, we’re gonna peek into the minds of some Go pros and see what they’re all about. Should be a pretty cool way to get inside the heads of the experts

Let’s dive in.

1. Convention

When working together on a shared codebase, having conventions for things like coding style, naming, and formatting can be a huge help for Go teams. Having those consistent guidelines, even for minor stuff, keeps everyone on the same page.

Some example conventions a Go team could set:

• Coding style

• Naming conventions in Go

• Formatting conventions

• Documentation conventions

• Testing and debugging conventions

I prefer using the Uber Go Style Guide, which is a great starter pack for teams.

Consistency is super important for big, complex systems with a ton of moving parts and developers involved. When there’s so much going on, having solid conventions in place keeps things from falling into chaos. It’s like everyone speaking the same language, stuff just flows better.

But there is no perfect formula.

The key is figuring out where following the conventions strictly vs. flexing the rules will benefit the project and team most. Some consistency sacrifices may be worth it if they solve pressing problems. Other times, sticking to conventions might be better for long-term maintenance. There’s no perfect formula.

2. Writing clean, efficient, and maintainable Go code

Simply having conventions isn’t enough, we need to think bigger when writing code. Beyond style rules, strive for maintainable, loosely coupled, and reusable code.

When architecting features, consider how they fit into the overall system. Plan for change and make components decoupled. Refactor ruthlessly to avoid accumulating technical debt. Think about downstream effects on other teams…

Here are some best practices to make our codebase stays cleanly organized as it scales while we focus on big picture goals:

• Follow established coding style guidelines

• Keep interfaces small and focused. Don’t overload interfaces with unnecessary methods unrelated to their core purpose.

• Handle errors properly. Don’t ignore errors or fail silently, propagate errors appropriately so they can be handled.

• Avoid naked returns. Consider wrapping return values in a struct rather than returning multiples nakedly.

• Comments effectively. Comment complex code or design decisions, not the obvious, comments should clarify, not state the code.

• Review regularly. Read your own old code with fresh eyes, refactor stale or confusing sections, delete unused code.

• Lightweight design. Start simple but extensible, refactor instead of over-engineering upfront, avoid over-abstraction.

• Benchmark inputs. Test performance with realistic inputs, big-O benchmarks don’t tell the full story.

• Design for auditing. Log critical events, support traceability and auditing when necessary.

Somehow, deleting unused code is one of the most important starting point I think we should do for now; it prevents other team members from being concerned about your code.

3. Techniques for optimizing Go programs for performance

Optimizing Go programs for performance is crucial — it helps ensure stuff runs smoothly, efficiently, and can scale well. Good performance means a better user experience overall.

Luckily, there are some solid techniques which developers can use to optimize their Go code. Applying these can help make programs fast, efficient, and ready to scale to meet user needs.

Or you can consider the following options:

• Profile your code to pinpoint slow sections, so no need to guess where the hotspots are, use a profiler like pprof.

• Use memory efficiently, reuse objects instead of allocating and be aware of allocation costs.

• Benchmark bottlenecks using realistic data.

• Optimize hot paths first, pay off technical debt in the most high-traffic areas where it’ll have maximal impact.

• Avoid goroutine leaks because goroutines eat up resources, make sure to close channels, opened file,…

• Parallelize judiciously, more concurrency isn’t always better — balance overhead vs gains.

4. Effectively use concurrency and parallelism in Go

Go was engineered from the start for concurrency — taking advantage of parallelism was baked into the language design itself.

But where do you start? Here are some tips to get your Go code performing better with concurrency:

• Identify pieces that can run independently, any parallelizable work?

• Use the appropriate goroutine pattern for your needs, such as worker pools, pipeline, fan-out, or fan-in.

• Use the sync package for synchronization: The sync package provides tools for improving the concurrency of Go code, such as mutexes and atomic operations

• Don’t overuse concurrency, while concurrency and parallelism can be powerful tools, they can also add complexity to your code

• Atomic functions help safely access shared data, race conditions be gone.

• Mutex locks also coordinate goroutine access, but they’re slower than atomics.

• Profile, profile and profile.

5. Effective working with distributed systems

Working with distributed systems well is super key for improving the maintainability, scalability, and reliability of your code and biz. This is especially crucial for programs needing 24/7 uptime, or that are mission-critical for a company.

Distributed systems can scale horizontally by adding pods, nodes, rather than being limited by vertical scaling on one machine.

Here are some tips for working with distributed systems:

• Design for failure: distributed systems are designed to be fault-tolerant, which means that they can continue to operate even if one or more nodes fail.

• Use appropriate data storage: distributed systems often rely on data storage to function, so it is important to choose appropriate data storage mechanisms.

• Monitor and log your system: you can detect and fix issues before they become serious problems.

I suggest reading The Twelve-Factor app methodology to learn from what’s worked for other devs.

The Future is Bright

The things we’ve covered are just the tip of the iceberg for what experienced Go developers think about. There are always tons of other issues popping up they need to deal with.

Senior Go programmers have to be ready for anything and be able to adapt to new challenges as they arise.

So stay open-minded, keep hacking away at projects that excite you.