This may come as a shock to some of you, but your job as a lead developer is not just to write code; in fact, you'll be doing less and less coding as you gain more leadership responsibilities. Rather, your job is to make it easier for others to write code.

In this edition of The Catch Block, let's talk about two ways we as leaders can make programming easier on our teams: knowing where stuff is (or how to find that out), and keeping the bigger picture in mind, partly by paying attention to your team's cross-cutting concerns.

Is the bigger picture one of them, or ALL of them? Photo by Soragrit Wongsa / Unsplash

Where Is This?

As a lead, you are expected to be the go-to person for the other developers on your team, whether they have simple questions, need debugging help, or just want your opinion on something. The problem you might have, particularly as a new lead, is figuring out where the thing they are looking for actually is.

If you've been at your company for a while, you probably have a good idea where all the potential resources are: the internal apps, the custom-built APIs, the company's databases, etc. If one of your teammates asks for access to these items, most likely you point them to where they need to go. But what if they need to get a resource that you don't have access to, or worse, don't recognize?

There are two primary ways to find out where something is: looking for it yourself, and asking someone else. The second is much quicker than the first, but you have to know who to ask. Asking your manager is a great start, but if that fails, asking your fellow leads and senior-level developers is the next place to go. Only once you run out of people to ask should you start looking yourself.

In this case, as it often is, preparation is key. Take some time after you become a lead to familiarize yourself with where the basic resources (databases, APIs, designs, tests, etc.) are and how to access them (e.g. credentials, URLs, people who must give permissions, etc.). The time invested in finding out how to access common resources will save you much more time down the road in not having to look that stuff up yourself.

Cross-Cutting Concerns

There are certain things that all programming teams, regardless of size, need to do of in order to complete their tasks efficiently. These include cross-cutting concerns that every codebase, every application, every project will use in some form. Part of keeping an eye on the bigger picture is learning and researching the cross-cutting concerns that apply to your team.

OMG what am I gonna do about those code reviews? Photo by Nathan Dumlao / Unsplash

An example of a cross-cutting concern would be error management. How do your team's projects handle errors and error logging? Do you have a central place to log or report errors, or are there several separate places? Does no such place exist? One of the things you will repeatedly be asked to help with is debugging, and knowing where errors go when they happen will be invaluable.

Another example might be project deployments. At my company, the lead developers are the ones responsible for creating a process by which our applications get built and then deployed to our servers in various environments (we use Azure DevOps, which makes this relatively simple). If anything goes wrong with the process, it's up to us to find the issue and fix it. You can imagine that I've become pretty handy with YAML because of this. :)

The key thing the cross-cutting concerns have in common is that they are larger than their individual projects. Learning how to manage errors and error logging will help in multiple projects, not just one. Knowing how your release process works and what kinds of issues you might encounter will be useful information for the team, not just a single developer. These are problems that are bigger than individuals, bigger than projects, and it's the job of the lead to manage them.

Other cross-cutting concerns might include:

  • Team mentoring and training (we'll talk about this specifically in a later edition).
  • Reports and logs, particularly if these will be going to upper management.
  • Filing a bug, i.e. how does a user go about reporting a bug in one of your apps?
  • Code reviews
  • Team standards and conventions
  • Database management
  • Writing QA test instructions and goals
  • Software architecture
  • Testing
  • Goals and project benchmarks

There's a lot more besides! Cross-cutting concerns are everywhere, and the more responsibility you take on as a lead, the more you have to be aware of them.

Previews and Announcements

With the release of .NET 5 getting ever closer, there were a bunch of important announcements this past week.

Quality Reads

Special Focus

Catch Up with the Previous Issue!

The Catch Block #26 - Developer, Know Thyself!
Let’s begin our Leading Large Teams series with two ideas: you need to know yourself, and you need to be ready to step in.
Exception Not FoundMatthew Jones

Thanks for reading, and we'll see you next week!