I was eavesdropping on a conversation about vetting technical skill during an interview in a local Slack channel last week. One person suggested live programming or logic exercises on a white board. Others responded that this is inhumane and rigged against people that need a quiet space without people hovering over their shoulders to respond to this type of challenge. Another person suggested a take home exercise that someone could complete over the course of a few days and email back for assessment during the interview. Yet another group of people said that this type of challenge only assesses privilege. They claim person that has disposable time and resources to complete an at home programming challenge has an unfair advantage over the person that works full time, has a family at home, and has little disposable income to build a good development environment at home.
All of these perspectives have a little truth in them of course. But, we still need some way to understand what the technical skill of a candidate is. I have interviewed a few people over the years and have learned a few lessons along the way.
You might remember some of the product announcement keynotes that Steve Jobs delivered at the end of his career. Just as you thought the presentation was over, Steve would say “oh, and just one more thing”, and introduce product, like the iPod, iPad, or iPhone. Each of these took a technology that already existed but cumbersome and made it available for the masses. He presented the idea as a new category of device – and held his ground.
Steve began by introducing each device with a tag line, such as “a thousand songs … and it goes right in my pocket.”
He would also make and project his own judgements about the product – that it was “amazing”, “wonderful”, “beautiful” and magical. Journalists would copy those words without thinking, and the readers of those articles would assume they were the judgements of the journalists, not just a repeat of what Jobs said. The techniques Steve used have even be parodied by sites like college humor.
Steve projected a reality where the products were the best thing ever.
You may have watched some of those videos, thought you “had” to have the product and realized, six or eight months later, that hey … it’s just a tablet. It’s pretty, and has some cool games, and it might be easy to carry and combine multiple features, but it’s a tablet. Buying it did not make us better humans.
As of this morning, a google search for “Steve Jobs” “Reality Distortion Field” yields over forty-seven thousand results.
I attended and spoke at the first run of Music City Agile last Wednesday. Music City Agile is a one day conference themed around, your guessed it, agile software development. A sister conference, Music City Code ran the following Thursday, Friday and Saturday. Jim Benson ran the opening keynote on Post-Agile Stress Disorder (PAST). Jim presented what seems to be a more common theme: consultants arrive at a new gig and present a set of tools and process that will fix every problem. Once that consultant leaves, the tools stick and the process mostly washes away. New consultants arrive at a regular pace and present their preferred tools and process. This happens over and over again.
All in all this was a very well run conference. I’d like to talk through a little of my experience with what Jim described in his keynote.
That is, the technical staff feel they are not heard, but when we get down to talking, they often don’t know how to ask.
Today I’d like to talk about assertive communication, and how different it is from passive, using When I Say No I Feel Guilty as a sort of field-guide.
I got back from the annual Conference for the Association for Software Testing (CAST) last Thursday morning after catching a red eye flight from Vancouver, BC to Nashville. I am one of the tortured souls that are unable to sleep on overnight flights. I get glimpses of sleep here and there, but nothing long enough for it to feel like a real night. Recovering from the flight, and the energy spent at the conference gave me some time to reflect on the day 2 keynote on neurodiversity in technology from Sallyann Freudenberg.
Sallyann’s talk was powerful, bringing many audience members to tears during her presentation and then again during the Q&A segment at the end. It seemed that people in the audience were discovering things about people around, and themselves at the same time. There were two big messages in the talk — foster varied perspectives on your technology teams, and also nurture the variation you already have.
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.