Low Hanging Fruits, 2024
I've been in Informal Systems since 2020, and contributing since then to the development and expansion of the interchain. Below are some areas where there are low-hanging opportunities for me to improve in 2024 as part of my work. Another way to look at this list is as a compilation of activities where my use of time was sub-optimal throughout 2023.
Roadmaps. Crafting the roadmap for IBC and CometBFT took a lot of effort. I wish I could dedicate in the next year more of my time to value-add work, and less to planning and roadmapping. The coordination overheads, preparations, presentations, write-ups, persuasive work, housekeeping and tracking the evolving docs, addressing comments and asking for review, waiting, clarifications, nitpicks, naming decisions, estimates, estimates margin error negotiations – I want to do less of this.
When it comes to roadmaps and plans, I think v0 of a roadmap plan is better than v1, v2, or any subsequent refined version. You do the v0, then you adjust for X (a certain concern) to get v1, then you add comments and review to get v2. Then you execute on it as you go along, and things change so often that it makes you wonder if even v0 was beneficial after all.
Instead, I want to try something else this year: stick to v0 and proceed directly from there to execution, short-circuiting any refinements.
To be clear, I think roadmaps are beneficial. Doing roadmapping work changes how you think about priorities throughout the rest of the year. It provides a strong base of certainty with respect to capacity and priorities. So a roadmap is necessary. But doing 20% of the roadmap work (i.e., very rough, with order-of-magnitude estimates as it appears in a v0) gives 95% of the benefits. That’s how I want to approach roadmapping in 2024.
Adoption cycle. I was not able to find a way to incentivize (or encourage, or motivate) the interchain ecosystem to move faster on adopting CometBFT new versions. As of today, there is no mainnet on CometBFT v0.38 that I'm aware of (ref). The impact of this valuable product is still too tied to the release schedule of other elements of the Interchain Stack. We managed to address most important internal sources of risks, but this one is external, and is likely one of the biggest risks that CometBFT faces.
User interviews. I have not done sufficiently many user interviews. The # of user interviews I do may be a dumb metric, in the sense that it doesn’t track any specific outcome in isolation. Nevertheless, user interviews are the “bread” of product work. I think I did around 30 of them this year, and probably a better target would have been double.
Engineering. I did insufficient technical work. I think it would have served my role better had I rerouted some of my efforts to more dabbling in the code, fixing some specs, reviews some PRs in depth, maybe pair up with a colleague on a deeply technical fix.
Conferences. I went to 2 Cosmos conferences (Cosmoverse and Gateway) and 1 non-Cosmos conference (Stanford Blockchain Conference). I’d like to attend more non-Cosmos conferences, with broader audiences and ideally more focused on industry, standardization, real-world assets, adoption, impact, or DePin. These are very important topics. The year 2024 is about pushing the maturity of CometBFT and IBC, so my pick of conference attendance should align with that.
Product sense. This is probably the most difficult one, but still a low-hanging fruit. I have found it challenging to demonstrate product sense in CometBFT or IBC (my areas of focus) since these two elements are so coupled with the other parts of the interchain software. Meeting user needs by a feature or a fix within the confines of the CometBFT repo (or IBC-rs, or Hermes relayer) is too often impossible because of this coupling. Thinking of a single element of the interchain software as a product is very difficult, therefore. Two examples where I stumbled are state sync or the relayer incentivization problem. Such problems are very complicated with a lot of dependencies, so they entail a lot of diagnosing overhead. We rarely get past the diagnosing stage, let alone arrive at a sustainable solution.
There is no simple way out of this one. The problem and solutions are stack-wide. What I'll try is to accept the situation as it is and learn to work holistically – or across multiple parts of the stack – as the situation demands.
