Nomic Labs DevX: Prioritizing projects

Our approach to road-mapping the improvement of the Ethereum developer experience

As mentioned in my previous post, Nomic Labs has been working closely with the Ethereum Foundation in coordinating the ecosystem to drive improvements in developer experience. While that post was a high-level description of what kind of things we do in DevX, this one will describe the way we’re prioritizing issues and picking projects.

The main framework we use for this is “product drivers”. These are high-level directions to steer what we believe the Ethereum platform should improve upon and are, therefore, our compass for the DevX effort. They are derived from identified technical issues, user feedback, and our own intuition and meant to help us understand what to prioritize and whether we’re working on the right things or not. In a way, these are product objectives, but not objectives in the sense of something that can be achieved and filed as done — they’re simple, broad, vague, and flexible directions by design.

The list of product drivers is meant to be dynamic. We’re starting with an initial set that we assume to be incomplete and imperfect in different ways. As we keep learning more about what needs to be worked on to improve the developer experience on Ethereum, we will add more drivers, remove some others and break down existing ones into narrower items — but they need to be few to be useful. Changes to this list should be sought and celebrated, as they should be a reflection of progress in our understanding of developer needs in Ethereum.

If a potential driver doesn’t encompass many projects or doesn’t generate a significant direct or indirect impact on developer experience, it shouldn’t be a driver. Drivers are also not meant to perfectly classify everything we do. It’s fine if a project doesn’t clearly fall under any specific driver or if it actually hits multiple drivers.

DevX Product Drivers v1.2

Speed: Make the contract development feedback loop faster

Developers write code, the compiler builds it, the automated tests run on a local development network, the developer looks at the results and decides what to do next to start the cycle again. This is generally the core process of building contracts, and software in general. The amount of time this cycle takes sets the pace for developers, and the faster it is, the faster developers can work. Frustration levels increase non-linearly with the cycle’s length. Currently, this is too slow in Ethereum, but there are several ongoing efforts to make improvements across the components involved. Generally, Buidler already provides a significant speedup in this process.

Visibility: Increase visibility to what’s happening at the EVM/Solidity level

The last step of the development feedback loop is an assessment of the results of running the code. Generally, the results are either a confirmation of successful execution or an error message of some kind. This error message is the developer’s core communication interface with code. When there isn’t a meaningful error message, it’s like getting feedback that you’re doing something wrong, but without specifics on what the mistakes are. Both the EVM and Solidity have historically been obscure in terms of what’s going on inside the hood. Developers have worked for a long time with a black box, as we previously described in our stack traces announcement. When something behaves unexpectedly or fails, it’s historically been very challenging to figure out why. This isn’t just about error messages but encompasses the need to improve the entire debugging cycle with the specific aim of increasing visibility into code execution.

Editing: Improve Solidity editing assistance across major editors

Programming text editors and IDEs can make developers more productive, there’s no doubt about it. Currently, the experience of writing and editing Solidity with a specific selection of tools is not the worst it could be, but there’s a lot of room for improvement and little reason for it not to be as good as the experience of working with other languages.

Tooling: Lower the barrier to entry for tooling development

Building tools for Ethereum is pretty hard. The most advanced features take truly heroic efforts (shout-out to Tenderly for their near-insanity projects). It takes a lot of accumulated knowledge; there’s little documentation to work with the core components in the platform, and there isn’t a lot of stability in the building blocks the tools need to integrate with. This massive barrier to entry must be lowered as much as possible through processes, standardization, better policies, and more coordination. The potential compounding benefits of these are incredibly high.

Composability: Reduce friction when integrating protocols

DeFi developers are pushing contract composability to its limits, and they’re are dealing with some really rough edges when integrating protocols both off-chain and on-chain. It’s currently like unstructured manual dependency management without versioning, and incredibly tricky to reproduce testing scenarios. Solutions are lacking across the board, and by making this entire process more efficient, there’s clearly a lot of value to unleash within the ecosystem.

Value ≠ Impact

Even with clear guidelines to prioritize projects, shipping large chunks of value to the ecosystem isn’t as obvious as it may seem. Deciding to invest in a given project is all about nuance. While it’s tempting to go around improving anything that has significant room for improvement — after all, isn’t any technical improvement going to improve developer experience in some way or another? — this isn’t an effective way of allocating finite resources.

Improving a piece of infrastructure that existing codebases won’t be able to adopt because of migration costs outweighing benefits, won’t produce as much impact as something that can be instantly adopted by everyone in the ecosystem; like better editing assistance or stack traces.

When improving something, how is the improvement actually benefiting developers? Who is this developer? Are they a beginner developer or an advanced developer? What kind of contribution are they making to the ecosystem? What’s the impact timeline for this? Are there additional support efforts needed to catalyze this value? Education? Exposure? Integrations? What is the user’s circumstance around the problem that this improvement is solving? How are they limited? Are other limiting factors actually completely eclipsing this improvement? Is this improvement a regression for others? How does this impact future potential improvements? If we’re successful at deploying this across the ecosystem, how permanent is that deployment? Can we iterate? Can we lower adoption costs? What about using this as a trojan horse for something else that would be too inconsequential for users on its own, but in conjunction with something else that may go through and enable all sorts of things? What are the risks involved?

APIs and technical infrastructure in general are also products that must be explored from many perspectives. A seemingly obvious move may actually be counterproductive, just like a simple move may unlock huge value.

A lot of things go into consideration when deciding whether to take on a project or not, and having a holistic big picture perspective is the most important part in allocating our resources.

If you’d like to work on improving Ethereum developer experience, these are some clear directions for you to explore. Let us know if you start working on something along these lines!

Coming up…

In the next post, I’m going to write about the specific projects we’ve been working on since we started focusing on developer experience. Stay tuned!