Once in a while, I think we all find some statement we read somewhere, while doing something, that sticks with us. I have *definitely* found that to be true very recently, mostly because it puts into words a concept that has rolled around in my head for quite some time.
First, some background .... If you read my blog, then you know that I have been known to rant, at times. Really, I try not to, but it happens. Sometimes, it is just that I want *so badly* for others to change, and I have a hard time understanding why people don't just *do* things the best way, all the time. Often, when I find others to talk through the issues I am encountering, they ask me questions like "Why do you still work for that place! It's hopeless!" (Sometimes, I believe it is, and I leave, as I did in 2008.)
Sometimes, however, I stick around for a while, and I have a hard time explaining why. And then, recently, I saw a sentence that resonated with me.
Twitter was all abuzz recently with responses to Joel Spolsky's recent blog about "The Duct Tape Programmer". He quotes Jamie Zawinski, and Elisabeth Hendrickson (@testobsessed) pulled out Zawinski's resignation letter from AOL.
This one quote resonated with me, and continued bouncing around in my head:
"...you can divide our industry into two kinds of people: those who want to go work for a company to make it successful, and those who want to go work for a successful company."
It rolled around in my head for a few days .... Did I agree? Did I think that people could generally be so easily divided up into just those 2 groups? Probably not quite *that* easily, but for many people that I have encountered in my career, I could place most of them into one of those pretty quickly.
For a while, I have described these groups in the following way: people either seem to come to work because it's a job, and they do their job, and that's it, OR they seem to be really passionate about *what* they do, and are constantly striving to make things better. I fall into the latter of those 2 categories. I most certainly do what I love and love what I do.
But Jamie's sentence looked at things from just a slightly different point of view, and after thinking about it for a bit, I believe, describes *me* just a little bit better. I have *always* wanted to work to make things great, and not so much wanted to work for/with/on things that were *already* great.
This can be applied to many aspects of my life. I was the single mom who put herself through college, working full-time and taking full-time classes in CompSci. I am the vocal advocate of a high functioning autistic child who wrote to the local newspapers when the school district was failing at its job. I chose to bring a Siberian Husky into my home (this sounds silly, but Husky owners will tell you .... WOW).
I THRIVE ON THE CHALLENGE.
That's it, that's me. That's why I like testing over development. I have said for years that developers have to find one way to solve a problem and testers have to find ALL ways to un-solve the problem. Testing gives me the challenge of being creative, being technical, being analytical, speaking in at least 2 different languages, juggling an obscene number of balls in the air and being squeezed and sometimes disrespected along the way. But, it's a challenge, and I like a challenge.
In the same way, companies that are struggling, companies that don't "get it", and have fallen into the proven patterns that destroy great ideas, are a CHALLENGE. They are high-risk, for sure, and sometimes they offer little reward other than knowing I am doing my best, but *if* I can affect change, *if* I can help, the reward is incredible.
I believe that for "successful" companies (I place "successful" in quotes because this is a relative term .... for me, in this context, it is mostly about doing things the best way possible), I would personally gain little reward because there would not be *enough* of a challenge.
I wonder, then ... how many other great testers that I know are like-minded? Do other people enjoy testing because they enjoy a challenge? Would they generally choose to work to make a company successful, or choose to work for a successful company?
4 comments:
Interesting post, Dawn, I had never thought in these terms before.
I definitely prefer to work for a successful company. However, I still find plenty of challenges. My team at ePlan rocks, but we were always finding ways to do a better job, and every team periodically runs into a crisis.
My current employer is a very successful company, but we could be doing a lot better overall at software development.
I think my bottom line is: if I think I can make a difference, I'm happy. Some companies are unsuccessful because they get in the way of their good people and prevent them from being able to contribute. I run away from those companies.
Thank you for a great post. And, as always, having such an amazing attitude!
I think Lisa is on to something - if the company won't let their good people contribute then you might be fighting a losing battle.
But, I agree with her "if I think I can make a difference, I'm happy"
I have to admit, sometimes I think I'm guilty of being excited by the chaos if I see a path to improve it because it means we can make such a great difference and that can be the most satisfying thing in the world!
There are some really good points made here. The only thing that makes me nervous is the way you describe a tester/developer divide. Why does such a thing have to exist at all?
I so often hear people say "Oh, that's the testers job" or "Oh, that's the developers job" or "Oh, that's the BAs job" and so on.
If the only people who genuinely care about the quality of the product are the testers (and the term QA goes some way to propogating this), then the team is fundamentally broken.
A successful team is one where all people care equally about the delivered product. "It's someone else's job" is an organisational smell. I've been known to pick up rubbish strewn across the desk if it's causing the team to run slower. I'm a pretty expensive cleaner :-)
At the end of a day, a successful company is one where everyone already has this mindset. Working to make your company successful may be more of a challenge. Working to instil the "success attitude" in the team is probably the biggest challenge of all.
Antony makes a good point about dynamic roles within teams
Andy,
Your comment has had my brain going all day long. I've wondered about exactly this before, and struggled with how this is supposed to look.
In practice, I have yet to see a team that is *truly* flat, without roles defined. I wonder why that is?
In Antony's article, I picked up on one important thing, though -- the highlighted text (int eh callout) talks about not having to *wait* for a certain role to finish what they are doing in order to move forward on what you are doing.
Completely! I agree ... but does that mean that a team shouldn't have people who are better at testing than others? And that they shouldn't try to balance this out?
I suppose I am not disagreeing with you, either, tho. I myself fight the old "you can't fix that bug, a developer has to do that". I think that's ridiculous.
On the other hand, however, I would also like to see that someone with that natural curiosity, that natural affinity for seeing a problem from all sides, spend a good chunk of their time *using* that ability, too.
How can a team be so truly flat, but also optimize each individual's natural talents?
I smell a different blog post coming ....
Post a Comment