How Did I Get So Jaded?
How Did I Get So Jaded?
Churning out medium-grade software to meet deadlines, and experiencing critically defective projects over the years, can easily wear down optimism till it gives way to cynicism in the software testing and quality professions. In this column, Eileen Strider empathizes with that tendency and offers ideas that may improve the quality of your experience.
I was talking to an IT consultant the other day and she said, "I'm almost fifty; I've been in IT since I was sixteen and I'm pretty jaded." Like me, that's more than thirty years of IT experience. For some of us, we feel jaded after only three or four years.
How does this happen? We begin each new job and project with excitement and high hopes. We anxiously apply our technology to deliver significant value. Yet somewhere along the line, we start noticing recurring language and patterns. We listen, bored, to "Our project is different." We are fed up with ineffective management techniques such as understaffing, over committing, overly ambitious schedules, and blindness to risks. We are worn down by our inability to deliver enough software, fast enough with high enough quality.
After experiencing these patterns, it's easy to become jaded, disillusioned, cynical, hopeless, and even seriously depressed. I've found myself in these states time and again during my thirty-one IT years. Is this our reward for trying to deliver quality software on time and within budget?
The Chinese symbol for the gemstone jade, "yu," contains within it the symbols for the heavens, the earth, and humankind. This seems appropriate because I think we begin our projects with our sights set on the heavens and are quickly brought down to the earthly reality that we are dealing with mere humans and manmade technologies.
However, this symbol "yu" is also the same one the Chinese use to describe something precious (as in, "precious as gold"). So the question becomes "How do you turn your jaded perspective into precious experiences?"
Turning a jaded view into valuable experience is your choice. This is a simple concept, but it is not easy to actually practice. It takes hard work to develop this ability. And more important, it takes a willingness to reshape your views.
Each time we experience something, we make a meaning out of it-in other words, we "frame" the experience. Each of us frames a current experience based on personal expectations and past experience as well as individual values and beliefs. If the current experience meets your expectations and matches positive past experience, values, and beliefs, you will frame it in a good light. If the current experience fails to meet your expectations or match your values and beliefs, and it recalls a bad past experience, you are likely to frame it negatively. After some number of negatively framed experiences, your feelings accumulate into a jaded view. As you collect a repertoire of these negative experiences, you are more likely to go into the next project with a cynical view before you even start work.
Just as we have the ability to frame an experience as "bad," we also have the ability to re-frame the same experience as "good"-or at least as "an experience from which we can learn." Have you ever noticed that an experience you framed as "bad," someone else framed as "good"? How can that be? It's because the "frame" is something you assign. It's not inherent in the experience itself. The meaning is in your interpretation.
Now, I'm not suggesting you change your values and beliefs or reframe an experience just to feel better. Rather, I'm suggesting that you choose how you frame your experience by setting expectations realistically. For instance, if you start with an expectation that "this project must produce a perfect product," then you will be disappointed if it doesn't. If you frame your expectation as "I want to produce the best product I can within the project constraints," then your expectation may be met. Many IT professionals have extremely high expectations of themselves, coworkers, their companies, and clients. This isn't bad, but it may be impossible to meet them consistently, which can set us up for repeated disappointment. In effect, we create our own self-fulfilling jaded view.
And how about a project that fails or involves a critical mistake? Did you take from that experience something to avoid or correct in the future? Did you derive information from the mistake that you could not have discovered otherwise? There might be aspects of even "bad" experiences that can help you at least frame them as "constructive."
To conclude, if we are willing to set more reasonable expectations, we increase our chances of meeting them, thus increasing our repertoire of positive experiences. We can also learn to seek the value of mistakes. Over time, this can turn our jade into a precious experience, gradually raising our expectations and increasing our ability to meet them more consistently. So I challenge you to choose to frame your experiences as learning rather than as bitter disappointment.
Comments
#1 Submitted by qadiva0 on Thu, 06/05/2003 - 5:33pm.
Doris Lessing wrote; "There is only one real sin, and that is to persuade oneself that second best is anything but second best." We, QA, might be the last bastion holding out. While we must understand and support business decisions, we must not accept striving for less than we believe we are capable of.
#2 Submitted by Tom Greenbaum on Thu, 10/04/2001 - 8:16pm.
This is an excellent article. I forwarded the URL to everyone in my group of QA engineers and technicians. In particular, it was well-received by one senior engineer who applauded me for my courage in submitting this to the group. I believe that discussing this topic can be a good team-building experience. Within any QA group there will be people at many different levels of "Jaded". This disparity often causes a disconnect among the team. Those who are successful at re-framing can help those who are having difficulties. In addition, people who are new to QA need to develop a new frame altogether. I have recently worked closely with an engineer (new to QA) who was very stressed each time he discovered a bug. I had to explain how this was a positive thing - better for him to find a bug than the customer!
#3 Submitted by Gregory Cook on Wed, 10/03/2001 - 5:02pm.
Excellent article. But I would implore you all not to "givein to the dark side"! I have had SQA experience for 20 yearswith several companies. If you get lucky (as I did) you'llfind one that does not subscribe to "quick and cheap".
#4 Submitted by Frank Gorham-Engard on Wed, 10/03/2001 - 4:02pm.
This article is not about Software Development and Testing. It is about growing up.
#5 Submitted by Joe Perreault on Wed, 10/03/2001 - 2:09pm.
In the conclusion, Eileen says "if we are willing to set more reasonable expectations...". Reasonable expectations based on what and by whom? Management says they want 20 new features coded, tested, documented and released in 3 months. The Developers say they can only code and unit test 10 of these new features in 3 months. The testers say they can test 5 of the new features in 3 months and still do some regression testing. Each group of people has "reasonable expectations" as far as they are concerned - and yet each group has some "unreasonable expectations" at the same time. Trying to produce the best product you can within the project constraints is what leads to low quality software because one group, Management, usually sets those constraints without consulting anyone else. Until there is more collaboration between all the groups involved, projects will fail and people will feel hopeless.
#6 Submitted by Richard Foster on Wed, 10/03/2001 - 12:27pm.
Great article! Although I try not to, I have certainly fallen into the "jaded" category on more then one occasion. Having said that, I also have to agree with one of the earlier comments - certain co-workers see the way I look at things as being inappropriate. Does the author, or any of the other readers, have any suggestions how to communicate to others - especially management level - when the demands and expectations they have are either inappropriate, or unlikely to be met?
#7 Submitted by Antony Marcano on Tue, 10/02/2001 - 7:22pm.
Take a leaf out of John Daughety's metaphorical book - INDIFFERENCE IS THE KEY! This should not result from frustration, however... Indifference is key to retaining objectivity, the benefit of independent testing! That is the best way of fulfilling your responsibility - to deliver information about the risks and facilitate and support decisions that must be made by those RESPONSIBLE for the business (Directors), the programme (Programme Managers) and the project (Project Managers). Even if you are involved in Quaity Assurance and Engineering, you are still there as a check and balance to provide information to the decision makers as to what risks are being taken &/or managed by following a given process and methodology (or not be that the case). If you are given the responsibility of delivering quality by these parties, they are transferring their burdens and their risks onto you (without the glory I might add), dare I say inappropriately. If you seek the responsibility of delivering the REQUIRED levels of quality (i.e. good-enough to meet the objectives) and take it on by default, you should probably consider a career change to one of the above job-titles. Otherwise, recognise and optimise your effectiveness by being one of the most important decision support mechanisms in your organisation!------------------------Antony Marcano
#8 Submitted by Hal Brown on Tue, 10/02/2001 - 5:06pm.
Congratulations on an excellent article, Eileen. Mental health experts have been telling us for years that the overwhelming preponderance of the stress we feel emanates from between our ears. In other words it's not the events in our lives, but the meaning we assign to those events that cause us disappointment, disillusionment, anxiety, depression, and so forth. "Positive reframing" is the tool we use to overcome those maladies. However, I have lately been exposed to a dark side of this technique, which I think of as "positive reframing run amok". When a project goes over budget and behind schedule and is finally delivered with less than half the original feature set, management will often acclaim it a resounding success as an avenue of self promotion or in some cases, self-protection. The down side of this is that we are not allowed to document our mistakes and therefore not allowed to learn from them. This frequently means we will be condemned to repeat them.
#9 Submitted by Andrew Raybould on Tue, 10/02/2001 - 3:45pm.
Eileen, no matter how many times you say that you are not advocating lowering standards, it doesn't necessarily make it so. There is no law of logic or nature that guarantees that there will never be a situation in which the only realistic expectations are dismal, and disillusionment sets in when that seems to be the expected outcome. Failing to face up to a problem in the face of overwhelming evidence to the contrary is called denial.The real problem is that too many people think there is nothing wrong with the status quo and so lack any motivation to strive for anything better. The last thing we need is for anyone to tell them that they have the proper attitude.
#10 Submitted by amy reichert on Tue, 10/02/2001 - 3:11pm.
Excellent article and subject. I learned to adjust my expectations to be more realistic in order to preserve my sanity and reduce my stress level. However, I've noticed in working for others that they tend to look at you suspiciously - like you lack ambition or something. Sometimes I feel they see it as a "fault" especially on performance reviews. I still think saving my soul is much more important than banging my head against a brick wall for no apparent reason.
#11 Submitted by John Daughety on Tue, 10/02/2001 - 2:13pm.
This is such a good topic, since the mindset of the tester definitely takes the worst beating in most companies. The project I am testing now is in its 30th build, and three of those 30 builds passed our very basic smoke test. We are at the point now where we log a bug and the developers try to argue why it is actually a feature! As I await build 31, I can honestly say I am completely indifferent to the outcome of any testing I do! This feeling stems from frustration with the rest of the organization, which has not been involved with software development (this is not a problem on its own) and has no interest in listening to those who have had experience (this is the problem). While I distance myself emotionally from the quality of the software as a self-preservation measure, I am also saving my energy for more important efforts which do not have as much to do with actual testing. I know we are destined for a critical failure of some sort, and my best plan of action is threefold: 1) continue to do a good job of testing, continually improving our test process, and reporting the state of the software to the rest of the company; 2) compile data and prepare my story for the possible moment when software quality becomes a focus and I may be able to help fix the situation; 3) keep all this information and my insights gained as support for my next "gig." Wisdom from real-life war stories and adjustment of the basic testing theories so that they can apply to real life are both very strong plusses in the interview process.While this may sound pretty negative and hopeless, I really do not feel that way at all. I know some companies will not succeed in building good software: in some cases that will make the difference in a company's success and in other cases it will not matter at all. I also know that I will be frustrated at times during my career, and those periods will create the greatest opportunities for me to build my base of wisdom. Finally, I know that there are companies out there that will build good software, and the better I know how to spot them, the better chance I have of working for one!
#12 Submitted by Chris DeNardis on Tue, 10/02/2001 - 9:52am.
I am a positive person, always trying to find the good, or be the devil's advocate on many projects. However, I feel that while I can create reasonable expectations, I am over powered, by another factor - business decisions, and marketing suspicions. Thus the product goes out the door, and in some cases comes back and bites us. So maybe this article is a wake up call for senior management? I feel as though they are the conductors of this train, and steering us in the right (or maybe wrong) direction. However, when we notice problems, or suggest ideas, they cannot hear, because the steam engine is too loud.My question would be how does one stand up and be "louder" about creating reasonable expectations? Recently in STQE Magazine Johanna R wrote an article about a person who was hired to do process improvement. When the improvement ideas were identified, and sent off to senior management, senior management came down on the person for even suggesting such ideas.
#13 Submitted by Christopher Go on Mon, 10/01/2001 - 10:20pm.
As a QA person, you don't want to have low expectations of your product to start with. Instead, you want to keep your expectations realistic.
#14 Submitted by Doug Gohringer on Mon, 10/01/2001 - 5:37pm.
Is the moral of this story "keep your expectations low, and you won't be as disappointed"?! I must be beyond jaded.