Problems are plentiful out there in the world, but we don’t document them enough. Below are some of the ones I’ve been thinking about.

Discovery

All things considered discovering stuff online feels vastly inferior to what we have in the physical world. Whenever I order groceries online, I’m shocked by how consciously I need to remind myself of the things I want to buy. It’s a lot of work! In a physical grocery store, I walk around and just throw the things I’d like in my basket. Easier, more fun, and I can glance at hundreds of items in a few minutes. IMO this problem of inferior digital discovery applies to software and other digital-only goods as well. Lots of room for improvement here!

What discovery mechanisms seem to already work well?

• Conferences around software products with lots of vendors (think AWS re:Invent)
• 3D Games?
• Ads? (And influencers)

Ideas:

• Enterprise software influencers (is this just Gartner? What about SMEs?)
• A physical retail shop that only sells B2B software (you can walk around try it out, see how other people use it, etc.)
• Vendor-built 3D games to help folks learn about their software (B2B snapchat lenses)

Periphery

On a related note, the whole concept of “peripheral vision” only exists in very limited form on computers (mac menubar apps and perhaps social media come to mind?). There need to be more and better ways to serendipitously discover stuff.

I used to have a print subscription to The Economist. I’d get it in the mail every week and then I’d read some of the articles that seemed most interesting. Eventually, I got annoyed by all the different copies lying around and taking up space, so I switched to a digital subscription. But now I read The Economist way less! The content is the same, but this is interesting from a discovery and periphery perspective: An easily dismissible notification telling me about the latest edition is not the same as getting a physical magazine in the mail every week.

Building software takes a lot of time

Building and shipping software can take an unbelievable amount of time! It’s norm rather than exception for a 2 week project to ultimately take 6 months. It’s worth thinking about all the levers we have to reduce the amount of time it takes to write software.

Long periods of uninterrupted focus time

To make any substantial progress on any code, software engineers (me included) tend to need 4+ hours of uninterrupted focus time. If there are interruptions, or if a four hour block isn’t available in a given day, productivity dips substantially and it’s unlikely much progress is made. If we could reduce this 4h number to 2h or even 30m, I think there’d be a significant uptick software engineer productivity.

Reliable estimation is not possible

We cannot reliably estimate how long a software project is going to take. Workarounds are “double your best guess” or “assume each task, however small, takes at least half a people-week” but that’s as good as it gets.

Onboarding onto a new codebase takes forever

It takes a long time to get familiar with a codebase and become productive within it. More so than just reading code or knowing what files exist, familiarity with any sizeable codebase develops gradually over time as you make changes, poke around, and build an extensive mental model. This takes on the order of months to years. Imagine what we’d unlock if you could onboard onto a codebase in a single afternoon.

Related: It’s easier to write code than to read code. This has a whole bunch of second order effects.

Need to retain and activate extensive mental models and state

As you work within a codebase, you slowly build up a mental model of how all the different pieces fit together. The more extensive and sophisticated this mental model is, the faster and more effectively you can write code. This happens not just at a macro, codebase-wide level but also at a more micro whatever-you’re-working-on level.

As you sit down to start working away on a feature-level problem, you need to activate (or reactivate) your mental model and keep track of many pieces of mental state: “This is how these functions fit together; this is why this variable has value x; if I change this line, it’ll have these consequences, etc.”

Keeping a lot of state in your head is incredibly draining and has a high activation energy!

This problem is extremely related to the “Long periods of uninterrupted focus time” problem

Manual test writing

Tests make it easier and less error prone to ship high quality software, but they take time to write. Often they double the amount of time it takes to ship a particular feature. Part of the problem is that software engineers currently have to manually write tests. IMO at least some (and maybe a lot of) test writing can happen automatically.

A consistent process for deploying code

There seems to be a huge variety in how organizations go about letting their engineers deploy software to production. There are complexities in how deployed code rolls out, but the user-facing experience should be more consistent. Git + GitHub introduced a standard way to “make a code change” via pull requests. It would be neat to have a similar set of best practices for the UX of deployments.

Knowledge transfer

A huge boost for humanity would also be if you could actually learn from the mistakes of others. Sure, currently you can read someone’s book filled with precious advice, but wouldn’t it be great if you could receive their knowledge in a way where you internalize the conflict, the experience, the lesson learned, and so on just as well as the person who experienced it.

Every new generation wouldn’t need to start from 0 knowledge – although we would need to figure out how to unlearn all the knowledge that is not relevant anymore!

Knowing when and what to “micro-learn”

Many tiny productivity improvements in almost all of our daily workflows are completely within reach, we just don’t know about them (yet). These could be keyboard shortcuts, or swipe gestures, or really anything that strays from the core paved path you’ve adopted as your workflow.

For example, did you know that you can option click on the command line to move the cursor exactly to where you want it to go? I’ve probably spent hours hitting left arrow, when I could have been doing this instead 🤯

Similarly, you can click CTRL-R on the command line to search through your history and really quickly find a command you ran in the past.

Once you know them, these shortcuts can become essential tools in your daily workflow but you need to know about them first. The challenge is multi-fold:

• it’s hard to learn about (or google for) things you don’t know exist
• even when you do proactively decide to “micro-learn” something, it’s not like you can read through a list of all the things that would be relevant to you. You need to manually filter and that takes a lot of time
• there’s always a trade off between sticking to the path you know or venturing out to explore a bit. Exploration is less certain to bring you closer to completing the task you need to complete, and can often seem like the far inferior choice when the known, paved path can get you where you want to go, just perhaps a bit more slowly.

I would love if there was some kind of contextually aware system that could tell me at exactly the right time what tiny piece of knowledge I’m missing and then teach me.

Feature discovery

Every product I’ve ever worked on has struggled with telling its user base about new functionality that has been added to the app. Naturally, this is especially true when the product has a lot of capabilities (for example GitHub).

Users (and buyers!) of products could get even more value out of them, if they had a better understanding of how all that the product has to offer! I’d guess that it’s not rare for customers to only use 50% or even just 20% of the capabilities in a product they paid for. Sure, customers might not need everything, but I think there’s still a pretty large discrepancy purely based on a lack of knowledge.