🥳 2024 Developer Tooling & Infra Predictions
The last fundamental tools get reworked, "Cloud to Code," and more.
Hello! Happy New Year! 🥳
I'm embracing my inner VC and forcing myself to share four predictions around developer and infrastructure for 2024. Next year we’ll see how I did! If you've been thinking about the same areas, let's find some time to catch up.
1. The last "fundamental" developer tools get reworked
In 2015 it was considered "unheard" of to ask a developer to make a shift in a core part of their tooling - especially an editor. Yet, Visual Studio Code did just that.
Since then, we've seen other core pieces of a developer's local environment be upgraded. Zed is differentiating in the editor market through performance and collaborative features1, Warp2 and Fig have done the same for the Terminal, and Bun and Deno are re-invigorating the conversation around runtimes.
While I could go on for a long time about all the core things that have changed for the better in the last few year, there's a few key areas that haven't changed in the last ~decade. I think we'll see people go after them in 2024. A few examples:
Pull requests. Given that we're moving toward a world with collaborative editors (with coworkers or with copilots), the nature of our review tooling will change. The pull request will not longer be the only place for "code collaboration."
On call schedules. This is another area that hasn't changed much in the time I've worked with engineering teams. It's still entirely manual and prone to human error. As we get "cloud to code" we should also have more information about who will be able to solve problems and why.
Nonfunctional requirements. There's still a lot of engineering that goes into "non-feature" work - like accessibility, localization, and performance. Lots of the improvements here are predictable, and now seems like a great time to reboot them.
2. "Cloud to code" for developers
In 2023, Cybersecurity professionals talked a lot about "Code to Cloud - the ability to connect insights from the developer environment to application runtime, contextualizing alerts and offering remediations to effectively prevent risks and stop breaches."
In 2024, developers and operations professional will start to talk about "cloud to code" - developers having production-context while writing code. This was part of the original intent of the observability movement (specifically traceability, rich context, and end to end instrumentation from each user's perspective), but today most developers are functionally still writing code completely separate from production.
There's a great baseline to build on top of - the CNCF OpenTelemetry project. To contextualize, ~6000 companies have contributed to Kubernetes, and 1200 have contributed to OTel. Using OTel provides lots of data that can be surfaced to developers in interesting ways. Some of the earliest GenAI devtools pitches centered around using OTel data to write unit tests (think tracetest + LLMs).
"Cloud to code" can go way further than just generating tests. We shared one hypothesis of how to do this in a standalone with Darklang’s trace driven development. The benefit of trace driven development was massively shortening feedback loops for developers.
In 2024, we'll start to see a lot more "cloud to code" for developer tooling that can be added to existing systems, especially now that we know that real time feedback loops and flow are two of the three core components of developer experience.3
3. Fitting into existing user experiences is the key for stickiness for AI products
One of the huge GenAI success stories is Github Copilot. More than half (56%) of professional developers in the StackOverflow 2023 survey use it, and it makes them far faster.
I hypothesize that the biggest reason for this is that copilot integrates seamlessly into what the developer is already doing. Before copilot, Most developers already have some form of autocomplete, and there's no big "I go to the AI app" or "now I run the AI" - it's a much better form of what existed. There's little need for the user to think about changing their behavior.
From what I've seen so far, most of the other "AI" products don't have this same style of interaction. Zach Lloyd elegantly described the interaction with most GenAI interfaces today as - "ask and adjust.” This model matches my experience with using tools to write, generate images, make slides, make music, and make videos. In the long run, I think people will be able to change to "ask and adjust." In fact, "ask and adjust" might be easier than our existing models.
But in the short term, we've already learned the existing models. I think the winners will have products that fit into the existing workflow vs. asking people to learn something new. Having something that helps in the tool you already write in (Microsoft Word, Google Docs, Obsidian, etc) is more effective than drafting, asking ChatGPT for feedback, copying back out to edit, back in to ask a new question, and so forth. In the short run I think this is a strong advantage for incumbents.
4. Leaner teams - especially around engineering management, PM, DevRel, and design systems.
Right now, the impact of ZIRP (zero interest rate policy) is mostly discussed at a "macro" company level around future rounds of financing and layoffs. As the changes percolate, we'll see expectations change for a variety of lower tier management/IC roles.
Engineering management - During the ZIRP time it wasn't uncommon to hear from engineering teams that they wanted their manager to have ~5 reports. I don't think we'll be seeing many more 5 report systems. The difference is between 5 and 8 reports for a 1,000 person IC engineering org is an entire level of hierarchy and about 100 people (8%). We'll also see a corresponding compression in the number of "director" roles available.
Product management - It's been easy for "product management" to proliferate as people want to grow their teams. When this happens, we wind up with people who have really small scope - frankly, a lot of product managers should be called feature managers. Or, we end up with people who don’t have any accountability for end impact. We'll see teams widen scope with fewer PMs, or give more responsibility for business outcomes (like Airbnb did). Like with engineering management, there were also be compression in PM management roles.
Developer relations - In recent years we've seen this role split into several with different titles/responsibilities: developer marketing, developer relations, developer advocacy, and developer PR. We've also seen more "celebrity" devrel with people who spend most of their time on the speaker circuit. Given how much developer tools are being evaluated by serious adoption vs. pure developer numbers, I think the profile will switch and we'll expect more quantified activities vs. PR.
Design systems - This tweet has been living rent free in my head all year. Design systems make a big impact on teams being able to move more quickly. That said, I think we'll feel more of a push towards headcount being applied directly into product areas. Design teams will have specialists who help build the system, but I'd guess that the maintenance would be work that a designer would do in addition to feature work.
Of course, I couldn’t fit everything into a few predictions! If you’ve been thinking about what’s next for devtools and infra, I’d love to hear your predictions too.
I’ve been a long time believer that all software will be collaborative - and this will definitely continue into 2024. This was another piece on the topic I enjoyed recently.
I have a small angel investment in Warp from before I joined boldstart - huge fan of their product and team!
More on flow in this talk, more on feedback loops in this talk at 9:00, and here’s the 2023 paper proposing that these are two of the core components of DevEx).
Can you talk more about how a11y, performance etc development can be improved using GenAI?