sleepyfox

author: @sleepyfox
title: Time to decelerate
date: 30 October 2020 
preamble: Sometimes going ever faster is not the answer

---

Time to decelerate

Imagine you're an alien from another world, a crustacean-like species from an ocean world orbiting Epsilon Eridani, and you're researching Earth civilisation and culture. You're interested in the whole earthling obsession with quality and food, Michelin stars and celebrity chefs. On your world food is fuel, you eat rocks. Rocks provided by your world government as a service to citizens. There are no restaurants.

sleepyfox

author: @sleepyfox
title: Preview-Driven Development
date: 18 October 2020
preamble: Doing the PR review before the code is written is more helpful, just like TDD

Preview-Driven Development[^0]

Reader's note: these notes were originally written to support a SimplyBusiness tech talk, so is written with some embedded context which I hope to explain or remove in a future edit - my apologies for any confusion that this may cause the reader.

sleepyfox

Software Engineering, 1968/69 NATO Conference Garmisch/Rome

Many people are aware that in 1968 an inaugural conference in Software Engineering was held in Garmisch, Germany under the auspices of NATO, and that a follow-up conference was organised the next year, 1969 in Rome, Italy.

Although the reports from those two conferences are reasonably well distributed, if not perhaps as well read, there exists an appendix that the report editor, Brian Randell, notes:

Unlike the first conference, at which it was fully accepted that the term software engineering 
expressed a need rather than a reality, in Rome there was already a slight tendency to talk as 
if the subject already existed. And it became clear during the conference that the organizers 

sleepyfox

author: @sleepyfox
title: Fox's laws of software development
date: 27 October 2021
preamble: A not entirely serious treatise on the immutable fundamental laws of software development activities

Fox's laws of software development

A not entirely serious treatise

sleepyfox

author: @sleepyfox
title: Simplification
date: 22 October 2021
preamble: No, that is not the simplest it could be...

Simplification

There's this meme, this pervasive idea nowadays that complex things have to be complex, and only simple things can be simple. That somehow if you're trying to make a complex thing simple, that it is because you're just not 'man enough' to deal with the complexity, or that you're deluding yourself. I reject these notions.

sleepyfox

author: @sleepyfox
title: Continuous retrospectives
date: 6 October 2021
preamble: How MMO/esports practices for continuous improvement can be used for software teams 

Continuous retrospectives

Failure in software teams

sleepyfox

author: @sleepyfox
title: Pairing, and coaching
date: 19 September 2021
preamble: A coaching technique may help your everyday pairing practice

Pairing, and coaching

When I first read Kent's book, eXtreme Programming eXplained back in the early 2000's, pairing immediately made sense to me, in a way that it apparently didn't for many back then - and by many accounts still doesn't. The thing that was different for me, was that I already had many years of experience pairing, just in a completely different context.

sleepyfox

On communication, and when it goes wrong

Yesterday something happened that I needed to apologise for.

In a team call, person A was asking for help with a team problem, and I was in the process of explaining to them how they could fix it by doing X. Person B thought I was talking about them, and interrupted "oh, you mean by me doing Y?", I dutifully ignored the interruption and continued talking to A, I was explaining what I meant by X when B interrupted again. I again ignored the interruption and tried to finish my sentence, but distracted couldn't remember the technical term for a thing and in the slight pause B interrupted again.

"Can I please just finish my **** sentence?" I blurted out.

I did then finish my sentence in the silence that ensued. I explained that I was talking about what A could do with X, and that yes, B could help by doing Y, but hopefully that wouldn't be necessary unless X failed. We moved on.

sleepyfox

Why 3X is only half the story

Many people will have read one of Kent Beck's articles on 3X or eXplore-eXpand-eXtract or The Product Development Triathlon. Many people have taken to explaining Kent's work on their own sites, sometimes helping, sometimes not, sometimes even ranking higher on search engines than the original articles!

I have an unpayable debt owed to Kent, his work started me off on a journey of discovery that forever changed how I practice my craft. I count him as one of the handful of people who in this field have had the most effect on my professional career.

But even the best of us are blind to things that our position, our background, our experience and our culture either deprioritise, hide away or even make taboo. I'm going to argue that Kent isn't wrong per se, but rather his model is only half the story - perhaps

sleepyfox

On hiring, retention, and designing a better workplace

I'm often told stories with a very similar pattern. They usually start with something like:

• "One of our senior ICs has just handed in their notice"
• "We need to come up with an action plan for hiring and retention because the CTO has told me churn is too high"
• "I've just been told by my team lead that they're leaving for XYZ corp"
• "I've been listening to one of my team's devs telling me that there seems to be no clarity around what they need to do to get promoted here"

The symptoms are always the same: