Ctrl+Shift

A Post for Plumbing Couple of posts in the pipeline, but first, the pipes …

Fri, 13 Nov 2026 23:57:56 GMT

A Post for Plumbing

Couple of posts in the pipeline, but first, the pipes themselves…

This blog is now a blyg, at least superficially. You can get its content at blyg in addition to the normal /blog endpoint. This will have Implications and Advantages that you can read all about at the blygger protocol site and see live at blygger.com. A lot of that will come into relevance over the next week or two as I roll the rest of the protocol here; part of this post’s purpose is to deploy something that works with conformance level 1.

And: this now goes out via possumus including the Kit.com adapter, rather than the Kit-side RSS publication pipeline.

Changes abound! New protocols and new possibilities!

See you in the next post.

A Post for Plumbing Couple of posts in the pipeline, but first, the pipes …

Fri, 13 Nov 2026 23:49:29 GMT

A Post for Plumbing

Couple of posts in the pipeline, but first, the pipes themselves…

And: this now goes out via possumus including the Kit.com adapter, rather than the Kit-side RSS publication pipeline.

Changes abound! New protocols and new possibilities!

See you in the next post.

A Post for Plumbing Couple of posts in the pipeline, but first, the pipes …

Fri, 13 Nov 2026 23:43:00 GMT

A Post for Plumbing

Couple of posts in the pipeline, but first, the pipes themselves…

And: this now goes out via possumus including the Kit.com adapter, rather than the Kit-side RSS publication pipeline.

Changes abound! New protocols and new possibilities!

See you in the next post.

Imported from the Ctrl+Shift archive — Substack, Posse, and the age of intellectual deindustrialization I dislike and …

Sun, 28 Jun 2026 02:28:00 GMT

Substack, Posse, and the age of intellectual deindustrialization

I dislike and distrust Substack. It’s centralized, funded by people I distrust, has an unmitigated history of giving a pass (and profiting from) to some pretty hateful content, and could very well end up another Twitter in short order. It’s also where some of my favorite sort of nerds are, particularly around the World Machines project. RSS won’t suffice; I want to be a participant. We all need community.

So how to bridge the gap? I’m not moving over there wholesale. I like my newsletter. I don’t want a platform. Substack’s functionality around cross-posting is nearly non-existent. You can do a big one-time import; using it as a mere endpoint instead of the center of your universe is discouraged. (Another reason not to trust it; this feels deliberate.)

Thus: POSSE (Publish on Own Site, Syndicate Elsewhere). Twitter was centralized and launched a fair number of folks’ Personal Brands and/or social lives and/or careers. That world is dead, gone, buried under a steaming pile of musk.

A couple years ago, this would be a conundrum. Do I do the one-off import and then copy and paste everything by hand? Just give up? Track down a syncing service and hope it stays alive? Find the time to write something custom?

The latter one there–roll your own–was until recently untenable for more than a handful of projects at a time, at least for us mere mortals. Now, though, ideas like that turn into Claude Code sessions. And so did this one.

So: welcome, Possumus. Sort of the same idea as Posse Party; different sync targets. Possumus is an Elixir Phoenix app that watches your specified RSS feed and republishes to your targets. It’ll backfill as a one-off operation if you’d like. I’ve tested Substack (with this very post) and have the wiring in there for (Convert)Kit. It’s not a huge announcement; I (with heavy agent assistance) built this entirely to scratch my own itch, and it does that. And I think that we can collectively do that now is neat!

The chaos and swirl as we deal with strengthening large models and improving harnesses and horrific politics and power dynamics is far from settled. But it’s cool that I can just stand this up and use it. Some was Claude-built, but some was local: DS4 Flash runs great on my Macbook Pro, and pi makes for a good-enough harness to drive it. There’s definitely a full post in there about The Age Of Intellectual Deindustrialization and I’d like to write it–but don’t want to hold up this post over it.

Possumus is free (beer and source). If you’d like to use it, the source is there to hack on–hosting the source on Radicle feels philosophically aligned. I’ve gone to the trouble to persistently host the service; email me if you’d like an account too!

And who knows, maybe this’ll get me unblocked and publishing again.

Imported from the Ctrl+Shift archive — The Detox Burnout is a slippery beast. I hit burnout somewhere in early April of …

Thu, 16 Apr 2026 02:44:00 GMT

The Detox

Burnout is a slippery beast.

I hit burnout somewhere in early April of 2025. Maybe late March.

It looked different than how we usually talk about it. I was still showing up for work. I was not putting in fewer hours. I was putting in all the hours.

Some of that happened way early on, not so much the result of burning out as the removal of protective factors. I stopped going to the gym. This newsletter went on unannounced hiatus as I stopped writing, both for myself and for an audience. My warm contacts and clients got cooler.

But something shifted around February. A project under my purview had been shelved after over a month of effort, having run into too many tech debt shaped blockers to cleanly integrate without functional regressions. The long-tenured principal departed, leaving me one of the most senior folks there despite about six months of context. And my next project was designed, committed, and had a tentative delivery date, despite my not being certain about what landmines may have lain ahead.

The hand dealt

Any project, any client, any job will have lessons to take away. I’ll get to those with time as this newsletter resumes. But for purposes of talking about my trajectory, here’s what actually mattered:

My positioning was compromised and, relatedly, my confidence was shaken;
I didn’t have the context to push back on the project definition with data, nor the confidence to push back with experience;
My only remaining lever was sheer effort.

All of this didn’t necessarily doom the project. (Like a good poker player, let’s discuss inputs and decisions, not the outcome.) But it did set me firmly on a burnout trajectory, and it didn’t take long to get there.

A new vision of burnout

My prior take on burnout was that of bleak, unenergetic cynicism–of finding myself physically unable to look at a computer screen, struggling to get out of bed, that sort of thing. Most of it would map to depressive elements. And yeah, I had some depressive tendencies going on.

But I’d thought that burnout looked like Tired Batman.

Me? Nope. Still at my desk, frantically slinging code.

Twas the shame wot dunnit

Like most burnout self-diagnoses, by the time I started to catch on, I was neck-deep. It was a slow death by shame, not by exhaustion. I was increasingly certain I was letting down my team and setting them up for failure; my ability to make confident estimates was increasingly compromised; I’d started to deflect when things went wrong instead of getting curious to diagnose.

“I’ll tell you what the human soul is, Mary,” he whispered, his eyes closed. “Animals don’t have one. It’s the part of you that knows when your brain isn’t working right. I always knew, Mary. There wasn’t anything I could do about it, but I always knew.” – Kurt Vonnegut, Galápagos

My “something is off in my brain” moment in reflecting after a conversation in which someone had asked me to self-evaluate in my abilities to apologize and repair after dropping the ball. Objectively, this is something that I am skilled at, a direct beneficiary of years of therapy both in and out of relational contexts. Yet when asked about this, I’d responded that I was failing at it and that it was something I wasn’t good at.

I’d responded entirely out of shame, and none at all out of being present. My body was there; my fingers played across the keys, moving code and plans; my face appeared on all the meetings. But my self was ducked behind a young protective factor.

From the outside, I looked…stressed. But was my growing absence professionally visible? Probably not.

With this retreat into a small version of myself, I’d unknowingly drawn The Detox. By late May, I found myself out of a job, utterly spent, and having to do the work of draining the poison from myself before I had any business looking for The Next Incredible Journey. No, before that, I was bound for The Woods.

We think of burnout as legible, visible from inside and out. It is not always so. My burnout looked like trying, and felt like failing.

Imported from the Ctrl+Shift archive — Scheduling something optional? Stop reaching for Fridays. This was once a good …

Mon, 13 Apr 2026 16:43:00 GMT

Scheduling something optional? Stop reaching for Fridays.

This was once a good idea: you and your colleagues would set up an optional time to collaborate or just connect over something lighter. An ad-hoc game hour, or a lecture or an industry topic, or a happy hour, or a standing mastermind. If something came up, you could scrub. Folks appreciated the chance to decompress a bit before heading home for the weekend.

We should’ve caught on to this being an anti-pattern years ago; it should’ve been obvious when working remotely even pre-covid. The very things we’re describing as “optional” and “light” are often the second-quadrant (important, not urgent) work that we should be fighting to get prioritized ahead of the noise. But alas, when we as professionals want to schedule something that’s not immediately relevant to in-flight work, we still reach for Fridays.

You can trivially prove to yourself that this is a bad idea. Pick a thing you’ve been meaning to learn about in terms of professional growth. You’ve probably already got a handful of resources you’ve been meaning to follow up with it on–a course or a video or something. Block off half an hour at 3pm local on Friday to do it. And see what happens. How’s it feel? Are you able to attend to it in earnest? What do you feel compelled to do? What do you actually want to do?

When we schedule those second-quadrant things (including the social ones! connectivity is important!) for the end of the week, we’re choosing to deprioritize them. And when we do it for other people, instead of offering a nice way to wind down before leaving the office, either folks skip because something comes up, or we’re forcing them to choose between your optional thing and closing their laptop an hour earlier.

Author’s note: it’s been a while. Missed y’all. Stories to come; in the meantime, knocking the rust off these fingers will take a few days to weeks.

Imported from the Ctrl+Shift archive — Decide what not to learn At least, for right now. You can learn anything, but …

Wed, 12 Feb 2025 04:52:00 GMT

Decide what not to learn

At least, for right now.

You can learn anything, but you can’t learn everything.

Career-adjacent learning can be one of the most compelling ways to spend your time and energy. It promises open doors and Possibility, new abilities that you can use to build grand new dreams and advance yourself, and the sheer enjoyment of gaining knowledge.

It’s also bottomless and neverending.

If you start digging in to learn every interesting thing you come across, you’ll only ever glean a Wikipedia-depth summary of each topic. And if you’re working in technology, this risk is all the more tempting: there’s every day a new language, framework, process, or entire field of study promising to make the life of you and those around you somewhere from better to utterly transformed.

The only way to get to a level of depth where you can competently apply a new topic of learning is to concentrate on it to the exclusion of all that other noise. Which comes down, mostly, to deciding not to learn most things.

If you, like myself, struggle with this, a tactic: write down all the things you want to learn, are in the middle of learning, haven’t quite had time for, know you really would benefit from…you get the idea. Pick the top one. The rest of the list–especially #2 and #3!–is the stuff you absolutely must avoid at all costs. That’s not your “next” list. That’s your “DANGER” list.

You’re allowed to start on the second topic when and only when you put the first one down for at least a month.

You can tell yourself you’ll get to everything else on the list someday. Maybe you will! But if you try to do them all today, you’re not really getting to any of them.

Imported from the Ctrl+Shift archive — Obvious often isn't. It’s pretty easy to dismiss our own thoughts and …

Thu, 16 Jan 2025 04:22:00 GMT

Obvious often isn't.

It’s pretty easy to dismiss our own thoughts and observations as obvious. Why bother telling everyone else? It’s clear enough; they can see it for themselves. To actually voice it or write it would be pithy at best.

Then, when we do open our mouths or pick up a pen, the feedback comes quickly: that was novel! or brilliant! or different! or any number of things that make it clear that, what was obvious to you wasn’t to everyone else.

And then we forget and do it all again.

The thing is: we all do this. It’s a wonderful thing individually to learn how to get past the sense of obviousness and just put it all out there, but the real multiplier is to help those around you: your team, your reports, your organization, your peers. Try a simple prompt when next thinking through a project: “What’s obvious about this that you aren’t saying?” – and see where things go from there.

You might be surprised. And so might they.

(Derek Sivers has a great writeup on this, too.)

Imported from the Ctrl+Shift archive — Prescribing the Big Pill Willful self-injury Peace Corps volunteers returning …

Wed, 15 Jan 2025 04:54:00 GMT

Prescribing the Big Pill

Willful self-injury

Peace Corps volunteers returning from parts of West Africa are given the Liver Bomb, and strict instruction: continue malaria prevention, abstain from alcohol completely for weeks, and follow the protocol exactly. This potentially harmful medication is administered presumptively, without any presenting symptoms.

Why?

The risk is high: these volunteers spend years in rural areas with limited sanitation, facing near-certain exposure to parasites.
The threats are severe: from potentially fatal (and certainly miserable) malaria to permanently damaging conditions like river blindness and schistosomiasis.
The alternatives aren’t viable: Waiting for symptoms is a non-starter, since these tropical diseases are often misdiagnosed or missed entirely in Western healthcare settings until serious damage occurs. And less aggressive treatments aren’t effective enough.

The Liver Bomb–the Big Pill–gets prescribed presumptively, despite lack of symptoms, and despite it potentially causing some minor harm, because it mitigates a much greater harm that has a fair chance of actually happening.

What’s your Big Pill?

This is a newsletter about tech leadership, not tropical medicine (though permit me some nostalgia). So why am I telling you about this?

Sometimes, we need to consider and accept team and organizational “injuries” to prevent greater harms.

Some technical examples:

code freezes before major releases or known high-traffic dates, or
the continued high friction of zero-trust infrastructure, or
strictly curtailing access to your production data.

Or, at an organizational level:

you might deliberately have redundant staffing, or
devolve power and decisionmaking across multiple centers that compete for resources, or
you might need to remove a poor-fit employee or even branch without a clear succession path, or even
push for industry-wide regulation that you’d be subject to.

The key is to thoughtfully consider the context–the levels of risk and severity, and cost of the mitigating actions. A five-person startup probably doesn’t need to worry about devolving authority, and a sticker seller on Shopify is unlikely to need Kubernetes. But identifying your team’s and organization’s “Big Pills” – and when to take them – is crucial for their long-term health.

Imported from the Ctrl+Shift archive — How many times did you buy that? The first time, when you spent the money to …

Tue, 14 Jan 2025 02:56:00 GMT

How many times did you buy that?

The first time, when you spent the money to acquire it.

The second time, when you spent the time to learn to use it.

The third time, when you spent your team’s time getting trained to confidence.

The fourth time, when you patched over the problems and inconsistencies with more money and time and attention.

Was there a fifth? A sixth, a seventh?

And then you paid for it one last time as you replaced or retired it.

A training course you buy and then abandon only costs you the money once; a poor program pushed without abandon multiplies its price over time.

Whether tools or trainings, products or partnerships, we pay for things in so many more ways than money. It’s worth weighing, both at the start and over time, just how expensive something will be.

Imported from the Ctrl+Shift archive — Every new system has its boundaries. Draw them or discover them later. You can’t …

Thu, 09 Jan 2025 05:25:00 GMT

Every new system has its boundaries. Draw them or discover them later.

You can’t reinvent the universe.

If you wish to make an apple pie from scratch, you must first invent the universe.

Carl Sagan, Cosmos

All of us live and work within systems, and each of those systems operates within further systems, and those within systems further yet, and so on until stardust, spirituality, and semantics. Even just a few hierarchical steps represents fractal complexity.

Any time you aim to replace or reinvent “the whole system”, there will be boundaries around the system space for which you can even attempt this, and tighter boundaries on the space where you could possibly succeed. This is true whether you’re shattering the patriarchal-capitalist system, rebuilding your organization’s core offering, refactoring a software feature, or changing a personal habit.

Every system change space has boundaries.

Reinventing the universe is too much. You have to depend on most existing systems remaining outside your influence as you work to effect change within a boundaried space.

What’s far outside these boundaries can be (but isn’t always!) intuitive. Your apple pie from scratch will most likely have milled flour you bought at a store, butter churned in a factory, apples from trees you did not grow. But as you get closer to the boundary edge (do you sift your own flour?), the line becomes less clearly obvious.

Boundaries can be drawn and defined, or discovered…or can slip by unnoticed.

When you draw a boundary between the system you want to change and the ones it interacts with and depends upon, you clarify how your new system has to interface with the rest of existence. Once you decide you’re not changing your reporting structure or the teams outside your division, so you’ll have to find appropriate ways for the new system within your division to communicate and interface with what’s still in place. Or if you’re changing your daily schedule to accommodate exercise, you may decide that appropriate systems to continue using are the 7-day week and your existing workplace, and only work within those boundaries.

If you don’t decide on your system-under-change boundaries, limitations on your ability to make that change still exist–though their expression when you discover them can vary. If you’re “lucky”, you’ll run headlong into a system boundary in a definitive fashion: a hard “no, you can’t change that system”. This can be disappointing, but has the upside of clarity. More common is to miss entirely where you system boundary should be, and end up floundering trying to have a meaningful effect on too large of a system space, like a conceptual mud trap. Software folks will recognize “scope creep” as an expression of this failure pattern.

If you want to succeed in changing, replacing, or rebuilding a system, you need to know what you won’t (or can’t) change. Draw the boundaries early on. Keep them tight. You can always make another apple pie when you’ve finished the first one.

Imported from the Ctrl+Shift archive — Just getting started is honorable work It’s booking the recurring 1:1 with your …

Wed, 08 Jan 2025 02:08:00 GMT

Just getting started is honorable work

It’s booking the recurring 1:1 with your new hire, or your new manager.

It’s git init . or mix phx.new the_next_big_thing --live or rails new my_greatest_work.

It’s picking up the phone and dialing the number of one person in the market you want to serve.

It’s writing a throwaway sentence or three just to get your pen moving.

More than what you’re actually accomplishing in terms of a task, you’re going from not-moving to moving.

It isn’t the whole work. It’s not completion, and the danger is that it feels like you’ve done something, and so you’re done. You’re not. You’re just getting started.

And in that, you’re doing the hardest part. Now you just have to keep going.

Imported from the Ctrl+Shift archive — Washboard abs, great hires, and market dominance Abs are made in the kitchen, …

Sat, 21 Dec 2024 03:36:00 GMT

Washboard abs, great hires, and market dominance

Abs are made in the kitchen, championships are won on the training ground, and a sustainable body of creative work is built on a foundation of the creator’s psychological self-acceptance.

Visakan Veerasamy, “I don’t wanna!”

Most of what we celebrate are trailing indicators. They’re exciting! A major product launch, lapping your competitors. Pulling a major hire into your team and watching them soar. Giving a successful talk at a conference.

These are great events, and we should celebrate them!

They are terrible expectations.

If you put in your work each day with the sole expectation of winning the market in 3 years, you’re going to flounder, burn out, and likely fail–and should none of those apply, you’re still counting on some luck.

If you instead spend each day looking for where you can do slightly better at one thing than the day before, and do it each and every day, with the expectation of getting slightly better…you’re going to get better at that thing. With time, the difference will be dramatic.

And you might not end up with the abs or the championship or the one perfect position or hire or owning the market. You’ll probably get some big wins mixed in there, too. They’ll be trailing indicators, and they’ll feel great, and they won’t be what you expected.

And when you’re done celebrating, it’ll be time to get back to setting expectations around what you can do better tomorrow.

Editor’s note: Ctrl+Shift will be sporadic through the next few weeks, resuming in earnest in 2025. Happy holidays and new year to all!

Imported from the Ctrl+Shift archive — Slow is smooth and smooth is fast Slow is smooth. Smooth is fast. – Common US …

Fri, 20 Dec 2024 01:31:00 GMT

Slow is smooth and smooth is fast

Slow is smooth. Smooth is fast.

– Common US Marines expression

Restoring your production database from backup takes time…especially the first few times. So does building a new dev environment for an onboarding engineer. And safely and reliably pointing your infrastructure at a different application container version than latest. But by owning that these things are slow, and doing them slowly and repeatedly before you need to, you can ensure that doing these tasks is smooth.

Slow is smooth.

It’s 3am when the page comes in. Things look bad; half your services are down, and there’s likely to be some data loss. You alert the stakeholders and support parties that have context, formally start an incident log, and pull up the checklist for each element of the situation: data integrity, backup restoration, blast radius limitation…

Nobody wants to be in this situation, but you’ve practiced the start of this, planned around it, and you’re ready to go. The next few hours will be stressful, and you’ll have a few surprises in there, but you’ve already got a plan, and your and your team’s fingers have gone through these steps enough times that it’s practically muscle memory.

It’s smooth.

And smooth is fast.

Imported from the Ctrl+Shift archive — Planning around working memory The theory of working memory holds that most …

Thu, 19 Dec 2024 04:49:00 GMT

Planning around working memory

The theory of working memory holds that most people can usefully think about and work with 3-7 concepts or things or chunks at a time. This isn’t the same as short-term memory—we’re not talking about remembering what your friend said five minutes ago, but rather what you’re actually thinking about right now.

Like most things in cognitive psychology, this is all theoretical. You can’t crack open your skull and see three to seven physical slots with a concept in each. We can’t prove any of this, or even disprove it.

But it remains an incredibly useful framing.

My own working slot inventory is probably 3. (It may have been 4, with one semi-permanently committed to the raising of young children.) And, knowing this limitation for myself, I can adapt accordingly. If there’s a growing list of things–tasks, concepts, people involved in a scenario, groceries–and it passes three elements, I know I need to start writing them down or I’ll drop some on the floor. Thinking on paper is slower than just doing it in my head, but having to rework missed items or rebuild lost context is slower still.

It’s worth considering: about where do you start having trouble keeping track of all your juggled concepts, tasks, people? Is it consistent across different types of thought-chunks? If so, you may have a good idea of how many working memory slots you’ve got to work with–and can make decisions to help yourself be more effective as a result.

Imported from the Ctrl+Shift archive — What context switching really is More generally, when you switch between a Plan …

Tue, 17 Dec 2024 23:41:00 GMT

What context switching really is

More generally, when you switch between a Plan A and a Plan B, momentum shifts from one bundle of possible worlds, to another. This is rarely a matter of turning one switch off and another one on. The clean fork-in-the-road shift is the exception; the dissipation of momentum associated with one course of action, and the cohering of another, is the rule.

Venkatesh Rao, Tempo

We talk about “context switching” as this thing to be avoided for knowledge workers and creative people, because it ruins concentration. But we don’t really give it any color, or any depth–just this thing to not do unless there’s a fire.

The best way to understand is to experience directly, and deliberately, so you’re prepared to observe instead of just to go with the flow.

Try reading this passage in a single go:

A civilization known as “Type I” has achieved a technological level close to the one attained on earth at the time Kardashev’s article was submitted (December 1963), with a rate of energy consumption evaluated at about 4 x 10^12 watts (W). A civilization known as “Type II” would surpass the first by fourteen orders of magnitude, matching the entire power emitted by the Sun in about 3,200 years, i.e, our home star’s “output“ at that time, predicted at 4 × 10^26 W. Finally, a civilization known as “Type III” reaches the milepost set in 5,800 years when humanity’s rate of energy consumption is predicted by the author to match the power emitted by the approximated 1011 stars in our home galaxy, the Milky Way, which involves harnessing power of up to an estimated 4 x 10^37 W.

https://en.wikipedia.org/wiki/Kardashev_scale#First_publication_(1964)

Do you feel the comprehension building, the mental model of the subject matter starting to fit together?

Hold that thought. And let’s jam out.

Okay, quick! What were we thinking about? How big were the magnitudes involved? Shit, was it three categories or five? How many years out were we estimating for that big one?

As you’re considering–what even was the name of the song that was just playing?

This is contrived, and we did it in about three minutes. Now imagine you’d been trying to chew on a full page of material. Or an hour’s reading and writing.

We changed subjects and media and tempo and timbre and might’ve given you a bit of attention whiplash. You don’t get to just drop context on the floor; as fast as the change of subject took, it took your brain and your pattern of attention some time to shift into that bizarro song. The momentum took time to shift–and once it had, it was hard to go back.

We’re skipping a lot of nuance, but this is the core.

Imported from the Ctrl+Shift archive — Mining memories for the future If you’ve been in this industry for more than a …

Thu, 12 Dec 2024 00:53:00 GMT

Mining memories for the future

If you’ve been in this industry for more than a couple of years, you’ve no doubt seen some trends come and go among your tools. If you’ve seen more than a couple of job titles over the years, you’ve seen the same in process, team organization, strategies, and all that. And if you’ve primarily worked with Javascript and the frontend, you’ve seen this whole cycle on technologies and frameworks play out over the length of a couple of podcasts (and, also, my condolences).

Tools and techniques become passé and fall into disuse, then obscurity. Oftentimes this is for the best of reasons: we’ve discovered a better way to do things, or found that a conceptual pathway was a dead end. Sometimes, though, this fashion cycle masks the usefulness of both tools and ways of thought–or even ways of being.

Tools

Guard is a test (and other command/event) auto-runner for Ruby. It watches your configured project and, when a file is changed, it runs only the related tests. If you were learning to use Rails 10-15 years ago, you probably learned about it in your first project. Now, you’ll be hard pressed to find it deployed anywhere. It still works just fine, and when I introduce folks to it, they typically love it.

It just fell out of fashion when we started containerizing everything. Now it’s forgotten.

Techniques

I mean, I still think Test-Driven Development is great–but in a much more nuanced sense than “you must test exactly every function every time before you implement it”. By and large, TDD, too, has fallen out of vogue–in part due to oversimplification of its upsides, in part because the more popular ecosystems don’t have as wonderful tooling around them as some older ecosystems once did. This isn’t the place to sell you, dear reader, on a new worldview around TDD, but know that it can be a competitive advantage when other folks don’t think even to try it.

Product Concepts

Adium hails from the Instant Messaging era: a single application that could pull together the diaspora of various accounts from AOL, Microsoft, ICQ, Jabber, and more. All that has fallen by the wayside–but here we are again, spread across Slack, Mattermost, Microsoft Teams, Skype, Signal, Telegram, and so many more. And so along comes Beeper, which does the same thing as Adium did, but for the current suite of messaging ecosystems. They’re young and already being acquired by Automattic.

Process and Ritual

If all you’ve ever seen of Agile is the way most enterprises have rolled out their SCRUM-ish processes, the Agile Manifesto is downright revolutionary.

And as always, Venkat’s there to comment as well:

Do forgotten historical cheap tricks regain their vigor and leverage after a period of abandonment? Is it possible to systematically improve your sense of history, by approaching the subject in specific ways?

Venkatesh Rao, Tempo

You

Over the years, you’ve tried on many ways of being. What pathways have you integrated? Which ones have you left by the wayside? And, of the latter, are there some that you might yet pull in to your life as it now stands, giving you a unique perspective among your colleagues and peers?

The new and the fresh is exciting, and often for the best. But as you mature and get more experience, being able to mine your past for fully fleshed-out but forgotten concepts can turn into a superpower. Ignore it at your peril.

Imported from the Ctrl+Shift archive — Productive Struggle There is actually an idea in psychology that makes the …

Wed, 11 Dec 2024 01:45:00 GMT

Productive Struggle

There is actually an idea in psychology that makes the connection even stronger: the Yerkes-Dodson law. This law posits that the ability to learn requires the right level of arousal. Too little, and you get boredom and disengagement. Too much, and you will react too quickly with hide and watch (or even fight or flight, the best-known natural behavior) to situations that might yield more learning with bolder exploration.

Venkatesh Rao, Tempo

In more progressive education circles, the concept of “productive struggle” has been in vogue since at least the start of constructing the Common Core efforts. Its premise is simple in concept, and remarkable in its implications: to learn and grow effectively, you must struggle. But not too much.

If you’re trying to learn (or being taught, or trained) something new, but the material you’re working with is too easy, you might get a nice quick dopamine hit right off the bat as you feel good about yourself…but then get bored and go do something else, never really internalizing the related concepts. Crucially, this applies to getting help, too; if a learner keeps receiving assistance instead of struggling to complete the work themselves, they won’t absorb things at depth.

If the material you’re working with is too hard, you’ll grind without much progress. Different folks have different amounts of grind they’ve got to give, but in the end, you’ll get frustrated and give up.

You’ve got to be challenged, but not stonewalled. You’ve got to struggle–productively.

While what “too easy” and “too hard” is varies by the person, the overall concept of productive struggle appears to be universal–at least enough so to get a lot of top-tier teachers really excited about it. So when you want to grow, or when you need your team to pick up new skills and concepts, make sure there’s struggle (but not too much!), and don’t interrupt it out of a desire to share the right way.

Imported from the Ctrl+Shift archive — Don't listen. Just watch. If a frog turns right and catches a fly, and then …

Sat, 07 Dec 2024 01:41:00 GMT

Don't listen. Just watch.

If a frog turns right and catches a fly, and then turns left and catches a fly, and then turns around backward and catches a fly, the purpose of the frog has to do not with turning left or right or backward but with catching flies. If a government proclaims its interest in protecting the environment but allocates little money or effort toward that goal, environmental protection is not, in fact, the government’s purpose. Purposes are deduced from behavior, not from rhetoric or stated goals.

Donella H. Meadows, Thinking in Systems

Toss your company’s mission statement. Ignore the org’s vision and everything it says on your landing page. If you looked only at where your organization expends its time, money, and resources, what would you determine is the purpose of your org?

What would someone else determine about your team?

And about yourself?

Imported from the Ctrl+Shift archive — Reacting, responding, retreating, recoiling The thing happened. It was a big …

Thu, 05 Dec 2024 03:30:00 GMT

Reacting, responding, retreating, recoiling

The thing happened. It was a big thing! And then you did…something.

Did you take a breath to consider first? Or did the action flow out of you without thought?

Did you push forward into the situation, or take space from it?

We’ve each got some default behaviors around all of these, varying from person to person but consistent across time. What’s your default? And in retrospect, when might it not have been the best approach?

Imported from the Ctrl+Shift archive — You are not Steve Jobs (and that is okay) And reading books about how Steve Jobs …

Wed, 04 Dec 2024 02:30:00 GMT

You are not Steve Jobs (and that is okay)

And reading books about how Steve Jobs thought and worked and acted will never change that.

How many books about Steve Jobs do you think Steve Jobs read in his life?

(In fairness, the number might not be zero. Egos are real, and his was perhaps larger than most. But the number might, in fact, be zero.)

And that you are not Steve Jobs is a good thing. Steve Jobs was brilliant, inspiring, and successful–and also combative, stubborn, long in denial of his own daughter, famed for a mercurial style that burned sane people out, and perpetually dissatisfied. Most of us, on balance, would not be happy in that life.

You are not, and won’t be, Elon, or Altman, or Cook, or Zuck, or Larry, or Gates.

Substitute virtually any man¹ so successful in building their personal wealth through business that they’ve become pop-famous. Even the most public relations-shielded among that cadre appear perpetually dissatisfied with what life has given them.

There’s value to be had in examining the strategies used by folks that’ve built sustainable systems and businesses. But don’t get lost trying to become more like somebody that you’re not–especially when that somebody can never be happy with their life.

You risk succeeding.

: It does seem easier to generalize men in this position. I’m more willing to believe that Oprah or Martha Stewart, for example, is satisfied with her life–but I could well be wrong here, too. ↩︎

Imported from the Ctrl+Shift archive — Irreplaceable isn't the point. Most “irreplaceable” people ultimately aren’t. As …

Tue, 03 Dec 2024 04:13:00 GMT

Irreplaceable isn't the point.

Most “irreplaceable” people ultimately aren’t. As dug in to a specialized position as you might be, organizations and economies can and will change tack, and without change, you’ll be left behind.

Instead, aim for unforgettable. Or remarkable. You likely won’t be in your job forever (and who wants that, anyway?), but you can set your team and yourself up for success by leaving a lasting impression. This is the work that will get you promoted, not the work that keeps you in place.

Irreplaceable won’t save you. Remarkable will propel you.

Imported from the Ctrl+Shift archive — In praise of loose ends When you’re having to put aside some work in progress …

Wed, 27 Nov 2024 06:04:00 GMT

In praise of loose ends

When you’re having to put aside some work in progress before you can fully complete it, a common approach is to find a “good stopping point”–finishing up some distinct unit, and leaving a clean break without loose ends. It feels tidy, and like the right thing to do. This is optimizing for a feeling of done-ness.

It also, counter-intuitively, makes it harder to resume work. There isn’t an obvious starting point, so the first thing you have to do when picking back up is make decisions about what to do next.

Writers use a tactic that runs utterly counter to this: deliberately stopping mid-paragraph, or mid-sentence, or even mid-word. It’s not satisfying. It’s not clean. But it makes it such that, when the author picks up their pen, there’s no question as to how to start or what to do next: they finish the word, then the sentence, then the paragraph. In so doing, context and momentum rebuild naturally. This is optimizing for undone-ness.

What can you leave undone that will leave a sense of frustration, so you’ll be almost compelled to start on it right away when you pick the work back up again?

Imported from the Ctrl+Shift archive — The skill that is not-doing Gregor: It would be nice to do something. Sam: We …

Tue, 26 Nov 2024 04:14:00 GMT

The skill that is not-doing

Gregor: It would be nice to do something.

Sam: We are doing something. We’re sitting here, waiting.

Ronin (1998)

It’s compellingly easy, even invisible, to stay in the loop of doing. Are you working with code? There’s no end of open tickets needing your attention. Are you supporting a team? Get another set of meetings in there! Are you managing a project? If you’re not syncing with stakeholders or delivery, you can go write documentation!

The thing is: sometimes, the best use of your time, the most effective action, is to do nothing. To sit, wait, and let the system that you’ve put into motion move without your intervention. To not mess with what’s working, and to make time and space for your team to figure things out for themselves.

When we’re accustomed-nay, addicted-to continuously doing, this can be jarring. It feels like you’re at the very least not pulling your weight.

Coping with these feelings, and doing–or rather, not-doing–the right thing, then, becomes the work.

Imported from the Ctrl+Shift archive — A somewhat useful LLM framing: the sparring partner If you’ve tried to have an …

Sat, 23 Nov 2024 04:54:00 GMT

A somewhat useful LLM framing: the sparring partner

If you’ve tried to have an LLM write prose for you at some point–particularly within the last year, since tightened safety mechanisms made it nigh-impossible to effect a more artistic voice–you’ve probably been disappointed with its dry, stilted voice. The only available personalities appear to be “printed user manual” and “awkwardly trying to be brah”.

It should go without saying that you shouldn’t publish this output. It’s awful, and often cringe to boot.

A more useful application is to ask the LLM to challenge and criticize your own writing. While its ability to generate new text with personality is weak, it knows well the rules of the game and can point out where you may have strayed. Ask: what about this misses the point? Where is my logic wrong? What seems redundant or extraneous? Convince me that my argument is wrong!

The intent here isn’t to get the LLM to think and write for you. It’s to find weaknesses in your own writing and thinking.

Imported from the Ctrl+Shift archive — Scheduling breaks in the high season You must schedule time to rest and recover, …

Fri, 22 Nov 2024 04:43:00 GMT

Scheduling breaks in the high season

You must schedule time to rest and recover, or it will be scheduled for you–typically at the least convenient time possible. (Paraphrased, many sources, including Tara Brach)

This is sage advice—and it’s broader than it looks at first blush.

Yes, by all means, take a break before you burn out or make yourself ill. And yes, certainly, learn to give your mind and body and anything else that comprises your human experience the time and space to not be always doing.

That’s already a difficult lesson—we all need to learn it more than once. But there’s variations and subtleties that get missed when we just hear this advice as Hey Have You Tried Mindfulness.

Oftentimes, you can anticipate times and situations where you’re going to have less in the tank. Your org has seasonal variations, and you’re coming up on a really high-traffic period. The holidays are coming, and your family often causes you strain. The anniversary of a big loss is coming up, and you’ve historically found it pretty hard. Flu season is here and a lot of your team has kids in school.

Building some breaks into all of this is counterintuitive. Why not try get ahead of things? Knowing there’s limitations on upcoming availability and emotional bandwidth at both personal and collective levels drives us to work ever-harder so we won’t fall behind when things go sideways. The actual result of this is that we spend on work all the time and energy that it would take to get through the hard stuff gracefully—and then the hard stuff knocks us on our collective asses without the resilience to get back up again.

Are you or your team facing down some strain that could affect your velocity? Before pushing harder, consider building in some rest.

Imported from the Ctrl+Shift archive — Strong opinions, weakly held The idea: hold your opinions strongly enough to …

Thu, 21 Nov 2024 05:25:00 GMT

Strong opinions, weakly held

The idea: hold your opinions strongly enough to advocate for them, but weakly enough to change them when presented with new information.

I mean, okay. The values here are solid. But this industry truism is predicated on the idea that people want to argue about things and then change their minds–and I’ve found that, by the time someone’s arguing about something, they’re already pretty dug in. It’s going to be an ego hit for them to turn around and say: this thing I’ve been all-in for? Nope. I was wrong.

Nobody likes to do a wholesale, boolean reversal. Y’know what’s doable? Shifting along a continuum. If your opinions are nuanced and your attachment to them not a black-and-white proposition, you can shift the details as new information comes in without the self-compromise. You can say: “I was wrong about this part, but I still think this other part is important.” Or: “I was 80% in on this being the best way, but now I’m only 60%”.

If you can do this for yourself, your ability to grow will be higher–and less painful.

If you can do this for your team, together, you’ll be unstoppable.

I’m about 70% sure of it.

Imported from the Ctrl+Shift archive — Your days can't all be 100% Neither can your team’s. Yes: those days where …

Wed, 20 Nov 2024 03:21:00 GMT

Your days can't all be 100%

Neither can your team’s.

Yes: those days where everything seems to click and flow are lovely. Sometimes you’ll get a few of them in succession, and it feels like you’re going to conquer the world!

But we live in reality, as staunchly as some might deny it, and Life happens. Not only do folks have ups and downs–they’re also not evenly distributed. Which is to say: sometimes you or someone on your team is going to get the shit kicked out of them by life events, and to expect streaks of amazing performance without occasional streaks of having to focus on getting through the day is setting yourself up for surprise and disappointment.

People will miss a habit. Twice. You might well do so, too!

The key is not set the expectation that folks show up perfect every day, or to devise some ingenious system that makes every day perfect for them regardless of how they show up. It’s to check in with yourself and your team in a way that works for all of you—which might be deep, or might involve scaled questions, or might just be a weekly vibe check—while setting the example and expectation that shit days and weeks happen.

You can’t keep people from falling—yourself included. But if you can ensure there’s no judgment against someone when they’re down, and sometimes even help them get back up.

And I’ll take that over trying to force or fake a 100% day any time.

Imported from the Ctrl+Shift archive — It's about the links, not just the nodes No one really understands all the …

Sat, 16 Nov 2024 03:20:00 GMT

It's about the links, not just the nodes

No one really understands all the relationships that allow a tree to do what it does. That lack of knowledge is not surprising. It’s easier to learn about a system’s elements than about its interconnections.

Donalla Meadows, Thinking in Systems

One can define a human being by DNA or by the physical traits of the species, but I prefer to use the word person for the focus of a pattern of relationships.

Mary Catherine Bateson, Peripheral Visions: Learning Along the Way

You can learn all of the technology and architecture. You can build great technical systems to a high degree of predictability. But when the lights go out, it’s the communities and relationships that sustain us–personally and professionally.

What does investing a little time in strengthening your community look like? What’s one thing you can do today?

(Ctrl+Shift is resuming at last; that hiatus was longer than anticipated.)

Imported from the Ctrl+Shift archive — Writing good tickets (and projects) is salesmanship [ENG-7566] Refactor our …

Tue, 05 Nov 2024 03:40:00 GMT

Writing good tickets (and projects) is salesmanship

[ENG-7566] Refactor our fraglesnitz model to split out its roles into separate modules

Nobody cares. This will get put off forever.

[ENG-7566] Split razzmatazz off fraglesnitz, enabling us to build snazzyfleep

This at least has some justification. We want snazzyfleep.

[ENG-7566] Initial Snazzyfleep functionality [requires fraglesnitz refactoring]

This is the one that gets scheduled and started. It has a clear, immediate benefit.

But these are all the same job!

Yup. But…

The first one is written like a chore, with no clear benefit.

The second is written like a technical exercise with a nice side-effect.

The third is written like a business opportunity.

Guess which one is easiest to justify?

Ctrl+Shift will be off tomorrow for US election day (and perhaps longer if things get really ugly out there). If you’re based here in the states, and you haven’t already voted, go vote. And setting aside the pretense of anything being “not political”, Donald Trump is unfit to lead, in particular because he deliberately wants to hurt lots of people, some for power, some for revenge, and some seemingly just for fun. Vote against him.

Imported from the Ctrl+Shift archive — The Opposite of Resistance The opposite of resistance is not flow. Nor is it …

Sat, 02 Nov 2024 03:06:00 GMT

The Opposite of Resistance

The opposite of resistance is not flow.

Nor is it ease, or productivity.

The opposite of resistance is resilience.

Imported from the Ctrl+Shift archive — Scales of Resistance Where does Resistance come from? The concept is commonly …

Fri, 01 Nov 2024 03:05:00 GMT

Scales of Resistance

Where does Resistance come from? The concept is commonly discussed at the individual level, but its sources and expressions aren’t limited just to one person at a time.

Resistance in Individuals

The seminal work on Resistance, Pressfield’s The War of Art, focuses pretty tightly on the individual level. This is a great starting point for thinking about and understanding Resistance, not least because we can all relate. It’s also not comprehensive–Resistance can emerge individually, in teams, in systems, even in societies.

At the individual level, Resistance is emotionally rooted. It’s often an expression of a wide variety of fears, be they around status, effectiveness, routine, breaking things, the perception of others, and so on.

Imposter syndrome is Resistance at the individual level. Oftentimes, so are procrastination, perfectionism, and the fear of failure.

Resistance in Teams

Resistance in teams is rooted in culture, norms, and processes. You see it when people say or paraphrase “but we’ve always done it this way”. A series of failed initiatives can instill cynicism in a team’s culture–especially when management or leadership is graceless and blame-heavy. Resistance can also grow from consistently under-resourcing efforts towards change, expecting growth without providing training resources, or in setting arbitrarily unrealistic deadlines and then beating the team over the head with them.

Resistance at the team level shows up as cynicism, disengagement, and a muddled chaos of confusion as communications get further strained. If you’re on or managing a team like this, you’ll likely feel like you don’t know what people are doing with their time, or what they’re thinking when you interact with them.

Resistance in Systems

Resistance can arise from the individual or the team level, or it can come in more diffuse form from the systems we live and work in. Typically, at the systemic level, Resistance grows from either structural or knowledge barriers–though cultural issues similar to those on teams can emerge writ large and have similar effect. There’s two essential questions to address: how risky, difficult, and effective is it to make change within the organization, and how does one learn how to do it? For example, does your organization’s software have a lot of technical debt, and is knowledge of the gnarlier bits siloed off into just one team? Or does unclear ownership over a business function mean that you have to coordinate with five different teams to accomplish a small change, only to find that the needed expertise to pull it off isn’t present in the organization?

Resistance in Societies

Ask an American about their ability to concentrate on new things during an election week.

I may want to expand on this lattermost scope of Resistance Sources in the near future, but (perhaps fittingly) am living out this form of Resistance right now.

Imported from the Ctrl+Shift archive — When situationally compromised, delegate decisions There’s cloudiness and pain …

Thu, 31 Oct 2024 04:07:00 GMT

When situationally compromised, delegate decisions

There’s cloudiness and pain around the Situation, and you’re feeling (or trying not to feel) resistance to facing what could be painful truths.

You’re compromised. No shame in that; we all have our blind spots, our emotional fragilities, our scars.

But your judgment is compromised, too, and people depend on it. The right thing to do is to delegate to someone else. They’re imperfect too! But everyone’s got a different constellation of blind spots, fragilities, and scars. (This is much easier to do if you’ve identified one or more good delegates in advance.)

Let’s acknowledge: this is hard! and humbling! and deeply uncomfortable! While doing this is actually a form of strength, it’s so easy to feel like you’re demonstrating weakness by admitting what you can’t do.

Try this: “Hey, the situation with X is really challenging for me because it’s too close to some painful personal experiences, and I think my judgment may be compromised. Can I ask your advice, or hand this off to you completely?”

Yes, you can (and should) take the opportunity to learn from the challenge, to work on yourself and your issues—but right now, decisions need making, and someone else’s view will be clearer. Borrow it.

Imported from the Ctrl+Shift archive — Recognizing Resistance “We’re not ready to start on that yet…” “I don’t think …

Wed, 30 Oct 2024 04:09:00 GMT

Recognizing Resistance

“We’re not ready to start on that yet…” “I don’t think I’m the right person for this task…” “We need to do more research before moving forward…”

Are you hearing the cries of Resistance from your team?

I don’t mean defiance. I mean big-R Resistance of the Stephen Pressfield variety: the working-through-molasses sensation, when everything feels hard to start and impossible to finish on time. This in spite of knowing that your team has the skillset to perform and the history of pulling it off.

What should you be looking for?

Higher distractability. A bug bash is great, but if your whole team’s focus is shifting towards smaller keep-the-lights-on tasks rather than meatier deliverables, they may be facing Resistance.
Perfectionism blocking delivery. Code that gets stuck in review is never fun; code that gets stuck in review for weeks is a sign that something’s off. If your team is getting bogged down in the details, they may be facing Resistance.
Aversion to starting new tasks. If your team is finding reasons to delay starting on new projects, they may be facing Resistance.
Challenges in finishing tasks. If your team is finding reasons to delay finishing projects, they may be facing Resistance.
Aversion to feedback. (Much more on this in another post soon after this Resistance focus.) If your team is finding reasons to avoid feedback, they may be facing Resistance.
Indecisiveness and seeming fear or avoidance of commitment. If your team is finding reasons to avoid making decisions, they may be facing Resistance.
A general sense of malaise, low engagement: silence in meetings that had once had participation, lack of organic collaboration. If your team is finding reasons to avoid engaging with each other, they may be facing Resistance.

It’s worth being able to recognize and identify Resistance. Everyone experiences it, individuals and teams alike. And, crucially, it’s not a sign of weakness or incompetence. It’s a sign that something is off in the system.

When you recognize Resistance, you’ll want to make some changes. But let’s start with what won’t help: laying out blame and guilt across your team. They’re going to need some leadership, grit, and momentum-building, and the worst way to start this is by being further discouraging.

Imported from the Ctrl+Shift archive — How should we hire less-experienced developers in the age of LLMs? Over the …

Tue, 29 Oct 2024 00:41:00 GMT

How should we hire less-experienced developers in the age of LLMs?

Over the medium to long term, we’ll at least be able to reflect and think about what’s worked and what hasn’t. But right now, we’re in fresh snow: no tracks, no scents.

When evaluating for technical competency, should we…

Tell candidates not to use AI? This seems backwards, like asking accounts not to use calculators.
Push more leetcode? This was already ineffective, high-effort, and filtered out otherwise great candidates.
Describe a feature & ask candidates to write the tests? I personally like this, but that’s probably because I’m An Old. It’s totally conceivable that effective development flows are going to look wildly different in a couple years, and the testing story when we’re increasingly using engines that are non-deterministic might get weird. Short-term, this definitely still has value.

For those candidates we’re talking with that have learned to sling code with LLM assistance, though, we’ve got an option that previously was much more problematic: the take-home assignment, but accelerated.

Previously, asking someone to write a feature from scratch and bring it back to you, while probably a decent indicator of technical competency, was a really big ask. That could take a day or more of someone’s usable time, and often, firms making this ask would do so without offering compensation. Yuck. Expensive, borderline insulting, and you filter out people that already have jobs!

Now, you can slim down your request to something that someone could reasonably build with an LLM in an hour or so. It’ll be brittle and full of code quirks and flaws, but you’ll have a chance to evaluate how someone breaks down a problem and composes a solution—and that’s the most important technical competency in our industry.

We’ve got the chance to be better at hiring and make the process less painful for everyone, especially job-seekers. Let’s not miss out on it.

Imported from the Ctrl+Shift archive — Getting Ahead: Pathways to Comfortable Career Satisfaction for the Aspirational …

Fri, 25 Oct 2024 22:05:00 GMT

Getting Ahead: Pathways to Comfortable Career Satisfaction for the Aspirational

Looking at software career options from an earlier place, many folks find themselves both aspiring for career growth and wanting not to be plugging in 60+-hour weeks by mid-career (and rightly so!). There’s a lot of hustle culture out there that promises to get you there right away; while a few folks out there get lucky, most of this is just concealing the outside-the-office time its purporters are plugging in. In hopes of making this wide range of possibilities a little easier to navigate (and with the wish that I could give myself this same resource some twenty years ago), here’s a breakdown of some common and reliable actual paths towards career satisfaction, particularly for those that are young and hungry:

Put in the hours with your employer. Like, a lot of hours. More than 40. You need to both get in the reps and establish a reputation. It’s hard. It’s low-risk. But you’ll more than likely get where you’re aiming. This is “a job”.

Or…

Put in the hours outside of work. Put in enough at your job to get your job done, then keep going. It’ll be more than 40 in total right now. You need to get in the reps and establish a reputation. It’s harder, because you have to self-motivate. It’s medium-risk: you need to self-niche and get good enough at marketing and build an audience or a portfolio or reputation somehow, and you don’t have someone paying you from day 1 and telling you directly what they value. But it’s pretty rewarding. You might get where you’re aiming, and you’ll be at least fine in the meantime. This is “a job, plus a side project” or “a job, plus contracts/consulting”.

Or…

Roll the dice right now. Start your own thing with a narrow niche: find a fit between what you’re willing to do, who you want to work with, and what product or service they want enough to pay for. It’s hard. It’s high-risk. Right off the bat, your expenses mount by the day; the way to outrun them is usually by putting in a lot of hourse. The payoff is high, but there’s no guarantee you’ll make any money at all. If this is appealing, you should probably do it on the side until you get funding or customers or both. This is “a startup” or “a consultancy”.

Or…

Adjust your perspective. This one is the actual superpower. Start moving away from the binary win/lose perspective into a more gradated way of living. You are not winning or losing in your career. You’re on a continuum. From where you stand today, where are you aiming? What will feel like a single step in that direction that you can do in the next week? Do that; call it a win. Know that you’re genetically predisposed to compare yourself to your peers, and hack that to not make yourself miserable: instead of trying to be richer or more successful than them, try to be more truth-seeking, more giving, more interested in identifying where you yourself can grow, more able to hear feedback and learn from it. Doing this takes time—outside of work. It’s mostly time over time, though; better 10 minutes a day for a year than a two-week retreat in isolation. Perhaps ironically, this is a pretty good recipe for career success —but that’s not really the point. It’s hard. It’s low-risk. The payoff is high, and in the meantime you’re pursuing the middle path. This is “enlightenment?” western edition? Or something? More than anything, this is finding happiness right where you are, which makes for terrible cocktail conversation and a lot fewer deathbed regrets.

Resources I’d pass along for folks interested in all of these directions:

https://www.effectiveengineer.com/book/
https://jonathanstark.com/
https://readmake.com/
https://geraldmweinberg.com/Site/Consulting_Secrets.html
https://www.annieduke.com/books/ (particularly Thinking In Bets) (summary at https://sive.rs/book/ThinkingInBets)
https://www.danharris.com/p/books-ee0 (or for the more crunchy-granola crowd [no judgment, this is me too], https://www.tarabrach.com/books/radical-acceptance/)

There’s also something to be said for initially aiming to go T-shaped (lots of breadth, one area of great depth) with the intent of going X-shaped (two complimentary but distinct areas of great depth), but that’s a discussion for another day.

Imported from the Ctrl+Shift archive — Experiments, not initiatives Want to sneak an idea into your organization and …

Fri, 25 Oct 2024 00:07:00 GMT

Experiments, not initiatives

Want to sneak an idea into your organization and give it the best shot of taking root? Call it (and frame it as) an experiment. Make sure people know it’ll probably be irrelevant to their day-to-day, that it’s just a few people trying this thing for a set time box, that they’re invited to join but no pressure, and if you’re pressed by a deadline for something else, that’s fine; maybe skip this round.

Want to ensure maximum organizational resistance to an idea? Call it (and frame it as) an initiative. Make sure people know it’s coming for them, that there’s a plan with phases and task forces, that it’s going to replace things they like or feel empowered over without real detail upfront over what that might be, and that most of them have no input because all the decisions have already been made.

What the idea itself actually is matters, but how it’s positioned often matters more.

Imported from the Ctrl+Shift archive — Should I break rank? Is it cool if you chat up your boss’ boss’ boss? Likewise, …

Sat, 19 Oct 2024 16:55:00 GMT

Should I break rank?

Is it cool if you chat up your boss’ boss’ boss? Likewise, should I grab coffee with the intern even though they’re two or three levels down the ladder? Let’s break it down by org size.

Small places: easy and natural

At a small org (say, less than 30 people), you talk to your boss and your boss’s boss, your report and your report’s report. That’s because there’s, like, 30 of you and you all know each other. It’s pretty cool: you can all stay in sync, and unless someone’s super insecure, it’s no big deal to ignore the “chain of command”, if there even is such a thing. Job titles are pretty fluid anyway. From the position of influencing such a culture, most of your thought should be on what happens as the org grows, since this arrangement is lovely but doesn’t scale.

Overall, this is the easiest size to navigate, albeit the least stable over time.

Crossing hierarchical boundaries: socially acceptable and effectively built-in, and so politically acceptable and built-in, too.

Large orgs: structured, political, and sometimes even regulated

At a large org (200+¹, bigger…), there’s a bit more charge and a lot more politics, but if you don’t regularly connect with folks that aren’t directly adjacent to you in the hierarchy, you’re uninformed of what’s going on at the line level, and probably perceived as somewhere between unimportant and an easy target by folks higher up the ladder. A common adage among individual contributors in orgs like this is that the easiest way to get a promotion is to change employers. Whether this is easier I leave as a personal judgment, but an alternative path is to establish and nurture connections more than one step up in the hierarchy & communicate a hunger to grow. There’s some political risk in operating this way, but also there’s at least as much risk in being perceived as easily disposed of. Smart orgs intentionally enable and foster folks’ ability to cross boundaries this way so they can grow and promote aspirational people & reduce confusion across the board. They do this by establishing clear communication policies (including examples of exceptions) and transparency around folks’ connections, while still encouraging a socially connected environment. Enterprises attract people that are pretty open about ladder-climbing, which further normalizes this behavior for everyone.

There can be a lot to navigate, but most of the rules are established and available, and their change is relatively slow over time.

Crossing hierarchical boundaries: socially optional, but politically expected and expedient, albeit not without some risk.

The weird middle: complex, undocumented, and evolving

Mid-sized orgs are where you need to be a lot more adaptable, attentive, and deliberate about how you engage. It’s much harder to be prescriptive at this rapidly-evolving organizational scale, but here’s what you can keep in mind:

Formal rules and relationships are starting to emerge, but may not be officiated or written yet. Further, different folks will have different ideas about what these rules actually are, and what can or should happen if they’re violated (and whether that’s a good thing).
Folks that have been at the org since it was much smaller are likely to have relationships that would be hard or impossible for a newcomer to establish and grow.
Different orgs will have different cultures around the acceptability of jumping ladder-rungs; this is all the more pronounced at scale.

When working to handle and influence cross-hierarchy comms, you need to keep in mind where the org’s going, more even than where it came from. Folks might miss the casual and informal structure of being small, but that ship has sailed. Past about 50 employees, communication by osmosis has already stopped working. You’ll need to look to the way organizations larger than your own have established the rules of engagement and communication & got more deliberate around making those relationships transparent. Since this size org is generally in cultural flux, the goal here is less to get it right in great detail, and more to remain attentive and adapt as things change—what was right for you, your team, or your org a month ago may already be a poor fit. This is the most difficult and involved size of org to navigate in terms of cross-hierarchical relationships. In my experience, it’s also really rewarding when you get it right.

Crossing hierarchical boundaries: nebulous everywhere, but to your great advantage if you can navigate these churning waters.

A pro tip: Consultants in such organizations also have fewer such constraints—without the obvious incentive to climb the ladder themselves & a more nebulous reporting structure, it’s generally accepted and often explicitly encouraged for consultants at these mid-sized orgs to dance up and down the org chart. If you’re entering an org in this capacity, you’ll be at your most effective if you can use this to connect individuals and teams that otherwise would rarely communicate. And if you’re working in an org that’s recently retained a consultant, it’s well worth keeping this exception in mind & playing it to your advantage.

—

(Note: Ctrl+Shift will be on hiatus this coming Monday and Tuesday, returning Wednesday.)

Yes, I’m considering a 100-person organization to be “midway” between 10 and 1000. This is more about culture than numeracy. ↩︎

Imported from the Ctrl+Shift archive — Good tools are worth paying for As an industry, we’ve long become accustomed …

Fri, 18 Oct 2024 01:58:00 GMT

Good tools are worth paying for

As an industry, we’ve long become accustomed (one might even say spoiled) on the no-cost availability of good tools. Those of us that came up with exposure to Linux, GNU, and the FOSS ecosystem in particular (not to mention the concurrent wave of peer-to-peer file sharing) are likely to have this mindset even more deeply entrenched. Have you ever paid money for a compiler? I have not (at least, that I can recall).

This has been an enormous boon for people and young companies wanting to get started: the capital investment required to learn how to build new things in software, actually build them, and build a new business or movement is incredibly low. And that’s been wonderful! It’s created careers, innovations, whole swaths of intellectual and economic growth.

It’s also created a mindset of never paying for our tools unless we absolutely have to. What started as a nice way to help teenagers learn to make websites has become the ideology of the captains of our industry–and their many deputies. And that’s to everyone’s detriment.

For the pedants out there, an acknowledgment: providing software at no cost was never the intention or the point of the free and open source software movement. For decades we’ve had to contend with the commingled meanings of “free” in English, clarifying with “free as in beer” and “free as in speech”. The latter was the thrust of FOSS from early on; the low cost was comparatively a side effect. But the impact of this side effect has been transformative.

There’s a strong argument that you should pay for your tools because it’s the Right Thing To Do. Somebody or many somebodies out there put in a lot of work to make that tool, and we should support them. This has merit! But it’s framing a purchase or a donation as charity–and this writeup isn’t about charity. If you get feelings when someone with a clipboard and a branded windbreaker approaches you in front of your local Starbucks, this ain’t gonna help.

You should pay for your tools because:

That’s how you get the best tools. If you’re stuck in the mindset of only ever using what you don’t have to pay for, you’re missing out on a lot of well-polished sharp blades. As I noted yesterday,, the difference in output quality between a free tool (OpenAI’s freebie DALL-E image generator) and a paid one (Midjourney’s¹ bleeding-edge diffusion model) is a wide chasm, and it’s enough to affect the reputability of your own work. There’s some incredible tools and services out there that are free, but limiting yourself to them exclusively is flying with blinders on. (Compare using your operating system’s built-in screenshot capabilities to CleanShot X.)
This is the only way our industry will change its mindset. Most of us that’ve found our ways into positions of influence or authority in the industry are old enough to have absorbed this never-invest mindset, and the knock-on effect is that a huge portion of the libraries and infrastructure underpinning the castles we’ve built are maintained by one or two burned-out folks that are one curse-ridden and disrespectful feature request away from throwing up their arms and walking away. Do something different yourself: pick either the most obscure or the most useful library that you, your team, or your org depends on, find a way to give them $100, and then tell your peers that you did. (I went for “obscure”, and give $10/month to Tridactyl.)

Let’s build a culture where paying for exceptional tools is the norm. The quality of your work and the health of our industry depends upon it.

Midjourney being perhaps an imperfect example to use here; if you want your work to look as professional as possible, make sure you give due consideration to stock photography and commissioned work. ↩︎

Imported from the Ctrl+Shift archive — Give Midjourney (or a stock photo site) your money Figure 1: Dall-E free …

Thu, 17 Oct 2024 03:32:00 GMT

Give Midjourney (or a stock photo site) your money

Figure 1: Dall-E free generation prompt–An ultra-realistic portrait of a walrus lounging on a beach chair

Figure 2: Midjourney generation prompt–Ultra-realistic portrait of a walrus sunning itself on a beach chair

Are you building images to share with the world at large, or even just with your team when presenting internally? Do they have text on them? Are you using OpenAI tools, particularly their free ones? Or perhaps an open model like Stable Diffusion?

They’re…okay, I guess. If you’re an expert, or an obsessed hobbyist, you can do wonders with them.

If you’re not an expert, go give Midjourney your money. Yes, it’s non-free. Your audience and your reputation will thank you.

Imported from the Ctrl+Shift archive — The Day After A layoff, a failed or canceled major project, or just a really bad …

Wed, 16 Oct 2024 03:54:00 GMT

The Day After

A layoff, a failed or canceled major project, or just a really bad night’s sleep. Our orgs, our teams, ourselves: we all have absolute dogshit days occasionally. Much ink has been spilled and coaches consulted on avoiding these in the first place—and I won’t argue that isn’t without value.

But if you base your plans on every day being at least okay, and you’re in for a world of hurt when you’re wrong.

The real skill isn’t not falling down; it’s knowing how to get yourself back up again. And that is a learnable skill.

Some learning, alas, comes unavoidably from painful experience. But you can also plan and practice the repair in advance:

On the day after a rough day, how will you and your team get back on your feet? Are there particular ceremonies that you collectively find restorative? How can you emphasize your team’s sense of community and support? Oftentimes, just taking deliberate space to acknowledge that things sucked (and letting everyone air it out) helps.
When your org as a whole takes a beating, what can it do the next day to help its folks back to their feet? Is there a cultural touchstone or sense of purpose yo can fall back on?
On the day after you miss all your habits because you were overwhelmed or compromised, how do you get back a sense of rhythm? What’s a favorite song that helps?

As a starting point, getting one small win in almost always helps at all scales.

You can put on your running shoes and walk around the block once and call it a win.

Your team can ship a single bugfix all the way to production and call it a win.

Your org can call out what went right when it seemed like everything was going wrong plan to enable that going forward and call it a win.

And then you can dust yourself off and get back to it—and get better at doing so every time.

Imported from the Ctrl+Shift archive — The discomfort of high-leverage time It’s easy to decry how difficult it is to …

Sat, 12 Oct 2024 03:20:00 GMT

The discomfort of high-leverage time

It’s easy to decry how difficult it is to set aside time to do strategic thinking–there’s an endless queue of tasks, priorities, interruptions, and heads-down time itself is needed for a lot of valuable work, adding to the contention.

And that’s why we don’t get to it. Right?

But what about when you do, indeed, have a solid block of an hour or two without interruption that you could potentially use to consider the bigger issues and decisions in your life and career?

Suddenly, mundane tasks become irresistible. Fixing documentation, polishing meeting agendas, or writing code suddenly seems much more important than they had been a few minutes back.

This isn’t about time management—it’s about resistance. Strategic thinking is uncomfortable because the stakes are high. Our subconscious knows this and pushes us to avoid it.

There’s lots of ways to cope with this. I personally find that changing my location with the explicit purpose of tackling high-leverage stuff helps; heading to a nearby coffee shop that I rarely visit for another reason builds up a nice association. Other tactics include scheduling the time, ritualizing an association (even with music or scent), giving yourself a prompt to start with, and so on.

But even more important than knowing what works is knowing what doesn’t: gritting your teeth, pretending it’s fine, and just forcing yourself through. Sometimes this works. But we are as a species so very good at resistance, and it’ll be even stronger the next time, so relying on this approach will swiftly fail.

The value of strategic, high-leverage time spent well is incalculable. But it’s not just about having the time; it’s about being able to use it. And the first step is to acknowledge that this is hard, so you can build the systems and habits to make it easy.

Imported from the Ctrl+Shift archive — A technical aside: Presentation summarizer Having spent the first few days of …

Fri, 11 Oct 2024 03:36:00 GMT

A technical aside: Presentation summarizer

Having spent the first few days of the week at a conference, I’ve found myself reflecting on talks I’ve seen recently and historically.

There’s been some really excellent talks over the years, but outside of actually attending a conference, it’s hard to set aside time to watch a presentation–so unless I’m there in person, I’m likely to have missed out.

For example, there’s tons of chatter right now about Ed Yong’s talk at the final XOXO festival. As a non-ticket-lottery winner, I wasn’t there, and so risk missing out forever.

But hey, we’ve got LLMs now, right? Sketching and experimenting with disposable code has never been easier. So I spent a bit under an hour half-distracted and brain dead from exhaustion chatting with Claude, and ended up with this Presentation summarizer.

Feed it a Youtube URL, and out comes a structured summary, considerably faster than real time. Here’s one of Yong’s talk:

Summary:

Speaker: The transcript includes a speaker who is an author and journalist. The speaker does not formally introduce themselves, but from the content it can be concluded they recently composed extensive work regarding COVID-19.

Content: The speaker starts the talk outlining their objectives and plan. They go on to recount how their attempts to ignore the start of the COVID-19 pandemic failed when their guilt, a previous piece they wrote on American readiness for a pandemic, and their wife encouraged them to write about the unfolding global crisis. They continued that over the next few years, they wrote long, detailed pieces aimed to provide an expansive view of the impacts of the pandemic. They tried to help readers make sense of the situation, hence they saw their role as providing a synthetic, comprehensive view. They also emphasized the repetitive nature of journalism and the need for diverse sources.

The speaker goes on to speak on how the pandemic affected their personal life while they were writing. They reflect on the strange experiences they had due to the success of their pieces and their nomination for various awards. They also emphasize that they can only achieve so much because of the support of their wife, Liz, editors, and all other team members.

Towards the end, the speaker tells of how they engaged with the public, and set a few personal rules to follow to maintain their mental health while working in such a critical time. They also emphasize the systemic nature of success, refuting the idea of meritocracy, and humbly acknowledge their own influence and reach.

Key Takeaways:

The speaker was involved in pandemic reporting and analysis

They explored pandemic related topics broadly going beyond just medical aspects.

The speaker’s work was recognized and gained a lot of attention.

Their work was a team effort with support from various members.

They set personal rules for engaging with the audience and handling publicity.

They acknowledge the systemic nature of success and used their platform to uplift others.

The transcription is hard to summarize due to language inconsistency and lack of clear context. However, a few points can be highlighted:

The speaker talks about the importance of people sharing their own stories, especially those dealing with chronic conditions.

They believe it’s essential for the broader public to understand the toll these conditions take and dismantling the notion of passive patienthood.

They talk about the potential for the media industry to work to amplify these voices and provide resources for those experiencing these issues.

In terms of web analytics:

Apparently, there have been changes to the website, with people’s views shifting over time in response to changing circumstances.

At one point, they mention responses to a pandemic, but it’s unclear how this ties into the overall talk due to the lack of context.

The speaker’s experiences in 2020 and 2021:

They discuss their decision to take a break in October 2022, taking a six-month sabbatical to rest and regain their abilities.

They returned to work in April 2023, albeit not at full potential, but chose to stop writing extensive pieces on the pandemic as they felt they had expressed all they wanted to on the subject.

Due to the challenges posed by the language, it’s hard to provide a more detailed or accurate summary. There are several mentions of various topics like empathy, chronic illnesses, pandemic stresses, work-life balance, and mental health, but the specific roles and thematic progression are challenging to decipher.

Summary of the Transcript

Title: A Personal Journey in Journalism, Birding, And Rediscovery

Main Speaker: The speaker was a former journalist for the Atlantic who is now predominantly involved in birding, photography, and book writing.

Key Points of Discussion:

Reasons for Leaving Journalism: Declared discontentment with the current state of journalism and decision to quit, citing the publication of poorly argued articles on sensitive topics as one of the factors.

Newfound Joy in Birding: Highlighted the mental health benefits of indulging in activities like birding, nature photography, and focusing on the present.

Writing Pursuits: Revealed plans to work on a third book about life at different scales, aiming for a more focused scope rather than numerous simultaneous projects.

Detachment From Online Presence: Shared a decision to reduce online presence, preferring to post bird pictures occasionally and largely staying offline; emphasized the role of community in real life rather than virtual spaces.

Aid to Long COVID Community: Mentioned starting a birding initiative, the Spoonbill Club, aimed at assisting people suffering from Long COVID to engage in easy outdoor activities.

Personal Health and Guilt: Admitted wrestling with guilt about not doing enough, but stressed the importance of self-care after professional success led to personal burnout.

Key Takeaways:

The speaker expressed disappointment and frustration with journalism and its potential, leading to resignation.

Birding and being outdoors have considerably improved the speaker’s mental health.

Emphasizing the importance of personal experiences and community over online presence and parasocial relationships.

The speaker is now focusing on writing projects, specifically a new book exploring life at different scales.

Demonstrated an effort to contribute to the community through a birding initiative for individuals with long COVID.

Decisions Made/Follow-Up Tasks:

Focusing on a new book project.

Continue running the Spoonbill Club, aimed at helping those with Long-COVID engage in safe outdoor activities.

Maintain the approach of staying mostly offline and focusing on real-life relations and experiences.

The emotional impact is, admittedly, utterly lost. This isn’t a replacement for actually watching a well-presented talk. But it gives a pretty good idea of what content to expect, provides a reference for later, and lets you know if you should invest the time to watch the whole thing.

It should go without saying, but I don’t represent that this is high-quality code. I literally haven’t even read it. But you’re more than welcome to it.

Imported from the Ctrl+Shift archive — High-value reviews from your newest team members Abstracting is all fun and …

Thu, 10 Oct 2024 03:18:00 GMT

High-value reviews from your newest team members

Abstracting is all fun and games till someone on your team writes a DSL without meaning to and in so doing makes onboarding new devs impossible. It’s hard for the author to see this—being too close to the code makes non-obvious things seem obvious: oh, you just call a self-registration function defined on the base class three levels of inheritance up in another file! Once someone’s got most or all of the structure of your team’s code loaded into their head, shifting complexity into it doesn’t appear to make things any harder than having a more complex function.

The best way to find this complexity that’s been pushed from implementation into structure is to have someone else try to understand the code, and tell you what’s hard. And the person on your team best positioned to do this isn’t your longest-tenured or highest-paid engineer—it’s your newest.

This is a peer review, yes—but it isn’t a Peer Review As We Typically Frame It. Most peer review’s purpose is to be a filter, preventing “bad” code from getting added into our expensive products. This isn’t without value, but it’s not what I’m talking about.

My suggestion: have your newest folks try to explain to the author of a medium to large sized changeset how their code works. (I freely acknowledge this is not a fun task for the reviewer-to-be.) The value is in finding where they struggle—and helping clarify how you can make those areas easier to understand in the future.

Imported from the Ctrl+Shift archive — Consultant's toolbox: solution-focused question sequences A quick Friday summary …

Sat, 05 Oct 2024 02:47:00 GMT

Consultant's toolbox: solution-focused question sequences

A quick Friday summary for your reference pleasure:

on a scale of 1 to 10, where 10 is exactly where you want to be and 0 is the worst you can imagine, where do things stand with you now?
why isn’t it worse? what are you doing that keeps you at (level they’re at)?
between now and (a point in the future close enough to relate to), where do you want to go?
how will you know when you get there? what will it feel like?
what’s one single thing you can do between now and (X) that will move things in that direction?

The overall mindset to carry with these is one of curiousity, non-judgment, and trust that your client or counterpart is the expert on what they actually want. You’re just a guide with good questions.

(Ctrl+Shift will be off Monday and Tuesday, resuming Wednesday.)

Imported from the Ctrl+Shift archive — Get to reality by asking on a scale “How was your day?” “Fine.” Or “Good.” This …

Fri, 04 Oct 2024 01:19:00 GMT

Get to reality by asking on a scale

“How was your day?” “Fine.”

Or “Good.”

This tells you nothing. It’s just pleasantries. Which is fine, if you’re just making small talk.

But what if you really need to know? What if you’re asking “how’s the crucial project going”? Without anything to scale or anchor against, you’re likely to get some variation of “fine”, maybe with a lot more words to make it seem like a deeper answer than it actually is.

“On a scale of 1 to 10, where 1 is the worst you can imagine and 10 is the best day of your life, how was your day?”

Now you’re going to get some real information.

Imported from the Ctrl+Shift archive — Fundamendalist SDLCs “[T]he rise of fundamentalism within any tradition is …

Thu, 03 Oct 2024 03:26:00 GMT

Fundamendalist SDLCs

“[T]he rise of fundamentalism within any tradition is always a symptom of the unwillingness to try to sustain joint performances across disparate codes—or, to put it differently, to live in ambiguity, a life that requires constant learning.”

Mary Catherine Bateson, Peripheral Visions

Fundamentalism is by no means limited to religion and politics. It’s one way that humans respond to the world around them, especially when in groups, especially when there’s a perception of threat. You bet your ass it shows up at work.

If, perchance, you’ve never done so (or even if it’s just been a while), have a gander at the original agile manifesto. You’ll find no mention of tools, no prescriptions, no proscriptions. It’s a document by dreamers, hoping to make progress in the world, not by eliminating nuance, but by leaving plenty of room to dance with it.

Twenty and change years later, what we as an industry typically call Agile is the Jira process. It’s very well-defined, and if you don’t subscribe to one of its denominations, you’re at the very least rebellious and more likely chastised or rejected by many of your industry peers.

We’ve largely lost the willingness to explore how different ways of working can fit different groups in different ways, and, further, to have more than one way of working in the same organization. And perish the thought of experimenting with entirely new approaches. That’s to be left to the professionals, whoever they might be–in any case, it’s not the business we’re in, because we have to deliver!

By having One True Way that all the teams in your industry work, you can have a shared vocabulary that makes reporting straightforward, comparing outputs simplistic, and individual workers more interchangeable.

So now, people are working under a system that may fit them poorly, and without anything to compare it to (except greybeards whispers of the damnable Waterfall), it’s impossible to figure out how to do better.

This is the cost of what Enterprise Agile has become: a fundamentalist SDLC.

Imported from the Ctrl+Shift archive — Don’t manage your business like it’s my garage “Buy cheap tools until you know …

Wed, 02 Oct 2024 03:14:00 GMT

Don’t manage your business like it’s my garage

“Buy cheap tools until you know what you really need from that tool, then buy the best version you can afford.”

Adam Savage

If you stick by this suggestion, as I have for years when it comes to hand tools, you’re going to end up with my garage. And that’s…not entirely a good thing. There’s some great stuff in there—and it’s crowded out by junk. When it comes time to track down the tools I need for a given task, sometimes I’ll end up grabbing one of the cheap tools even though I have a better one just because it’s within reach. And I’ll usually regret it, since the work will be harder, shoddier, and I might bleed a bit in the process.

What’s missing from this advice—what I haven’t done—is that once you’ve identified what you really need from a tool (even, and especially, if the answer is “nothing”), and acquired the best-fit version for yourself, you have to get rid of the old, cheap, dinky tools. Especially if they still kinda work. Because yes: you will keep using them.

But you’re probably not here to look for rotary hammer recommendations. (Though just in case, the Bosch GBH2-28L is a lovely, lively beast.)

It’s probably clear what I’m getting at here, but let’s make it explicit:

When you’ve opted to move past a couple of chained, brittle Zapier links and rolled your own automation pipeline, get rid of the old Zapier setup.

When you’ve restructured your org’s software delivery lifecycle away from enterprise-inflected Scrum to something more adaptive, get rid of your unneeded rituals (and maybe Jira too!).

Technical, architectural, and organization debt is only truly paid down when you fully get rid of what you’re replacing.

Otherwise, that old cruft will keep on living rent-free in your head. Just like it does in Dylan’s garage.

Imported from the Ctrl+Shift archive — Review your decisions, not your calendar A typical periodic review–be it for …

Tue, 01 Oct 2024 04:08:00 GMT

Review your decisions, not your calendar

A typical periodic review–be it for yourself, your team, or your org–often ends up looking something like:

set a date for a review meeting
everyone involved looks back at their calendar and tries to remember and piece together what they did since the last review
if there’s benchmarks or set goals to compare against, reframe the outcomes of the last time period to fit a desired narrative around those benchmarks or goals
have a meeting and possibly come up with next actions based around the intersection of those narratives, which are based entirely on outcomes

This isn’t the worst thing for taking the pulse of an organization as a whole, but it’s really not ideal for actually learning whether or not you and your teams’ decisions are good ones.

Instead, consider basing your review structure on the decisions themselves, not just “what happened last quarter”. You can do this by:

recording when you and your team reach a consensus on a decision–be it around architecture (for which a fair amount of documentation on decision records exists), communications, assignments, goals, etc.–and capturing the context, justification, and expected outcomes, along with the team’s confidence in those outcomes.
setting a date to loop back and review the decision
have a meeting on that date, to wit:
- what were the actual outcomes of this decision?
- was that good, bad, in between, or something else?
- how much of that was luck? how much of that was skill?
- what did we misjudge given the information and context at the time, if anything?

This won’t make for clean, date-aligned columns in a periodic report, but you’ll actually learn from your decisions.

Imported from the Ctrl+Shift archive — What darkness lies between decisions? Work is simply whatever we must do to get …

Sat, 28 Sep 2024 03:06:00 GMT

What darkness lies between decisions?

Work is simply whatever we must do to get from one decision to the next.

Venkatesh Rao, Tempo

An important metric: How many questions can you ask your system in a day?

Justin Searls (paraphrased from memory)

In the field of software development, many of us are already familiar with the extreme value of tight feedback loops as applied directly to writing code. Test-driven development’s “Red-Green-Refactor” development loop is a microcosm of this mindset, in which a programmer is given feedback on their function under development in ideally a few seconds at most. This also gets applied with the practices of continuous integration and deployment–or at least, such is the intention.

It’s curious, then, that we’re much less explicit about optimizing shortening the distance between decisions from a leadership perspective. Especially as Agile-as-practiced has degraded into a collection of prescriptive ceremonies without users understanding their intent, much of our focus has shifted to the performance of the stuff that comes between decisions, rather than finding ways to squash it.

Ultimately, this is the job, admittedly simplified:

What’s the next decision you or your team needs to make?
What do you want before making that decision?
What actually keeps you from making that decision right now?
- Do you actually need more information, or can you make a provisional decision and backtrack without losing too much time/effort?
- Are there other decisions this depends upon first? Restart this cycle with that/those decision(s).
Make the decision
Move on and start this loop again

The rest is either noise or semantics.

What else do you have between your decisions? And what of that can you get rid of?