Hiccupps

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...

I'm slowly learning German ... for fun, believe it or not.  To limit my time commitment I've been mostly studying with lessons on apps or in-person supplemented by YouTube, ChatGPT, DeepL, blogs, an ancient CD-based box set that my well-meaning parents bought in a charity shop, subtitled German-language films and ... Peppa Wutz.   I've pushed ahead in some areas, for example by completing Babbel lessons all the way to  B2  even though I'm nowhere near speaking at that level, and starting again at  A1  even though I'm well past it. Being exposed to the advanced content can give some useful context, and redoing the basics can cement understanding, reinforce learning, and make connections that were missed the first time around. What I wasn't doing was rote learning verb conjugations, grammatical structures, or vocab lists. And that was fine for a long time, at least until I got good enough to have simple conversations...

I'm enjoying The Vernon Richard Show  a lot recently because the vibe Vern and Richard have created is one where two knowledgeable and experienced mates talk around a topic they are both interested in with curiosity and open minds.  Also, there's less football than there used to be. This week's show is titled When Everything Sounds Like Testing… How Do You Explain What You Really Do?  and sees the pair discussing the meanings of quality assurance, quality engineering, testing and other related terms. There's no firm conclusions, and enough left unsaid that they're carrying the dialogue over into the next episode, but I was still interested to see these two models put forward: In the first, proposed by Vernon, quality engineering consists of preventing bugs (QA) and detecting bugs (testing). In the second, floated by Richard almost in spite of his better judgement, quality assurance is the holistic term. In this ver...