Categories
Blogmarks Blogmarks Personal Software Engineering Work Habits

Learning new things and “garbage fountains”

From my friend Lars Doucet: Operation Garbage Fountain

Some nuggets from this post:

Maybe you’ve heard that story about the pottery teacher who divided the class into two groups: half would be graded traditionally based on the quality of their work, but the other half would be graded on sheer quantity aloneAs in, literally, he would take all the pots they made that year, weigh them, and X kilograms of pottery would get you an A+. As the story goes, the quantity group produced not only the most pots, but also unambiguously the best pots.

Lars Doucet: Operation Garbage Fountain

And then a link to a post that shared the original story.

I’ve always been captivated by music, but much like many kids decide they “can’t draw” or “suck at math,” I likewise labeled music as a mystical alien magic that would forever be beyond me.

Later, in high school, I met a girl in the year below me who played the saxophone. She was really good and I assumed she started playing in elementary school. Nope, she started playing the previous year. That moment was the first click for me – you can just start learning new things, anytime. Even today.

Lars Doucet: Operation Garbage Fountain

The key argument is that it’s all about putting in the pracitce, the repetitions or “reps”, and not making excuses. From his own story:

It wasn’t easy learning an entirely new career, but I’m quite good at it now, and it didn’t take nearly as long as I thought it would. It turns out you can just learn new things if you have the right people to guide you and you have the opportunity and the inclination to put in the reps.

Learning, ultimately, is about putting in the reps. Figure out what you want to get better at, and practice doing it.

There’s a lot of things I would like to do. I mostly don’t do them. My reasons are all stupid excuses.

Lars Doucet: Operation Garbage Fountain

He outlines – and then rebuts – all the usual reasons we don’t learn more then outlines his solution, “operation garbage fountain”.

Basically a set of commitments to himself to just do the creative practice to get better, and to share it online in its raw form. Not concerned about quality, not concerned about the overall narrative arc of your posts, not concerned about audience or community building. And no guilt about posting too little or too much – just a commitment to make a little progress as often as you can, and to always post it in some form.

I love this. It’s a different take to what I also liked in Blogging as an Ideas Garden … but I’m not sure it’s incompatible.

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/

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