Hiccupps

The Wikipedia page on infinite loops in programming describes them as "a sequence of instructions that, as written, will continue endlessly, unless an external intervention occurs." One common example might be a while loop whose exit condition is never met, and needs to be aborted by a human pressing Control-C . With that concept in mind, we can make an easy analogy to software development where the same kinds of events happen over and over and over until our product becomes irrelevant, or uneconomic, or our organisation closes down, and the loop is exited.  Inside the loop, the world in which our product exists will change, the market in that world will change, the requirements on our product in the market will change, the product itself changes as our teams add features, or fix bugs, or update libraries, or run on new platforms, and so on.  So, for their lifetimes, our products inhabit an infinite loop of change and, if the...

I was guest speaker for a software testing class at EC Utbildning  a couple of weeks ago. I talked about one of my hobby horses — using automation to amplify my ability to explore — and I'll give the same talk at the Ministry of Testing Cambridge next Tuesday. Perhaps you can make it? Chatting with the Swedish students on the call before my presentation I asked what they liked about testing and, as no-one seemed to want to go first, I gave my own answer: I enjoy testing because it mixes technical, social, and intellectual challenges. And that's true but it isn't always enjoyable in the moment . Last week at work, in a small group session, I offered to share my screen while we tried to exercise and then, when it wasn't working, debug some new monitoring functionality. Honeycomb is a valuable tool, and I've used it plenty of times, but not at an expert level. The instrumentation we'd been developing is based on existing...

In Your job is to deliver code you have proven to work  Simon Willison writes: As software engineers we ... need to deliver code that works — and we need to include proof that it works as well.  He is coming at this from the perspective of LLM-assisted coding, but most of what he says applies in general. I think this is a reasonable consise summary of his requirements for developers: Manual happy paths: get the system into an initial state, exercise the code, check that it has the desired effect on the state. Manual edge cases: no advice given, just a note that skill here is a sign of a senior engineer.  Automated tests: should demonstrate the change like Manual happy paths  but also fail if the change is reverted.  He notes that, even though LLM tooling can write automated tests, it's humans who are accountable for the code and it's on us to "include evidence that it works as it should." Coincidentally, just the week before I read his post I told one of my...

In yesterday's Angry Weasel newsletter, Leadership is a Constant Experiment , Alan Page was explaining how, as a leader, he gets better results by trying things intentionally, in public, in a safe way: But in real work, confidence isn’t the superpower. Curiosity is.  I feel this too, although confidence, or the appearance of it, can get you a good way up the greasy pole, if that's your chosen destination.  In a post on LinkedIn today, John Cutler made an analogy between a software development teams and a restaurant kitchen where busyness is not a useful metric, and success means that great food is delivered as ordered in a timely fashion. He sadly concludes that: ...  in software, effort is easy to generate, activity is easy to justify, and impact is surprisingly easy to avoid. This is a tragedy that plays out over and over. My primary goal in software is to help us to metaphorically put the right food on the right plates on the right table at the right time more oft...

Last night I was at the Cambridge Tester meetup for a workshop on leadership. It was a two-parter with Drew Pontikis facilitating conversation about workplace scenarios followed by an AMA with a group of experienced managers. I can't come to work this week, my cat died. Drew opened by asking us what our first thoughts would be as managers on seeing that sentence. Naturally, sadness and sympathy,  followed by a week ? for a cat ? and I only got a day for my gran! Then practicalities such as maybe there's company policy that covers that , and then the acknowledgement that it's contextual: perhaps this was a long-time emotional support animal . Having established that management decisions are a mixture of emotion, logic, and contingency Drew noted that most of us don't get training in management or leadership then split us into small groups and confronted us with three situations to talk through: Setting personal development goals for others. Dropping a clange...

I bought a belt recently. Unexpectedly, it came with a tool for making holes and the notice above. My initial reaction was to chuckle and think "yeah, we could probably all learn something from that." But, honestly, that's just lazy. That's the cheap laugh. That's this misguided thinking:  DO NOT OPEN THE EDITOR BEFORE YOU FINALISE THE REQUIREMENT And I am so over that.  When asked what advice I would give to the early-career me I've often answered: get comfortable with uncertainty.  In the spirit of today's post, I might rephrase that as DO NOT HALT THE WORK BEFORE YOU ENCOUNTER THE BLOCKAGE Of course, this is what iterative development is predicated on. By the time we've coded what we can, and shown it to our customers for feedback, we might find that we understand the problem space well enough to not need answers, or that we were asking the wrong questions. What I like these days is to understand t...

  It's all relative. There's enough wrong in the world that having an imperfect job in tough economic times is still a privilege that many would cherish.  And yet, in its own isolated context, the daily grind can genuinely feel like being physically ground down, minced, fragmented.  Which is why it's important to find a glimmer of joy where you can. And I found one this week, in the accidental coining of the word cliction, a portmanteau of click and friction,  while exploring the user experience of a new front end. It doesn't solve any global, or even local, problems, but it raised a few smiles and lifted a few eyebrows, and improved my mood. I hope sharing it can do the same for you. Image: Gemini , " A close-up view of a human finger (drawn simply) gently touching or hovering over a single, large computer mouse button"

It's 14 years since I first posted on Hiccupps and one since I wrote about about  using trees for my mental health . Both practices are ongoing. Trees first: every Saturday I find a space with trees and spend a few minutes of silence with them. I breathe slowly and deeply and I look up through the branches to the sky, visualising a tangled journey into the blue, imagining it is my path to a better place.  The picture at the top is from the park around Schloss Lübbenau because last weekend I was in Germany but it can be any tree, anywhere. I have done it with a single tree on a quiet street corner. Blogging next: I am often asked why I blog. Sadly, I don't have a straightforward answer. On one level I just like to write. Before I wrote this blog I wrote a music fanzine for ten years. I genuinely can't remember when I didn't write something . It feels intrinsic, part of me.  My anniversary posts  talk about different extrinsic motivations at different times: I had exp...

Jerome Groopman, in How Doctors Think , reviews ways in which doctors can make poor choices, identifies potential causes, and suggests some practices, for both doctor and patient, that can help to prevent them. I find this interesting for a couple of reasons: first, I work in the health space, although not in a therapeutic area and, second, I like to reflect on my own thought processes. I'll take three broad themes from Groopman's analysis: the business of healthcare and how that impacts a physician's ability to practice; the doctor-patient relationship and how that impacts the experience of both sides; and the cognitive failings that impact a correct and timely diagnosis for any given patient. Naturally, these overlap. The book is written from the perspective of the notoriously commercialised American medical system and is around 20 years old, so doubtless some of the details are different outside of the US and have changed since pu...