Hiccupps

We are generally not the target users of the software products we work on.  That's not to say we never use our applications or that we have no interest in those who do, but mostly we rely on feedback from elsewhere to tell us whether needs are being met.  Sure, as testers we'll interact with the software and maybe even consider ourselves to be a proxy for users. Yes, we'll probably have people in product and business roles translating, or inventing, customer requirements for us. And, yes, perhaps we'll even dogfood the stuff we build sometimes, to some extent. I've lost count of the number of times I've asked developers whether they ran the software after their changes and been told that the tests pass. I've lost count of the number of colleagues I've had who work on a service and have little or no idea what clients it has and what kinds of tasks their users are trying to complete or why. I've lost count of the number of times I've been in argume...

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