In 1623 the German Wilhelm Schickard produced the first known designs for a mechanical calculator. Twenty years later Blaise Pascal produced a machine of an improved design, aiming to help with the large amount of tedious arithmetic required in his role as a tax collector.

The interest in mechanical calculation showed no sign of reducing in the subsequent centuries, as generations of people worldwide followed in Pascal and Wilhelm’s footsteps, subscribing to their view that offloading mental energy to a machine would be a relief.

TDD, BDD, DDD, Agile, SAFe, Scrum, Kanban, XP… there’s a lot of ways to skin a cat write code in a professional environment.

I take pride in being a person who is a non-ideologue when it comes to my code. There are many good ways of working, and they are all context-dependent.

You can’t apply the same things that worked when you were a two-person startup operating out of the proverbial garage and expect them to work once your hypothetical unicorn has reached a thousand-plus developers. Even within the same organisation, processes that work for one team can be catastrophic when applied to their neighbouring team.

This series is a place to collect interesting things I’ve seen, read, or heard, along with some brief thoughts (often incomplete and/or inconclusive) that they provoked.

The rise of Whatever - eevee

This is probably the best post about LLMs I’ve read, which is probably why I’m the millionth person to share it. It really sums up my emotional reaction to their meteoric rise: “ew”, basically.

The power of the argument is that it identifies a theme that runs through recent tech changes, of which LLMs are just the latest and greatest example: the lack of care for quality, and the realisation from Big Tech that consumers mostly are fine with mediocre output.

Last week I facilitated a session at XTC, where we discussed the new product development framework from Basecamp, Shape Up, led by Thomas Ankorn.

It was a really interesting discussion with people exploring the ideas openly, guided by questions posed by Thomas to get the conversation started.

I’ve summarised the points that came up in the discussion, reconstructed from memory and the collected post-its of scribbles at the end of the evening.

1. What problems does this solve?

We started by looking at the positives of the framework, trying to identify strengths that would help mitigate problems we have encountered in our own teams.

DISCLAIMER: This was not my idea - I picked it up from Jane Nicholson at an XTC event, who was introduced to it by Jess Gilbert (who in turn, I am told, got it from someone else). This post is just explaining why I believe it can be a useful exercise, not any truly original thinking!

One of the things that is really important to me is that my team and I keep learning at work. As such, fostering a learning environment is kinda key. I think we do that pretty well at Haplo – we have hired nearly exclusively early-career developers to our tech team for several years now, and one of the key points most hires mention as to why they join is that they feel it’s a good place to learn quickly, with the requisite support early on in their career.