Dimitri Glazkov

The rise of makersseven days beforeIt seems pretty obvious that there is some sort of cyclical nature…Live as our customer

· 3 min read

Development environment for rapid experimentation2023As the final challenge, I worked out the best practices for the…This principle is something that feels very intuitive at first blush, but in my experience, is rather challenging to adhere to, especially as a team.

The structure of a principle2021We had a bit of weather recently, and while waiting for electricity…Polarity-based API layering2021While discussing API design, one pattern that caught my eye was polarity-based…I will present this principle as resolving a tension between two forces that are very familiar to me in the realm of developer experience. I am pretty sure that these forces are still present in any other product development, albeit they may have different specific traits.

Doers, Thinkers, and Magicians2023I’ve been reflecting on my experiences of working with developers and developer…When building developer products for others, we often have a situation where the development environments that our customers have are different from ours.

Aircraft Carriers and Zodiac Boats2024An insightful conversation with a colleague inspired me to articulate the distinction…They may use different stacks, build systems, or apply different processes from ours. Conversely, we may have our special tools that we’re used to and our particular practices that we employ to be more productive.

Chances to get it right2023In the world of technology, there is this concept of shipping: the…This difference forms the basis for the tension. Clearly, to ship a product that my customer loves and is willing to adopt means that I need to understand their environment. I need to know deeply the problems that they are facing every day: what is difficult? What is easy? Where can I help?

No ship ums2023I’ve been thinking about the path that software dandelions take toward becoming…At the same time, I have my own environment that I am very comfortable in, honed by years of practice and incremental improvements. This is the environment that works best for me. This is the environment that I understand deeply, with all its quirks and idiosyncrasies.

The platonic ideal here is that I have it both ways: I deeply understand both environments, am able to hold both of them in mind, and develop for one while working in another.
If you can do this, kudos to you. But more than likely, there’s a bit of self-delusion going on. Based on my experience, this is simply not possible.

Separating cargo from the train2023I’ve been puzzling over a problem that many engineering teams face and…Instead, we subconsciously lean toward problems that we encounter in our environments, and tend to be blind toward the ones that our potential customers have. When we ship a thing, it looks like an alien artifact. It appears to solve problems that our customers don’t have, or try to solve their problems in weird, unworkable ways.

Imagine you’re an alien who was hired to be a chef. You’re asked to cook for humans. You can’t eat human food, and some of it looks revolting, honestly. Fried eggs. Blegh. How likely are you to cook something that humans will like?

Growing dandelions2022Effort to copy is an adjacent concept. How much effort does it…This tension grows stronger if the difference between the environments is large. Putting it very bluntly: if our developer experience is so different that it feels like an island, we can’t build developer experience products that others will love — or even understand.

Stages of customer-centric maturity2021While riffing on customer-centric mindsets and the veering toward first-order effects pattern,…To resolve this tension, we must live as our customers. We must strive to shift to as close to the same environment as they have. If our customers use Github as their primary tool, we’d better use Github, as well. If the customers we target mostly use Fortran (bless them!), well then we must learn and adopt it as well.

The waterline2023This one is a very short framing, but hopefully, it’s still useful.…Applying this principle is usually super-uncomfortable at first. Nobody wants to abandon their well-worn saddle. The new saddle will cause cramps and sore muscles for a while. Expect a lot of pushback and well-reasoned arguments to return to the trusted old saddle. “This bug tracker sucks! I can’t even use keyboard shortcuts to navigate between issues! Our is so much better!” “OMG, this build system is arcane! What is all this XML stuff?! I thought we were in the 21st century?!”

The Bootstrapping Phase2024I think I have a slightly better way of describing a particular…The tension between growth and control2023I alluded to this tension before, but it was somewhat buried in…There’s a kind of test that is built into this struggle. We signed up to build for these customers. Do we actually want to do that?

Loops: dead or alive2022There are two important shifts to consider when examining a setting. The…Build a thing to build the thingfour days after, links hereWe also adopted the “live as our customer” posture and used only…If the answer is still “yes”, we will find that we will be better off in the long term. We will have a much deeper sense of what our customers need, and where the pain points are. We will be able to spot them early and build things that they want to use.

Show 1 comment
  1. Build a thing to build the thing – Dimitri Glazkov linked here · August 3, 2023

    […] also adopted the “live as our customer” posture and used only the tools that were available outside of […]