Photo by Regarding the .NET ecosystem, we’ve become spoiled with great tooling choices from Visual Studio, JetBrains Rider, VS Code, and NeoVIM, not to mention the extension ecosystem like ReSharper, CodeRush, and OzCode. As a result, the ability to define your development workflow and your team’s workflow has never been more varied. What a time to be a .NET developer!
With choice comes the burden of improving your productivity while not hampering the preferences of your team members. After all, all of us have years of different experiences and skill sets that no single tool can satisfy. A development tool that tries to please everyone is doomed to please no one.
So I wanted to use this time to describe my philosophy when picking development tools and why I think it’s vital for personal and team happiness and completing development projects.
Let’s get started.
Picking Personal Tools
When it comes to defining my development environment, I believe it is a deeply personal choice. I prefer the operating system I like (macOS) and IDE I work with (JetBrains Rider). Over 15 years, I’ve found the combination of tooling that works for me, but I’m also willing to consider other options as the technology landscape changes. I also understand my personal choices will not be another individual’s. So instead of arguing about personal preferences, finding ways to be a better development neighbor is more important.
In the pursuit of being a good development partner, I have a “must follow” rule:
My tooling choices should not burden other developers with my preferences.
Therefore, if I choose a tool, it must abide by at least one of two criteria:
- The tool is transparent to other team members. It doesn’t pollute the shared spaces with my preference and put my team members at the disadvantage of dealing with my “junk”.
- If my tool produces artifacts, other team members must be able to utilize those artifacts regardless of all of our preferences. (we’ll talk more about this later).
What does “polluting” constitute? If a codebase is a communal shared space by team members, my tools shouldn’t leave artifacts that team members didn’t agree to use. These artifacts include tool-specific configuration files, assets, or dependencies. These artifacts are one more burden a team must manage, which would constitute selfish behavior on my part.
In my attempt to stay on the good side of karma, a tool needs to provide at least two options:
- Assets are optional; tooling can work with or without the extra configuration.
- Assets can exist locally in my development environment without me checking the files in source control.
These characteristics allow me to make my choice and still be a good team member. Everyone wins.
Picking Team Tools
Given the promise of .NET being a cross-platform technology stack, the shared tools a team picks should reflect that value. So, for example, tools might include test runners, HTTP clients, static analysis tooling, and build pipeline enhancements. This brings me to my subsequent “must follow” rule:
Any tool a team adopts must account for running locally on any developer’s preferred environment and provide value to all team members.
So what do I look for in team tooling choices?
- A tool must provide value to a majority of team members. Therefore, a consensus on what constitutes value is essential to adopting tools. Adding dependencies is a burden, after all.
- A team tool must be cross-platform. A Windows or Unix-only tool doesn’t benefit everyone and should be crossed off the list immediately. It’s time we expect better from our team tools.
- Any tool that processes files should provide a CLI version of itself. A CLI tool allows team members to get value from shared assets even if they might not have a comparable experience an IDE plugin might provide. A CLI tool also means you can get similar results in CI/CD pipelines and locally. At the very least, the tool should be accessible to everyone via a web interface if it is a subscription service-style tool.
In a team setting, a team tool should not penalize my macOS choice, favoring a team member’s Windows experience, and vice versa. Likewise, a team member’s use of a Visual Studio extension should not hamper my JetBrains Rider experience. And ultimately, a tool that I can run in a CI/CD environment must also run locally. Adopting a tool that favors one group over another creates unnecessary friction and fragmentation. That friction leads to resentment and conflict, lowering team productivity.
Team-focused tools should also be accessible to all team members in the same capacity, as everyone should be able to manage and maintain them. After all, the team agreed on the value of adopting the tool, right? With the complexity of the modern software development lifecycle, teams should limit their risk exposure. A team tool that only works in specific circumstances and is only accessible to certain team members is a liability.
Conclusion
As .NET developers, we have a glut of choices in front of us, and while we each have our particular favorites, we also need to understand the team-based nature of software development. When we take those choices away from team members, we create an environment devoid of diversity and creativity, which I try to avoid as much as possible. The .NET ecosystem and the folks working in it should champion team productivity and create a base experience everyone can rely on, regardless of anyone’s personal tooling choices. I hope you leave being mindful of how individual choices can affect a team’s productivity and, ultimately, the vibrancy of the .NET ecosystem.
