Four developer tooling areas I'm excited about

Since I’m a language and developer tools geek (I do this stuff for a living!), I like to think about where developer tools and languages will be in the future. This post is one of those kinds of future-thinking posts.

Before I dive into a bunch of stuff that I’m excited about for the future, I’d like to acknowledge that modern developer tooling as most people know it has a lot of room for improvement:

• Compilers and interpreters are too slow
• Language services are too slow and take up too many resources
• UX in IDEs ranges from great to terrible no matter the IDE or language or environment
• Git still isn’t that easy, nor is any source control system
• Modern web tooling is an absolute mess and way too hard to wrangle
• Modern cloud tooling is an absolute mess and way too hard to wrangle
• Mobile development is really hard and time consuming
• Cross-platform apps that aren’t web apps is too hard or too brittile or too restrictive depending on the stack
• Data cleaning lol

There is a lot of opportunity in just improving the small list of things above. Doing that would make millions of developers happier and more productive, save business countless dollars in wasted productivity, and probably make a company that improves these things a bunch of money. It’s a worthy goal to focus on making these things better, since they’re still some of the foundations of developer experiences.

The rest of this post will cover much more aspirational things. Some of what I talk about solves very real problems for people today, but an underlying theme is that they fundamentally change the game for developer experiences. They are also not exclusive of one another, and I envision a future 10-15 years from now where they’re all interplaying in interesting ways.

I think that if there’s one movement to “democratize” app development (coding?) it’s the so-called “Low Code” movement. There’s a bunch of people out there who generally know what they want, but they don’t have the ability to encode that into a runnable program.

The world’s most successful low code environment today is Excel, and for the vast domains it operates in, it’s king. But not everything can be solved by a spreadsheet. Low code systems for general app development could end up being a really big deal. There aren’t enough developers coming in through “the pipeline”, so this can change “the pipeline” to include people who aren’t getting a CS degree or doing a bootcamp.

The implications for developer tools are fascinating. IDEs today aren’t meant for non-programmers. Some questions come to mind:

• What does an IDE for a non-programmer look like? No, literally, what does the actual UI look like?
• Where are the major pain points/UX bottlenecks going to arise?
• What sorts of things are fundamentally difficult from an ergonomics standpoint?
• Where do natural performance bottlenecks arise?
• Where would you be able to use these IDEs?
• What does it mean to have extensions for these IDEs?
• What does version control look like for this stuff?
• What does CI look like for this stuff?
• How do you manage your dependencies? What even are dependencies in this world?

Of course, actual software developers will inevitably need to be involved in “low code” programs. Eventually the business requirements get complicated enough that you need to write some code, just like today. Some other questions come to mind:

• Is a custom program for a low code application an extension?
• What does the IDE look like when you’re in “programmer mode”? Or do you need a different set of tools?
• What language(s) can you extend something with?
• What does “IntelliSense” mean in the context of the application?
• Can refactoring tools work at the UI/component level as well?

The least inspiring version of the above questions is “basically like Excel VBA” where you just get a text editor in the application. But I think a lot more interesting things will be built.

Another area of opportunity here is going to be platform and vendor neutrality. Currently a lot of effort is being poured into this space with vendor lock-in. It’s a business model that works, and may ultimately be the future of this space. But I’m a big believer in platform and vendor neutrality for programming systems and tools. In general, at least in the current world of developer tools, platform and vendor neutrality always comes out on top. Programming languages have to be cross-platform now. It seems like every organization is trying to adopt Docker and Kubernetes to some extent. The most popular toolsets are available everywhere. The most popular code editors are available anywhere and don’t lock you into a particular OS or cloud provider or something. Will the same be true for low code systems? I don’t know.

I’m totally jazzed on GPT-3 and what its successors will enable for developer tools. Yes, I’m also scared of some of the dangerous implications of this stuff for society as we know it. But ethics in AI isn’t my wheelhouse, so I’ll defer to actual experts on that kind of stuff. I do know a thing or two about developer tooling though, so I’ll write about that.

So much about developer tools that we know today is deterministic in nature. Completion lists (IntelliSense), tooltips, quick fixes, and code navigation were game changers over the past two decades. There are still lots of improvements to make to these kinds of tools, but I think that making improvements there is also a game of diminishing returns. I recently added a feature to enable IntelliSense tooltips to pop up with the space bar when calling F# functions , and it’s been well-recieved and I view it as essential for programming in F# now. But it’s not really any different than the existing IntelliSense that you get when you call a method. All I really did was extend an existing feature into a little bit more of the language. I didn’t fundamentally change the game for F# programmers. Diminishing returns!

I’m imagining a world where deterministic tools are basically done, and they work exceedingly well for the majority of developer tasks. What comes next? I think it’s probabalistic tooling.

I can think of two ways to break this up:

• Tools to help me write code that’s actually solving a problem
• Tools to help me automate boilerplate

First up, what I could get help with when writing the code that solves the problem:

A lot of code I write is actually solving a problem, and if I can have some tools to make my code better then I will definitely take them. Having a tool that can suggest certain patterns that are statistically likely to be the right approach would be great. Or maybe I’m using a tricky API that, if misused, is a security vulnerability and a tool can catch that for me because it was trained on many other uses of that API. Or maybe there’s a known database of security vulnerabilities with writeups it could be trained on. There’s no replacement for domain knowledge, but not everyone is a domain expert and it’s better to have tools for this kind of stuff than not. I’d certainly feel happy to have something that usually suggests something correct than have no help at all. If there’s a system where I can input how useful the suggestion was, I can contribute to making it even better.

Next, there’s tools that do away with boilerplate:

A lot of the code I write is also not actually solving a problem, but writing boilerplate nonsense because in a software system that’s complicated enough, I usually don’t have templates or snippets tailored to my domain sitting around. Tooling that could generate this stuff, tailored to what I’m doing at the time, would be such a time saver. Maybe that means generating some data types a certain way because the library I’m using expects them to be there. Or sometimes there’s a common (but verbose) pattern for using an API where I can have a bespoke template generated within the context of the other code, then put markers in my editor where it thinks I should double-check that the code is right. There’s probably all kinds of other “smart templating”/codegen applications I haven’t thought of.

I’m excited for a suite of probabilistic tools to do the kinds of things I mentioned, and I’m sure there’s many other applications I can’t think of right now. They may not always be correct, but more tools could be built around them to suggest to me when I need to double-check something before committing the suggested code. All of this would make me more productive and probably allow for more developers to work in specific domains where they can’t today.

And this doesn’t even get into how this could intersect with the Low Code systems. People are already prototyping generating application designs in Figma with GPT-3. Why not have a way to generate a whole application that you can then spend time tweaking? Why spend all this time putting together the base of an application when you could have it generated for you? Then you, either a developer or a non-developer, can tweak the important stuff and spend your time more effectively.

The amount of code in the world is absolutely exploding. It’s been exploding for a long time and the amount of code is only increasing as more software developers are minted, organizations continue to grow their software businesses, requirements keep coming in, the world evolves, etc. If you’re lucky enough to have the time and capacity to effectively manage all the code you work in yourself (or with your team), good for you! You’re living the dream, so keep it up. I don’t think most developers get to live in that dream.

The sheer amount of code in the world is a huge opportunity for developer tools. We’re used to things like navigation and renaming in the specific codebase that we work in. What if we could do all of those things, but across all codebases in an organization? Some Googlers and Facebook developers also get to experience what that stuff is like in their companies’ home-grown systems, but if they leave that environment they don’t get to play with tools like that anymore.

Imagine there’s a big security vulnerability related to configuration files that’s just been announced, and you need to address that across your entire company. You might have tens or hundreds of thousands of these files. Millions? Not unreasonable. How do you check each one to see if they’re vulnerable, and if so, apply patches? If that doesn’t make your palms sweat, then you haven’t been in a big security compliance push across a several-thousand-employee organization before!

A tool that could let you deal with that problem would need to fundamentally re-think how search queries across codebases work. It would need a way to efficiently find and surface results that are actually correct. It would need to efficiently and correctly apply batch changes. Some questions arise:

• How would you run that query?
• How is such a system even set up in your organization?
• Would a prerequisite be that code is hosted somewhere else?
• Are there better ways to make batch changes beyond primitive text changes?
• Is there a way to test and preview batch changes?
• What editor is used when making a sweeping change?
• What if there was a way to monitor against the kind of change you made so that the issue doesn’t come up again?

This is just one scenario but it makes be excited thinking about how to build a system that could do this kind of stuff well. With the rise of supply-chain vulnerabilities, I’d be willing to bet there’s a lot of money to be made in this space.

Some more questions that come to mind:

• Would this system be tied to another system where regression tests can run against an entire company?
• Could this be used to better automate upgrades (e.g., nodejs library versions) across a company?
• Could this be used to have a more uniform set of dependencies across a company, since it’d be easy to query and change them?
• What other things could be scanned aside from code vulnerabilities?
• Could this system be utilized to track code performance metrics across a company and make recommendations to teams on how to write more performant code?
• Would this be tied into an IDE? Would it come with an IDE? Would this mean you could have an IDE that works across an entire company’s codebase?

I’m sure I could come up with more questions given some time, but these are what pop into my head immediately.

The thing about code size is it’s a very real problem today, and it’s going to get much worse in the next decade. I’ve seen this happen in my own work, where I’ve dilligently worked with people to measurably improve developer tooling across several important metrics for years. But complaints still come in, and sometimes people will even say things like “the compiler/ide/tools keep getting slower” when they’re objectively faster with each release! The size of code is increasing a rate that it’s really, really hard to keep up with in today’s programming tools. I’m not a finance person, but this feels like a multi-billion dollar problem to me. I’ve seen what it’s like when you’re encumbered with the codebase you own, and it’s not pretty. Having tools to reign in that complexity are going to be essential for software systems to progress moving forward.

And finally we have reproducible developer environments. To me, these feel like a sleeper technology that’s going to ramp up for a decade in usage until, one day, everyone will be “behind the times” if they’re not already using them. I see it as similar to git (in the era of widespread CVS, TFS, SVN, etc. usage in industry), where the possibilities are endless, the model is superior, work evolves around it as an ecosystem builds up around it, and then it’s the new normal.

Reproducible developer environments center around one central premise: you just create an environment in the cloud to build stuff when you need it.

When you need to write some code, you spin up an environment and you write your code, debug it, do whatever. You then push your changes to a branch. Then the next day, you just create another environment against that branch with the same context. Critically, you are not:

• Going back to that same environment from the day before (no finding your environment in some dashboard somewhere)
• Managing a complex, stateful set of tools on your local machine
• Re-running build scripts or docker build to re-set up your environment
• Constantly switching things like runtime and SDK versions based on the codebase you’re working on
• Massaging some kind of build tool or runtime or set of packages so that it stops acting funny

You’re just spinning up a new environment in the cloud and solving problems with code. This has huge implications!

For starters, the nightmare of onboarding on engineering teams (especially if they’re remote) could be more or lesss solved. New developers just click a button on GitHub or Gitlab (or some other source control host) and they can start writing code. Or if they prefer, maybe it’s a button on the local IDE of choice. It doesn’t matter, the point is that:

• The code didn’t have to be downloaded
• No tools had to be downloaded
• No huge swath of packages had to be downloaded
• No finnicky environment had to get set up
• No tool had to get pointed at the right finnicky environment
• Nobody had to wait for their build tool and bespoke scripts to finish doing their thing

This is a serious time saver when onboarding onto teams. But it’s not just for onboarding!

Do you work at a place where you program against a particular environment and everything, from your build tool to your packages and your runtime environment, is consistent across all of your codebases? Well congratulations, you’re in developer nirvana I guess. Most people have a cobbled-together set of build tools, packages, runtime environments, and IDEs that they all try desperately to maintain as they work on different projects, and they waste incredible amounts of time on that.

What if you worked on different Python apps with different dependencies running against different Python environments, and you didn’t have to remember to run the right commands and click the right buttons in your editor to get everything working correctly? Instead, you just clicked a button and spun up an environment isolated from everything else, with the right tools and packages and runtime environment for that codebase?

That isn’t some dream. It’s actually possible today, and it’s hopefully only going to become more capable and widespread over time.

Imagine you’re reviewing a pull request that makes visual changes to an application, and you don’t need to either (1) clone and build that branch to see what the changes actually look like, or (2) set up infrastructure to build a staged version of that app on every commit to a branch. What if it was just pre-built and you got to open the code for that branch in an isolated environment and run the app from there? No time wasted cloning things, and no need for bespoke infrastructure. Just easily review code and test out a pre-built app in an isolated environment.

Some more questions come to mind for this kind of work flow:

• Where is the “local” database? How is it deployed and managed?
• How can these systems effectively scale up and down hardware based on CPU and memory requirements?
• Could this come with a guarantee of a more secure supply chain?
• How would compliance for things like HIPAA play out in this sort of world?
• What would a marketplace for cloud-based, reproducible developer environments look like?
• Would this be a way to achieve vendor lock-in, or would vendor neutral tooling win out?
• Will web-based IDEs get good enough to have people abandon local IDEs altogether?
• What kind of new developer tooling features could be built when everything is in the cloud? New kinds of code analysis?
• Would this enable the third area (Cross-codebase search, navigation, changes, and insights) to be more effective?
• What would administrative tools (i.e., tools for dev leads and IT staff) look like?

I think there’s a lot to figure out in this area, and I’m sure a lot of developers need convincing to just move everything to the cloud. But I think we have the technology to enable it and I think it already solves some very real problems today.

By the way, I actually use this kind of environment for this website and some OSS projects that I maintain. It works exceptionally well for them and it’s already a step up from using my local machine. If I can get them to work with the main codebase I work in, I’m never going back.

I wrote about four areas, but I’m sure there’s more. Something will certainly happen in the next decade that nobody could predict, and it will take the developer tools market by storm. I’m definitely excited to see what it might be.