There is always a well-known solution to every human problem–neat, plausible, and wrong.
– H.L. Melcken
It’s an interesting time in Silicon Valley. Microsoft, fresh off this summer’s reorganization, has ditched stack ranking, the controversial process by which all employees are rated, and the bottom fifth (or 10%, or some percentage) are ‘asked’ to leave the organization if they can not improve their scores. Meanwhile, according to the Washington Post, Yahoo has picked it up.
First, let’s examine the practice.
Checking Amazon, I just found that “The Joy Of Work” actually is the title of a Dilbert book.
Then Richard Sheridan, the CEO of Menlo Innovations, comes along and writes “Joy Inc: How we Built a Workplace People Love.”
When I hear the title, I admit, I was skeptical. Then again, I’ve known Richard’s team for a long time. A few years ago I interviewed his team about the massive parallel interview practice they have, called an “Extreme Interview.” When I visited the office, there was a bassinet, used when new parents came back to work — and brought the baby.
So when I heard that Rich was putting a book out about his company’s vision to eliminate human suffering in the world as it relates to technology, well, I was at least going to invest a few hours in it.
Here’s what I found. Continued »
What’s the best way to get to the hotel?
How do I ask for a menu?
Will everyone speak English?
Are there any tricks I should know? What will it be like?
Today’s blog post is all about answering those questions for Agile Testing Days – but really any conference held in the Dorint Hotel in Potsdam Germany. You’ll find the general travel tips may help for anyone from North America Travelling to Europe for the first time. Continued »
Okay, okay. I got that line from an annoying animated gif that I never clicked. Still, last week I was in Potsdam, Germany, at a software conference, picked up a way to improve performance on team retrospectives, and thought was worth sharing.
Perhaps I should say, I co-created a weird tip, which I will explain. Continued »
No, I’m not talking about scanning every known book regardless of copyright, getting users to log in then tracking their behavior in order to target ads. I’m not referring to how google inserted code in Android for NSA backdoor access, or turning over data to the NSA’s PRISM program.
Those are so last week.
This is Google taking over world, fall 2013 edition. You probably haven’t heard of this one yet.
But you should. Continued »
You may have met the type, and you know the combination is incredibly powerful. And also dangerous.
The classic advice to stay technical is to take as much as twenty hours per week – 6PM to 10PM, 5 days a week, to learn the new hotness. That’s fine advice, but at what cost?
20 hours a week, from age twenty-one to forty-one, is twenty thousand hours or about ten business years. Think of what else you could do in that time.
Let’s imagine those twenty-thousand hours as an investment, designed to generate enough revenue that you don’t need the tech job anymore.
Here’s five ways to do it.
– New graduates are cheaper, hungry, work hard, and are open to learning new things
– As people get older, it gets harder to learn new things
– Therefore the typical tech career is about fifteen years long.
After fifteen years, if you haven’t moved up into management, you’d better be working for a company where you have deep an intimate technical knowledge, inventing something new (eg be the author of Linux, create git, that kind of thing) or move on to some other field.
I can’t disagree the conclusions above, but if you don’t mind, I’d like to propose an alternate explanation for why – and perhaps what you might do about it. Continued »
If you are anything like me, at this point, you’ve heard lots and lots about the DevOps movement. Like so many other things in this world (“quality” and “architecture”, for example), DevOps is a term that everyone grasps immediately, everyone is sure what it means … and if you ask five people, you’d get six different answers.
Today, I’ll take a brief stroll through the concept, probably get shouted at in the comments, and eventually we may actually get somewhere. (This follows Heusser’s Rule: When other people can’t define something, tell them what you think it is, and they’ll be happy to correct you.)
This week the paperwork finally came in for me to do placement for a client – three software testers in sunny Florida, relocation provided.
So yes, I have spent a lot of time on Linkedin lately.
Along the way, I noticed something strange – many of the job descriptions people post for software testing begin with something like “Create and Execute Test Plans” or “Create and Execute Test Cases.”
Who Talks Like That?
I mean, do know a programmer who “Creates and Execute Programming Plans”? Or a manager who “Creates and Executes Management Plans?”
The statement “Creates and Executes Test Plans” is really just saying “I plan my work, then I do it”, with the term “Test” thrown in; it is content-free.
You could say it of anyone.
When I see that on a linkedin profile, it’s headed to the ‘do not contact’ pile.
A Different Way To Do It
Yes, as part of the job, some testers create and execute test plans. Sure. That is the accident. I’m more interested in the essence – the why – the problem that testing solves. I’ll explore that with a 5 why analysis.
Why create test plans? Because the customer wants testing to occur.
Why should testing occur? So the software can ship.
But why does the software need to ship? So the client can use it.
But why does the client want to use it? For the value that customer will see when they use it.
That’s the thing.
The customer doesn’t care about the test plans; she just wants to be able to buy books from Amazon on her iPad. That’s it.
Imagine two fast-food workers, one who “prepared fries and burgers according to purchase orders” and another who “Satisfied customers by providing warm, fresh food quickly.”
That is a huge difference. It can be used on any job, from the intern to CEO.
But … Why Do So Many People Write Resumes Like That?
The programmer who writes “Creates unit tests in jUnit”, the DBA who “Tunes using SQL*Plus profiler”, and everyone else who writes in this stilted way, is doing it for a reason — they want to get past the folks in HR who scan for keywords.
The keywords got their from a job description, and the person who wrote the job description wanted it to be vague enough to not have to change every year, and to be able to span departments, and a thousand other reasons.
It’s all part of a game, using the same words as everyone else, doing sort of like what someone did before with the same words. Don’t rock the boat, go along and get along, if you need to put these words on a resume to get ahead, well, of course you should do it right?
We Can Do Better
I don’t blame the people who write “Create Test Cases” on their job descriptions, who hope to work within the system, to get past the legion of HR-scanning drones and get a chance to speak to a hiring manager. It’s okay. I get it.
If you find yourself in that position, though, I would like to offer a word of warning, and another of comfort.
First the warning: Organizing your resume, and pursuing a job in traditional ways, can be sort of earning one of those obnoxious certificates you don’t really believe in but HR seems to care about too much: It might just get you the job that you don’t want to have.
Second, the comfort: There are people recruiters and (many more) hiring managers who have a perspective like mine — they care about results and skill more than buzzwords; the essence of ability over the accidental elements.
Working for those folks is a lot more fun.
So if you’d like, take a look at that linkedin, that resume, or even how you position and explain what you do on the day job — and consider what kind of client you are attracting, who you’d like to attract, and what you should change.
The next step?
That’s up to you.