How Golang Helps Team Leads Become More Effective?

Team Leads Overview

Let’s talk about team leads and their role in the software development process.

What’s a team lead? There’s no agreed upon answer, so I will have to speak from my own experience.

The team lead’s goal and the reason for their existence is simple: they have to make sure the team is reaching its targets. No more, no less.

The day-to-day team lead duties are simple, but very important:

• • Keep the work meaningful: It’s almost impossible to get a human being to do something they don’t see the sense in on daily basis. So the team lead has to explain the targets, tasks, and steps in a way that the team understands.
  • Keep the team motivated: Money is not always the best way to entice programmers. In my opinion, the best motivator is an opportunity for personal growth. If a programmer feels he is making his skills stronger, he will be enthusiastic about the project.
  • Keep the targets achievable: Nobody can keep sustain their effort in a no-win situation, so we have to make targets realistic. But the targets should not be too easy to reach — remember the personal growth factor.
  • What actions do team leads take to reach their goals?
    • Provide leadership: The team lead should have a deep and broad knowledge of the task and how it relates to the organization’s business goals. They should have extensive technology knowledge that they can share to help team members complete their jobs.
    • Coach: The team lead will have to provide constructive feedback to help team members become more effective. Examples include: “Take a look to this technology”, “read this article”, “this might not be the best way to do this,” and so on.
    • Assign tasks: This is where team leads spend the most effort. Each task must be small enough to track, yet large enough to reduce management overhead. Each task must also be interesting enough, or at least important enough to make people work on it.
    • Perform code reviews: A code review is not valuable in itself — to make it valuable, the team lead has to evaluate the code with the big picture and strategy in mind. If the code is not up to par, the team lead must provide recommendations to fix it.

This is more or less a complete picture of the team lead’s duties.

Now, let’s take a look to the other topic mentioned in the title: Golang.

Golang Overview

Golang is a new programming language that’s unorthodox in some ways. It’s different from the procedural languages most developers are accustomed to working with. Below are its unique properties:

• • • It’s primitive: The word “simple” is not strong enough to describe the situation. Go has no complicated class hierarchy, no Algebraic Data Types, no exceptions, and no async-await. Every process is straightforward. Boilerplate code is used wherever possible — Go strives for clarity over elegance.
    • It’s rigid: The syntax is rigid (and primitive), the code style is rigid, and even the location where you put your code is predefined and not easy changed. Package names have to be highly descriptive and easily understandable. Unused variables and imports will cause a compile-time error.
    • It’s inexpressive: Writing an algorithm in Go takes twice as much code as Java, three times more code than C++, and ten times more code than Lisp. You have no access to syntax sugar, templates, generic types, etc. Error checking is boilerplate — write it simply, or suffer the consequences
    • It’s idiomatic: Most tasks can be written exactly one way in Go. Even if you find something can be done in multiple ways, there is one “right way” you have to use. The community is intolerant to non-idiomatic code.

Looks like a developer nightmare, doesn’t it? It is in some ways.

Now, you may be asking: how can this help the team lead? Let’s take a look.

The Benefits of Golang for Team Leads

Let’s, again, refer to the team lead’s list of objectives. Below is a breakdown of how go Go comes into play:
Leadership

• • • Go’s simplicity makes it easier to explain each task. In fact, there’s no way to do anything outside the task itself — one cannot write code ”for the future needs”, or for “others to use later”. The approach is easy: this is the spec, this is the result.
    • Go’s rigidity makes it impossible to waste time arguing about the way code should be structured or designed or stiled. One language, one way, one team lead.
    • Go’s inexpressiveness sparks less arguments about “ugly” code. Every piece of Go code is “ugly” in one way or another — so, no one tries to look for the beauty. In my experience, passion for “pretty” code can eat up a surprisingly large amount of time.

Coaching

• • • I didn’t think primitivism was a good thing before I started working with Go. Any idea explained in Go’s terms appears simple. Of course, the idea stays the same, but the explanation has no chance to become complicated. So, when you’re explaining the “how” and “why” of each task, everyone can easily grasp the concepts.
    • Go’s rigidity makes it easier to enforce common standards. Disagreements tend to take place over which coding practices are best. However, Go often has only one option, so there is no way to argue. Halleluyah!
    • Go’s idiomatic nature also makes the team’s life easier. Every programmer knows the common code style is best in any language. Since Go’s style is fixed, there is no space for developers to invent their own style — they have to stick to the common standards.

Task Assignment

• • • Go’s properties make it impossible to assign an unclear task. Of course, Go is not the only language that provides this advantage. For example, I can say the same for C (but C is dangerous to play with, right?). I could not say the same for Java, C++, C#, Python, Perl, or NameIt however.

Code Reviews

• • Go’s primitive, rigid, inexpressive, and idiomatic nature makes every piece of code easy to read and understand. Go has no virtual methods, so you do not need to search the whole project to find where the real code is defined. Go has no inheritance, so whatever type you’re looking for is the last and only version of the type. Go has no exceptions, so the error is catched exactly where it happens. Most Go modules are self-explaining, as opposed to projects in other languages like C++, where you have to know the whole project very well to understand the code you are viewing at the moment.
  • Go’s rigidity makes it easy to write linters and tests. I don’t even need to look at the pull request assigned to me, if they didn’t pass the tests and linters I carefully picked out myself. Less reading means more productivity!
  • Often, team leads have to provide negative feedback on the pull requests they’re assigned to. And, often, it’s difficult to explain the requirements. But not in Go! The ”code must be Idiomatic” mantra is not just a mantra — it’s a way of thinking that every Go programmer must employ to be effective. This makes negative feedback incredibly clear-cut.