My new guilty pleasure, Pokemon Go, was supposed to be a fun past time. I’m in Vancouver this week attending CAST2016 and have had some time to walk around the city and hunt digital monsters. The game is fun, it is something I can easily do that doesn’t really have direction or purpose. Basically it is a nice way to distract myself from normal busy life.
Pokemon Go was released a couple of weeks ago, and and has become an overwhelming success. For me though, it’s been tough. The game has a lot of bugs, and every day I’ve been learning aspects of the game that are hidden because I am lacking 10 years of Pokemon background.
I was thinking about that nice distraction and some lessons about software development started jumping out. Especially around the idea of what lean and agile people call a Minimum Viable Product (MVP).
I’ve spent the last week in Atlanta, Georgia, at Agile2016, the world’s largest Agile Software Conference. The conference started Monday, but there was a preconference event all day Sunday, called the “bag packing workshop”, where I learned a quality assurance lesson.
The bag-packing workshop runs 8AM to 4PM, including two three-hour shifts of thirty people each, with a lunch break and debrief.
My hope was to show up and help out.
I didn’t expect it to turn into my biggest insight from the conference.
I can see burnout on the horizon. I’m trying to back peddle, but it is still there.
I did a quick Google search on preventing burnout, and this was the top result:
- Work with purpose.
- Perform a job analysis, and eliminate or delegate unnecessary work.
- Give to others.
- Take control, and actively manage your time.
- Get more exercise.
- Learn how to manage stress.
The list makes sense, but sometimes those things just aren’t possible. Last Tuesday, I was walking into the airport in Houston about to fly home. I got a call explaining that a contractor had dropped out mid-contract with no notice and 4 replacements had been pitched, and they wanted me. I’m already working a nearly full time software testing contract and have a few writing gigs like this one. “Sure, sign me up” I said. It’s important to help friends.
So here I am with too much work till the end of the month. It isn’t glamorous, and working too much isn’t a sign of valor. Right now I’m taking steps to avoid burnout and still be productive when this ends.
Last month, my colleague, Justin Rohrman, posted a piece on giving feedback here. Justin’s suggestion was the “Sandwich method.” The sandwich starts with a positive mention, then the thing that really needs to change, then ending on a positive note.
That might work for getting people to change behavior, but it’s terrible for supervision.
A few years ago I received a feedback sandwich. It went like this: Thank you very much for your work on projectX, by the way, this behavior is terrible and needs to change, gosh it is great having you on the team.
Think about the stress I went through in that moment. Am I doing well? Am I getting reprimanded? Is this the first step toward a written reprimand? I don’t know. I left the room more confused than when I walked in. That verbal message was on the way to my first and only written reprimand as an employee.
The sandwich is certainly a way to give feedback, it can work in some circumstances, and having more ways to do it is better.
Today I’d like to provide you yet another option: The Spot Correction.
The question of ‘do testers need to code’ is a little tired at this point. Alberto Savoia’s opening keynote for GTAC 2011 titled Test is Dead made a clear prediction of what he viewed was the future of testing. Elisabeth Hendrickson wrote this piece in 2010 based on data from job advertisements, not about the question of whether or not testers should code or not, but about what the market is demanding.
My opinion for a long time was that testers do not need to know how to program to be hired, or to be effective in their work. That was based on my experiences in the software industry from 2005 till today. My opinion is starting to change, but that isn’t because of dark foreboding keynotes or data from job advertisements. Most job advertisements are bad descriptions of what happens when someone gets to the keyboard.
So, I think that testers do need to learn some programming skills now. Let me tell you why.
I have been a cable cutter for more than a year now. Over that time we went from nothing but what comes over the antenna, to using ChromeCast to watch Netflix sometimes, to an Apple TV, and just a week ago we added the Amazon Fire Stick to the line up. Originally, we canceled cable as a way to save a few dollars a month on something that wasn’t really adding value to the household. With the variety of options outside of cable now, we might be nickle and dimeing that savings away.
Apple TV and the Fire Stick are the most recent, and most comparable products in our anti-cable TV arsenal. Having some time to use the Fire Stick now, I wanted to make a short review of the product and compare it to Apple TV for any of you out there that are thinking of canceling cable.
The software landscape has change, and somewhere along the way map designers messed things up for introverts.
I mean the literal landscape. Walk in a modern, with-it, software company and take a look around. Things are not like they were 10 years ago. Modern offices are built around forced, radical collaboration. The best examples of this are separate offices and cube farms being replaced by large rooms filled with long tables. Every one on the technical team now live and do their work in the same space.
This sounds like a productivity dream on the surface. Meetings disappear because everyone is already there, problems are solved fast because the people you need are just a table away. The reality is more like a dystopian future — noise, turf wars, and a general mess. Some people thrive on this, they like being around people and in the mix all of the time. Others though, people that are more introverted, tend to struggle because there is no refuge, nowhere to escape the constant murmur.
Let’s take a deeper look at why this new office topography may not last for every, and why it is hard for some people to work with.
Over the years I’ve done a fair amount of writing on #NoEstimates. Here on uncharted waters, then again, over at CIO.com, and again, and a few other places, here or there. I organized a couple of discussions at the Agile conference, one of them on the formal program.
Then, somewhere along there, I just … stopped. Perhaps it was because of the vitriol in the discussions. Two sides entrenched, not listening to each other, is not my idea of a fun time. Perhaps it was because of how little actual change I saw happening, the vast distance between the idyllic business novels and my clients. I saw some benefit to the predictive modeling work of Troy Magennis and Steve Rogalsky, and had some success myself in that area, but found myself slowly abandoning the hashtag.
After thinking deeply for a few years on the topic, and taking a couple years off, an idea or two has started to bubble in my mind.
I’d like to tell you about it. Continued »
A friend of mine gave a keynote at a conference a few years ago. I was there, and really enjoyed it, most people I talked with felt the same way. But, as always there were a few people that weren’t into it. Give talk to a large enough crowd, and there will be a few people that aren’t super excited about it. The interesting part wasn’t so much that a few people didn’t like the talk, but the kind of feedback he got. When asked, one person said “It just wasn’t that good” and didn’t offer anything else.
I was surprised that someone would give feedback in that way. Why would someone be so dismissive?
I have had my fair share of “it’s just not that good” and have been thinking a lot about it. Vague feedback is poison, so let’s find a little antidote.
In January I read a news report about the DeepSpec project that is being developed by a few universities through a NSF grant. The press release had some bold claims, specifically that this project might be the answer to many people’s dream of bug free software. I had as emotional reaction to that. Ever since software was a thing, people have been trying to make it bug free. But, no matter how detailed the specification is, or how much *DD the programmers use, or how good the testers are, there are bugs in prod. It’s just the way of the world.
Bug free software may not exist, but that doesn’t mean the DeepSpec research project isn’t interesting or potentially important. Princeton University in New Jersey announced a workshop on the project, so I put some skin in the game and went. Here is a little bit about what I found there.