Technology improves and advances ceaselessly, new tools are created and change how people work. Some are small and simple, making people somewhat more productive. Others revolutionise the way people work. These revolutionary tools may come along only once or twice in a generation, and when they do, they tend make people uncomfortable. They can make people question their role, their skills, their future, and their place in the industry.

I would like to take a few minutes to talk about a revolutionary change in how developers work. I kindly ask the reader to reserve judgement on this topic till the end of this article, to fully understand the intent.

Developer tools have historically been hard to use, complex, and required extensive and specialised knowledge to accomplish anything beyond a simple “Hello World” program. While there have always been efforts to make this better – new tools, new libraries, new frameworks – these made the work more efficient, made developers more productive, but there were still few that could do it well.

This difficulty worked as a moat, a gatekeeper, that kept many people out. Not because they couldn’t learn, but because they had limited time. Not because they weren’t motivated, but because they had a job that took up their time. Not because they were lazy, but because they would prefer to spend their time with their family.

For those that hadn’t had the opportunity to invest the time to learn, they were largely locked out.

There are some that see this as a good thing, as it keeps those that aren’t qualified, those that aren’t dedicated enough, those that haven’t paid their dues, it keeps them out of the field. It ensures that only some can build software.

More importantly, some argue, it keeps them from making messes that others will have to clean up. It keeps them from creating work or introducing bugs that others will have to fix later.

Not all people learn the same way, not all people have the same opportunities to explore and gain skills, not all people have the time to dig into things to the same level. Most importantly, to me at least, some people would just rather spend time with their family. If a tool can help level this field, and help bring more people in – I see it as a good thing.

This is an exclusionary view that I tend to disagree with, though I’ll talk more about it below.

When these revolutionary tools are released, it doesn’t only open the door for new developers to join the field, it changes how many current developers work. It allow people to do more in less time. It means it’s easier to complete tasks. It opens the door to going home on time and spending time with loved ones.

For my entire career, I’ve always had a focus on productivity: I care greatly about the quality of my work, and that of the work that my teams do, but I also have a life. I also have a family. This means that the more productive I am when I’m working, the more time I can spend actually having a life. While I do love what I do for a living, it’s not my only priority.

When I’ve managed developers, my goal was to enable them to do their best work, and get it done as efficiently as possible. If you want a happy team, you always make sure that they can actually enjoy their life. That they don’t feel a need to be working constantly.

If there’s a tool, framework, or library that makes me more efficient – without a loss in quality – you can bet I’ll use it, and I’ll make it available to my team (if they want it). I’ve devoted countless hours to building private libraries and frameworks to allow my teams to do more, better, faster. These are some of the accomplishments that I’m most proud of.

I’ve had many debates over using new tools, and adopting technology that could reshape development. From dealing with fears about jobs being taken over by business analysts that have no background in development, to the worry of new bugs introduced by people that don’t have a traditional computer science background.

These conversations are always complex, always laced with fear & discomfort, and deep worries. Some don’t want things to change. They like the status quo. They like the gatekeeping. They like the feeling of superiority.

By now, you may be thinking that I’m speaking of a particular technology, and I am – but almost certainly not the one you’re thinking of. I’m speaking of Visual Studio¹ and the conversations I had while it was reshaping how developers work.

Visual Studio, with the ability to design a UI with a drag & drop interface, integrated debugging, IntelliSense, and a host of features that made it easy for people to build software. This new breed of IDE allowed new developers to enter the field without needing to memorise complex Windows API calls to create a window or add a button. It allowed people to instantly spot syntax errors and easily fix them. It allowed them to easily find and fix bugs.

The wave of visual IDEs changed development. It opened doors. It welcomed new developers and gave them new & gentler ways to learn and explore. It provided hands-on experience without the level of frustration that had existed. It allowed them to focus on getting things done. It allowed developers to work faster. It allowed them to focus more on what they cared about.

Yet, decades on, I still hear the refrain that “real developers only need vi.”

I’m not talking about those that use the tools they prefer – if you just love vi, good for you – but those that look down on those that use other tools². Some believed, and still do, that if another’s priorities vary from their own, they are doing something wrong. Unless you were using C or C++, you were doing something wrong. If you didn’t opt for the most complex path to achieve something, you didn’t belong.

There are still those, decades on, that see using tools that make people more productive as polluting software development. There are still those that want the gatekeeping.

I am a firm believer that each person should use the tools that are the best for them, and allow them to focus their limited time on this planet on those things that actually matter to them.

I will leave applying this to other technologies, if and as appropriate, as an exercise for the reader³.