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

When my dad retired around 20 years ago, I got him a second hand PC and have been serving as first, second, and third-line tech support for him and occasionally his mates ever since.  He's an inveterate story teller and, for a laugh, one time I told him he should write all of his tales down and give them numbers. Then, instead of telling them (again) he could just say the number and we'd all laugh, saving everybody time. Well, he called my bluff so I'm now mid-way through editing a 300-page Word document he sent me and if I ask him about a detail of one of the stories, he recounts the entire thing. Clearly my idea has backfired spectacularly. Even funnier, this opus only describes his early life in Smethwick and the various jobs he had between leaving school with no qualifications and retirement. Our family stories are in another epic file I haven't even seen yet! The joke is well and truly on me. Still, the pages are full of gold and h ere I'm sharing an escapade...

Introduction James : A few years ago, Claire, a friend from the Cambridge tester meetups, asked if I’d be her mentor. I said yes and we collaborated for around 12 months as she took stock of her role and career direction, and worked to get to where she wanted to be in both. We blogged about it in Don't be a Prick . Then, last year, I found myself doing the same thing with a colleague from my team at work, Yasemin . We’ve just ended that relationship and now we’re blogging about it too! (Thanks to Claire for suggesting we should.) Yasemin : Two years ago I moved from Turkey to Berlin. I know that I thrive on learning new things and challenging myself with joy, and what better way to do that than in a new culture, language, and company? And it has been an adventure: I've had brain surgery, taken a journey of self-discovery, explored new opportunities, and really pushed my limits.  One of those opportunities was meeting James. I watched him work for a year, observing how he inclus...

My friend Rachel Kibler asked me the other day "do you have a blog post about why we test software?" and I was surprised to find that, despite having touched on the topic many times, I haven't. So then I thought I'd write one. And then I thought it might be fun to crowdsource so I asked in the Association for Software Testing member's Slack, on LinkedIn , and on Twitter for reasons, one sentence each. And it was fun!  Here are the varied answers, a couple lightly edited, with thanks to everyone who contributed. Edit: I did a bit of analysis of the responses in Reasons to be Cheerful, Part 2 . --00-- Software is complicated, and the people that use it are even worse. — Andy Hird Because there is what software does, what people say it does, and what other people want it to do, and those are often not the same. — Andy Hird Because someone asked/told us to — Lee Hawkins To learn, and identify risks — Louise Perold sometimes: reducing the risk of harming people — ...

Earlier in the year Lena Wiberg posted an interesting challenge on Twitter:  I would like to pair up with other writers and do a series of pair blog posts. So we agree on a topic, we both write a post on our own blogs and publish at the same time. 2 perspectives for 1 topic! Any takers? Swaps are fun, so I signed up and Lena asked me for a topic. After some consideration I proposed "testing skills I use in management" for the selfish reasons that I'm interested to hear what she has to say on it and also to collect thoughts that I've had over the years into one place.  --00-- I spent quite some time early in my managerial career observing how I went about my work, finding what I liked and what I didn't, and deciding what my guiding management principles appeared to be and should be. This is what I came up with: Be clear and present Be congruent  Provide...

This is a joint post with Claire Banks about a mentoring experiment we conducted for six months last year. We describe how it started, how we organised it, how it went, why we stopped, and how we feel about it now. Starting Claire : I’ve been testing for more years than I care to remember. I am one of many that ‘fell into testing’ around the time of the hyped Y2K bug . I have held a variety of roles from being a test team member through to manager at numerous different companies and industries over the last 19 years. Given this wealth of experience, why on earth would I want someone I can talk things through with and seek advice from? Surely I should know it all? Well, no. I don’t know it all and never will. Plus I have a confidence issue. At CEWT #4 I presented on why I would never be a test manager again. I reflected back on my career and was struck by the realisation that I’d had: 16 years in testing 12 different companies 25 test managers 3 great test manage...

When Sneha Bhat asked if I'd present with her at CEWT #5 the talk we produced was Theoreticus Prime vs Praktikertron . In this essay we've tidied up the notes we wrote in preparation and included a few of the sketches we made when we were developing our model. The title comes from the Transformers we gave the participants at CEWT to explore in an attempt to illustrate different kinds of theory being discovered and shared. CEWT #5 asked this question: theory over practice or practice over theory? It's an age-old conundrum, represented in popular culture by memes like these that you would have seen as you avoid both theory and practice by grazing on social media when you should be working: In theory, there is no difference between theory and practice. But, in practice, there is. ( Wiki ) Theory is when you know everything but nothing works. Practice is when everything works but no one knows why. In our lab, theory and practice are combined: nothing works and no...