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.
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.
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.
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
- 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.
- Announcing .NET 5.0 RC 1 (Richard Lander)
- Announcing Entity Framework Core (EFCore) 5.0 RC1 (Jeremy Likness)
- ASP.NET Core updates in .NET 5 Release Candidate 1 (Daniel Roth)
- The future of .NET Standard (Immo Landwerth)
- Announcing TypeScript 4.1 Beta (Daniel Rosenwasser)
- GitHub CLI 1.0 is now available (Amanda Pinsker)
- Azure Static Web Apps with .NET and Blazor (Aaron Powell)
- Don't get burned by missing await Calls for Async Code in ASP.NET Core Middleware (Rick Strahl)
- How To Be Professionally Visible And Valued As A Remote Worker (Leah Ryder)
- Cross-platform diagnostic tools for .NET Core (Scott Hanselman)
- Browser Memory Limits (Eric Law)
- Three Ways to Help Developers Embrace Testing (Alyssa Lydon)
- Code is a coastline (Jessica Kerr)
- Priorities (Joseph Guadagno)
- .NET Performance Optimizations Don't Have to Be Complex (Steve Gordon)
- Padlocks, Phishing and Privacy; The Value Proposition of a VPN (Troy Hunt)
- How I Self-Published a Programming Book and Lived to Tell About It (Michael Shpilt)
- Tools should not only be for experts – they should turn us into them (Christian Heilmann)
- Why use MediatR? 3 reasons why and 1 reason not (Derek Comartin)
- Twitter is looking into why its photo preview appears to favor white faces over Black faces (Kim Lyons) - These kinds of tests are all over Twitter right now, and the appear to show that the image preview algorithm favors white male faces over just about anything else.
Catch Up with the Previous Issue!
Thanks for reading, and we'll see you next week!