Why standardizing on IDE might be ineffective for your team?

How beneficial it is for your team to standardize on an IDE and how this can affect engineers.

I want to start by making sure that everybody understands what an IDE is and what it stands for. On a quick Google search, you can see that IDE stands for Integrated Development Environment, and it is a software application that provides comprehensive facilities to computer programmers for software development. An IDE normally consists of at least a source code editor, build automation tools, and a debugger.

This means that we use an IDE to influence our whole development environment. So it’s not only about writing code, but a complete experience. It uses different tools to automate tasks that can be a distraction to you (linting, auto-complete, compilation, etc.) so you can focus on what is important and it helps a Software Engineer to reach that flow mental state.

Flow is a hyper-productive mental state where a person is fully immersed in what they are doing. Agile development also supports flow by working to remove non-productive work and helps a software developer to focus on tasks that bring value. For example, in SCRUM you have daily standup at a fixed hour to reduce complexity. While standardizing is beneficial for bringing simplicity and reducing complexity, it doesn’t always work with everything.

We have a certain routine when we are home, in our environment. Some of us have everything automated — when we get home we say “Alexa, I’m home” and that turns the heating on, turns on the speakers with relaxing music, and turns on the lights. Some of us don’t like that automation and we just do everything the old school way, while some of us just like to have the heating preset. The same concept applies to our development environment. When we develop, we have a certain routine that helps us become more comfortable and reach that hyper-productive mental state.

Let’s consider software development is like driving a car. And driving regulations are just like linters and other tools that help to standardize code style. If the whole team needs to follow regulations like driving 50 km/h (use 4 spaces indentation), stop on stoplights (no more than 120 characters per line) and other rules that your team defined as a code style, does it matter that you are driving a Honda or a Toyota? I believe it doesn’t, as long as it is comfortable for you and it lets you concentrate on what is important, like the road and the way to get safe to the destination. Nobody will remember that you drove a Honda when you get to the destination, they will remember that you arrived on the destination (Git/Completed Task) safely.

So I believe that the experience in software development is the same. It doesn’t matter for other team members what IDE you use, as long as it takes care of the code standards, and lets you concentrate on what is important.

Standardizing on an IDE might be beneficial for a novice developer, who doesn’t know what tool to use, so he can use the standard one. Changing that development environment for experienced developers that are used to certain tools for years might break their flow. These experienced developers will have to put much more effort into mechanics rather than solving tasks that bring value.

So, in conclusion, I believe that standardizing on IDE’s might not be worth concentrating on, but rather standardizing on code styles might. The team members review code in Git and as long as the team has a standard there, I don’t see why different developers should use the same IDE. We have continuous integration tools that make sure we reach a certain standard in Git, so we can focus on bringing value faster. So I would concentrate on those tools more, rather than changing the environment of a software engineer.