Hiccupps

  My friend Mirek wrote an interesting post recently: Where Rust fits for me . In it, he made a hierarchy of the programming languages he reaches for on a regular basis and why he picks a particular one for any specific task. I'd summarise it crudely like this: Shell: only for very basic setup. Anything with non-trivial logic belongs somewhere else. Python: his go-to but with caveats about the expected lifetime of the code: if it needs to persist without regular attention then Python won't do. Rust: Whatever doesn't fit in the other two categories.  I enjoy seeing people be thoughtful about their tools and reflect on the way that they work. Understanding what you do and why is a helpful first step on improving what you do and why, should you want to. And I always want to. So I thought I'd attempt the same kind of analysis and started listing languages that I use regularly: Groovy : I use Groovy exclusively in Jenkins pipelines. It's useful to have a little familiar...

The map is not the territory. You've heard this before and I've quoted it before . The longer quote (due to Alfred Korzybski) from which the snappy soundbite originated adds some valuable context: A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness. I was thinking about that this week as I came to a product new to me but quite mature with a very rich set of configuration options. When I say rich , I mean — without casting any shade, because I have been there and understand — it is set in multiple locations, has extensive potential effects, and is often difficult to understand.  For my current project I consider it crucial to get a non-shallow view of how this works and so I began to explore. While there is some limited documentation it is, as so often, not up to date so mostly I worked in the codebases. Yes, plural, because this product spans multiple r...

In simpler times you had to go out of your way to find useless motivational banalities. There'd be an aisle in the shops that you could easily avoid or a spot on the office kitchen wall next to the milk rota that you could stare straight past while the kettle boiled and you fantasised about another job.  These days, unless you've vacated social media, it's much harder to avoid having decontextualised generalities with a side of misleading infographics thrust in your face. I scroll hard past that crap but I was reminded of one that comes around frequently the other day. It goes something like these ( 1 , 2 , 3 ): "Ready to unlock your 38X potential in just one year?" "Imagine being offered a 365% return on any investment!" "Every day: 1% stack or 1% slide. You choose." Naturally, "better" and "return" and "stack" are pretty vague and the directions for achieving these easy wins are even more so...

If you've met me anywhere outside of a wedding or funeral, a snowy day, or a muddy field in the last 20 years you'll have seen me in Adidas Superstar trainers. But why? This post is for April Cools' Club .  --00-- I'm the butt of many jokes in our house, but not having a good memory features prominently amongst them. See also being bald ("do you need a hat, Dad?"), wearing jeans that have elastane in them (they're very comfy but "oh look, he's got the jeggings on again!"), and finding joy in contorted puns ("no-one's laughing except you, you know that, right?") Which is why it's interesting that I have a very strong, if admittedly not complete, memory of the first time I heard Run DMC. Raising Hell , their third album, was released in the UK in May 1986 and I bought it pretty much immediately after hearing it on the evening show on Radio 1, probably presented by Janice Long, ...

  I told you how much I love Kill it with Fire by Marianne Bellotti in This is Fire and you can see it in my copy above too. It's a book about dealing with legacy systems but in the first couple of chapters grounds its thesis in the marketplace, thinking about how products, the constraints on them, and the context in which they sit change in controllable and (more often) uncontrollable ways. This might not seem very "tech" but in fact is fundamental to understanding how we seem to bounce back and forth between the same kinds of solutions, why some of them become legacy, and why we should think carefully about radically changing a working system. To be clear, this information is not necessary to get the core benefits of the book but I found it fascinating and wanted to try to triangluate concepts such as Alignable and non-alignable differences Service-dominant Logic Hype Cycle Unique Selling Proposition Cro...

  Kill it with Fire is ostensibly a book about legacy systems but is packed with good advice about managing any significant project. In one chapter Marianne Bellotti talks about gathering consensus, showing progress, and maintaining momentum. It's probably coincidental but she happened to use several words that start with "pr" when describing some of the key aspects of her approach. I liked the description a lot, but I also liked the pun, so I recast the broad ideas with a Public Relations head on: Provoke a need. You'll have observed that people tend to care more about urgent than important. What urgent hook can you hang your important project on? Is there a security issue, a performance issue, a cross-team ambiguity, or anything else that can be used to motivate others?  Promote the value of the project to whoever matters and will listen. Be prepared to cast the value in their terms rather than yours. The head of marketing doesn't give a crap about your tech de...

    Kill it with Fire is by Marianne Bellotti is a truly awesome book about dealing with legacy systems. If you're in software you need to read it and this high-level summary is my attempt to persuade you to do that, right now. What is legacy software? an existing system, onboarding is probably hard because of its age, design patterns are probably consistent but out of date, it will probably still scale if the infra scales.  (Note that tech debt generally isn't legacy by this definition, although that doesn't matter. Much of the book is relevant to both.) How do we end up with legacy software? Choices made over time, decisions that seemed pragmatic, unexpected or undesirable constraints, re-orgs, accidents, compromises, ...  Why do we seem so keen to throw legacy software away? Because writing is easier than rewriting, because we bias to see only the positive possible outcomes, because we can try our ...

In a recent episode of the Vernon Richard show , testing's dynamic duo were inspired by Valentine's Day to talk about their love for our craft. On the topic of tools, Richard sings the praises of Selenium, but Vernon takes a different tack, instead talking about tool creation ... and me!  I worked at the same company as Vern for a couple of years and we'd find time to pair on something most weeks even though our responsibilities didn't overlap at all. Sometimes he'd bring a problem, sometimes it'd be show-and-tell about what we were working on, occasionally it was about people and process, but what really lit him up was when we looked at code together, particularly if we built something. I was out walking and listening to podcasts when the episode popped up in my feed. Honestly, it was a strange feeling to hear myself being talked about, even though Vern gave me a heads-up that he'd done it just after it was recorded. What he said is nothing that he hasn...

Whatever our workplace constraints, we have agency over our own actions and the choices we make impact us, those around us, and the work we do together. We'd prefer to make good choices, naturally, but good for who, when, why? In a short talk that I gave to one of my teams this week, I pulled out nine heuristics for working that have served me well over the years. Heuristics are rules of thumb: things that generally give the right kinds of result but are fallible, a good default but not a guarantee.   The talk covered three core areas: being clear to yourself and others navigating relationships doing the work effectively and here's the slides: You'll notice that there are no credits in the slides themselves. Instead I linked to blog posts where I've pointed to the sources and commented on the interpretation I've taken, or the use I've made, or the value I've extracted. That's important, because these ar...