Scope and Experience

Fair warning: this is about as broad as the range of my posts, so expect a wild flow of ideas across various domains.

A bit of feedback I receive a lot in conversations with recruiters/headhunters is that my profile is too broad. I understand that they look mostly for keywords, and I’ve never cared to SEO-ify my resume. Combine this with a person who likes to work on building teams as much as compilers, oscillates between network automation and integrating LLMs into business flows, conducts security workshops and technical due diligence, and you have a hireability nightmare. But I don’t experience it as disparate. It’s all about (user) experience.

A disclaimer

Before addressing the general thrust of my thesis, let me get the elephant in the room out: my general privilege in having to explain myself.

Now, the first thing is that I’ve been lucky enough to never truly have to worry about this. I do not pretend to be the world’s foremost authority on any of these. I do claim to have deep proficiency, but these are different things. Intellectual curiosity and a good baseline can get you to proficiency in adjacent fields rather quickly. Reaching a level of an internationally recognized subject matter expert takes a lifetime. My profile requires the former: I help solve a broad class of problems well, and I am able to connect the dots. It requires a good deal of honesty, because I need to tell people very clearly what I cannot help them with, but I don’t have a problem with that.

I also usually operate in high trust environments, working with people I’ve worked with before, and I rarely need to “prove” my chops. We can focus on solving problems together, rather than having to make me look impactful on the balance sheet.

But that’s not really what I want to talk about today, anyway. Let’s talk about user experience, shall we?

The world as an experience problem

As I pointed out above, the way I perceive all of the fields I work in, they are not as disparate as they may seem. At its heart, all of my work boils down to a study of user experience, and often those users are developers.

When I say thinking about user experience I mean thinking about cognitive load and how to reduce it, feedback loops and how to shorten them, and making the default path the right one.

Deep tech work: experience

I worked on all of my most complex deep tech work through that lens, and it might explain the weird technical gap between a lot of the things I work on.

• When working on the Carp programming language, my personal main question was how far we can take the compiler ergonomics. We combined type and lifetime inference and opened up as much of the internals as possible while simultaneously making it hopefully unnecessary for users to go too deep, and wrote a strong set of standard and standard-adjacent libraries. My main goal was to see how far I can push the ergonomics while making no concessions to runtime and performance.
• My work on Glamorous Toolkit was influenced by a deep desire to make building tools habitual by making it easy and quickly amortized. By solving this problem, navigating a system becomes about its shape, not about the shape of the tool you use to view it through.
• The recent work on cj, my minimal JIT compiler framework, has been a study of simplicity and joy. How bare-bones can the API be while still feeling like a delight? How little do we need to feel enabled to write complex JIT compilers for real languages? What if I told my users to bring their own register allocator, intermediate representation, labeling logic? Would it still work?

But this quest in exploring experiences is not limited to deep technical work.

Organisations, products: experience

My general view on user experience also shapes how I think about products and organizations:

• When I build network automation, I want to help people think about their architecture, not about their individual configurations. I want to help them make most of their fabric-level decisions directly actionable rather than having their network engineers translate that into a bunch of commands in a Junos shell.
• I start with a knowledge problem when working with LLMs. The usual problem is that there are one or more sources of knowledge with various sorting and organizing conventions, and no one can actually get to the information they need. Yes, LLMs can help solve this problem, but I’d like to spend time thinking about the way knowledge is structured and organized rather than jumping straight into discussions about AWS Bedrock vs direct OpenAI access and Pydantic vs. Agno. Both conversations matter, but we get lost in our tools all too quickly, and then never come up for air again.
• Similarly, when I think about a team’s or company’s processes, I think about how they help people navigate through the company and execute efficiently while staying true to the company’s goals (including compliance, responsibilities, and the like). I’d like to spend time observing the desire paths through the org chart and the most and least viewed parts of an ISMS and use those to guide gentle transformation. It all becomes a UX problem with the employees as users.

Once I started thinking about this, it all fell into place: everything I do is about making systems navigable by people. Sometimes the systems are technical, sometimes they are not.

Fin

As all too often, I don’t really have a main takeaway for this. I woke up at 5:30am with this thought and couldn’t let it go, so I wrote it down before the little ones would stir and replace this idea with more important—definitely more urgent—topics.

Maybe you’ve asked yourself what I’m about, and why I seem to do and write about so many different things, and maybe this might help answer it. I probably won’t send it to recruiters that want me to highlight my experience with Rust or Scrum more, though.