escape delta
A moment of conceptual breathing room by putting forward a well-articulated, divergent view could save a ton of resources later.
A moment of conceptual breathing room by putting forward a well-articulated, divergent view could save a ton of resources later.
I’ve been quarantined from my dojo a bit too long, so I took matters into my own hands last month.
I’ve studied many performance rubrics, skill trees, and advancement systems for engineering departments. Boiling them down to core principles can bring clarity when you’re up to your eyeballs in criteria, factors, and value statements.
When you’re building a software product, time always feels like your enemy. Co-opting an existing feature for a new use can feel extremely clever, like you’ve sidestepped a ton of work. But it doesn’t scale, it adds friction, and it adds danger.
As a white dude who can smoothly “pass” as straight and grew up with strong, educated parents in a very stable environment with a strong safety net, I had the privilege of approaching social power structures however I liked. And I chose deeply irreverent.
To me, credibility as a leader is fundamentally whether you’ve convinced me our interests are sufficiently aligned and whether you have the skills & motivation necessary to keep them that way.
Your company isn’t a family. Every time I hear someone describe their workplace as a family, it’s a red flag. It means one of two things: You’re squeezing people, or you’re earnest but inexperienced.
Shipping new features feels like it’s increasing the “moat” around your product because just look at all the time and effort it took. There’s just one problem: Features aren’t a moat.
I recently read “Why I wouldn’t invest in open-source companies, even though I ran one” by Wolfram Hempel and started to write a very long comment, but decided I’d just publish my own counterpoint instead.
I’m lately watching The Great British Bake Off. When I thought about why you couldn’t do a similar show about programming, I realized the hurdles to televising it are the same hurdles teams face anyway.
Why do I think so much about how people interact online? We’re at a rare moment of a tectonic shift in one of the great mysteries of the world: human society.
I don’t think many of us understand what a community is or how to support one. We’ve built a lot of software to help people talk, and very little to help them build community.
Are you old enough to remember Firefox 2.0? It was a huge deal. Why did semantic versioning kill “big deal” releases and what could we do instead?
The myth of the “10x Developer” is rooted in pure technical fluency and short-term growth metrics, and it’s a dangerous narrative to sustainable teams and products.
Some months ago, we decided I would be the one to take Kyle’s computer and put it to use. Today felt like the day I could remove the PC without doing further damage to my soul.
Offering community managers a forum to build a community is like giving a project manager a kanban board. Yes, they can make it work. But is there really a “kanban market”?
What is software development really if not a sprawling, borderless puzzle for which the lid with the big picture on it is long gone? To me, it seems obvious that the biggest hurdle to team-based software development is how difficult it is to communicate well.
Most substantive community work is about consensus seeking, and software is naturally very bad at this. How do you put humans at the center of community software? Don’t build better algorithms, build better workflows.
The greatest sin of any developer is thinking they are cleverer than the users of what they build. “I can guess what you want.” In truth, guessing what someone wants is far easier than helping them achieve what they actually want.
Platforms exist to remove interaction barriers between users. The folly of platforms is believing they can entirely rely on algorithms to control & shape human interaction.