Skip to content

Instantly share code, notes, and snippets.

Avatar
:shipit:

@sleepyfox sleepyfox

:shipit:
  • TypeError
  • The Midlands
View GitHub Profile
View 2020-10-18-preview-driven-development.md
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
sleepyfox / masterpiece-engineering-simpson-1969.md
Last active Nov 14, 2021
Masterpiece Engineering, T. H. Simpson, 1969
View masterpiece-engineering-simpson-1969.md

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
sleepyfox / foxs-laws-of-software-development.md
Last active Dec 13, 2021
Fox's Laws of Software Development
View foxs-laws-of-software-development.md
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
sleepyfox / 2021-10-22-simplification.md
Last active Oct 22, 2021
Simplicity, and abstractions
View 2021-10-22-simplification.md
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.

View 2021-10-06-continuous-retrospectives.md
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

View 2021-09-19-pairing.md
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
sleepyfox / making-good.md
Created Sep 16, 2021
On communication, and when it goes wrong
View making-good.md

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.

View 2021-07-09-why-3x-is-only-half-the-story.md

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
sleepyfox / 2021-06-09-better-workplace.md
Created Jun 9, 2021
On hiring, retention, and designing a better workplace.
View 2021-06-09-better-workplace.md

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:

@sleepyfox
sleepyfox / programming-as-theory-building.md
Created Apr 27, 2021 — forked from onlurking/programming-as-theory-building.md
Programming as Theory Building - Peter Naur
View programming-as-theory-building.md

Programming as Theory Building

Peter Naur

Peter Naur's classic 1985 essay "Programming as Theory Building" argues that a program is not its source code. A program is a shared mental construct (he uses the word theory) that lives in the minds of the people who work on it. If you lose the people, you lose the program. The code is merely a written representation of the program, and it's lossy, so you can't reconstruct