Category: Blogmarks

Categories
Blogmarks Culture First Engineering Software Engineering

Endorsing and regretting technical decisions

This post from Jack Lindamood has a format I loved. The decisions and his reflections are interesting, but I think less interesting than the format itself. What I love:

  • You keep track of all the big decisions you’ve made during your tenure in a particular company / role
  • You engage in self reflection on if they were good or bad choices, after you’ve had time and benefit from hindsight
  • You share knowledge with the community (I was exposed to tech I’ve never heard of, and had new takes on tech I use every week)
  • If we had one of these for Culture Amp, it would go a long way to clarifying not just why we use a certain tech, but if we still like it, separate from the decision of if we’re still using it.

At Culture Amp we do use a tech radar that mimic’s the format from Thoughtworks. But the “radar” UI doesn’t lend itself to reading as a whole.

I also like that he’s captured the decisions he’s been accountable for as an engineering leader. That’s fascinating when thinking about recruiting – how do you convince a new company that you’re going to be a leader with good judgement? And how does the new company evaluate if the way you make decisions – and learn from mistakes – is the right fit for them?

(Almost) Every infrastructure decision I endorse or regret after 4 years running infrastructure at a startup · Jack’s home on the web

Categories
Blogmarks Blogmarks Personal

Blogging as an “ideas garden”

Mark Carrigan has a post “How blogging is different from tweeting“. I particularly loved his description of blogging as an “ideas garden”:

It occurred to me recently that I feel extremely differently about ‘outputs’ via Twitter than blogs. I first came across the notion of the ‘ideas garden’ via Doug Belshaw and it suggests a blog can be seen as a place where you help ideas take root and grow.

This contrasts with the inherently performative feel of Twitter where the focus on immediate feedback means that individual item becoming a focal point for your reflection. In other words I care about the reaction a tweet gets because it is self-standing and immediately public whereas a blog post is an element of a large whole. It is a contribution to growing my ideas garden, for my own later use and whatever enjoyment others find in it, rather than something I have expectations of receiving a reaction for.

The blog itself then comes to feel like something more than the sum of its parts: a cumulative production over 13 years and 5000+ posts which captures my intellectual development in a way more granular and authentic than anything I could manage by myself. Over time I see old posts I’d forgotten about resurfacing as people stumble across them and this long tail heightens my sense of the emergent whole. It’s become an ideas forest which people wander into from different directions, finding trails which I had long since forgotten about and inviting me to explore a now overgrown area to see if I should begin tending to it once more.

https://markcarrigan.net/2023/05/22/how-blogging-is-different-from-tweeting/
How blogging is different from tweeting

Other people I’ve seen do this really well:

I’m inspired to try do a bit more of my thinking publicly, particularly about my work in the software industry (both cutting code and leading people).

Categories
Blogmarks Software Engineering

Tech debt metaphor maximalism and “creating opportunity”

Here’s one of the better write-ups I’ve read on the concept of technical debt, from apenwarr:

I really like the “tech debt” metaphor. A lot of people don’t, but I think that’s because they either don’t extend the metaphor far enough, or because they don’t properly understand financial debt.

So let’s talk about debt!

Tech Debt Metaphor Maximalism on Apenwarr

I learned things about debt and finance reading this, and it certainly helps bring much needed nuance to discussions about technical debt.

The discussion on Hacker News also had this comment that I loved, and I think I’ll use as alternative framing at work when discussing the need to keep code-bases healthy:

I worked with Ward Cunningham for about a year, and he said once that he regretted coining the phrase “technical debt.” He said it allowed people to think of the debt in a bottomless way: once you’ve accumulated some, why not a little more? After all, the first little bit didn’t hurt us, did it?

The end result of this thinking is the feature factory, where a company only ever builds new features, usually to attract new customers. Necessary refactors are called “tech debt” and left to pile up. Yes, this is just another view of bad management, but still, Ward thought that the metaphor afforded it too easily.

He said he wished instead that he’d coined “opportunity,” as in, producing or consuming it. Good practices produce opportunity. Opportunity can then be consumed in order to meet certain short-term goals.

So it flips the baseline. Rather than having a baseline of quality then dipping below it into tech debt, you’d produce opportunity to put you above the baseline. Once you have this opportunity, you consume it to get back to baseline but not below.

sonofhans on hacker news