Values Spotlight: A Labor of Enthusiasm

“When you arise in the morning, think of what a privilege it is to be alive, to think, to enjoy, to love …” — Marcus Aurelius

“Every morning when I wake up, I experience an exquisite joy —the joy of being Salvador Dalí— and I ask myself in rapture: What wonderful things is this Salvador Dalí going to accomplish today?” — Salvador Dalí

I want to paint my best understanding of enthusiasm by example.

Imagine breaking rocks all day and then throwing them in a hole. This would be a drudging task, because it is not interesting, and it serves no purpose. Imagine instead breaking rocks to something beautiful or useful: a sculpture, a deep well, a home, a place of worship. It is mentally stimulating, it is rewarding, it is engaging, and it delights both because others enjoy it and because it is utilitarian or beautiful for its own sake. When you are done, you can look upon your work with great satisfaction: your work was interesting and engaging, and it served a purpose. Both tasks may use the same hammer and chisel, and both may leave you sweaty and covered in dust. One is done begrudgingly and the other can be done with enthusiasm. The difference is not the form of the labor, but the engagement of the mind and the heart.

When you are breaking rocks, time moves slowly. You are counting the minutes until it is over. When you are sculpting, you forget the world. You forget to eat. You look up to find that the sun is rising, you’ve worked through the night, and your heart breaks because you must move on and do something else. 

Enthusiasm happens at a very precise point in space and time: here and now. When you are doing work for its sake, when you are interested in the work and challenged by it, your mind focuses on where you are, what you are doing. Your purpose is to correctly land each strike of the chisel. When it is done, the next strike is your next purpose. Something beautiful awaits, but you do not pursue it with grim determination or anxiety. You enjoy the work. And from doing this work enthusiastically, you imbue the work and the result with a greater quality than if you did it begrudgingly. 

The greatest misperception, stated explicitly or believed implicity, about work which I have heard is that to bring quality into your work requires you to give up something to your task or to the organization. People believe it costs you something to do quality work that it does not cost you to do mediocre work. But the wonderful secret is that the opposite of this is true: when you find enthusiasm in your work, you produce greater quality in whatever time you put into the task, and also extract greater joy and satisfaction. There is no trade-off involved in doing your work with enthusiasm. Indeed, the privilege of having that enthusiasm is part of what can make life wonderful. 

Finding Enthusiasm Within

Many people believe that they are either lucky enough to have a job which gives them enthusiasm, or they aren’t. They believe that whether they are enthusiastic or miserable at work is outside of their control, and so often they feel resentment, and they come to work begrudgingly in order to pay rent. But as our rock-breaking example illustrates, enthusiasm comes from the mind. Specifically, it comes from being able to tie the work you do to something meaningful: that is, if you know why what you do matters, you are much more able to be enthusiastic and enjoy your work. And you do not need to be a doctor or CEO to make your work meaningful. 

I used to work in milk bottling factories. They were loud and a bit smelly, and almost always were pretty far out in the middle of nowhere. As you might imagine, many of the people who worked in these facilities had worked there for a very long time. What they did was very repetitive: every day, they needed to fill hundreds of thousands of bottles of milk by operating and maintaining filling machines, casers, stackers, palletizers, forklifts, trucks. I had imagined that they were very unlucky to be working there, and that I was very lucky to instead be a consultant jetting about to help them. 

On one project, I met the operator of the bottle-making machine, called a blow-molder. He had been the senior blow-molder operator for 18 years. This guy was a wizard with a machine that was otherwise very finicky and difficult: typically, any time precision heat is involved in a process, you need skill to make it work. But the blow-molder mostly tended to itself, taking in plastic and cranking out bottles. To me, it looked boring. But we were working together because the plant wanted to reduce some of the downtime on the line, and I had gotten to know him over a few weeks.

One day I saw him standing at the blow-molder, arms crossed, smiling. He had just brought it back online after some of the bottles had come out malformed. I said to him: “You look like you’re looking at a painting you just made.”

He put his arms down and looked me in the eye. I could tell his own eyes were getting a bit moist as he told me this story: “Ten years ago, when I was in the grocery store with my wife and my granddaughter, my wife pointed at all the milk on the shelves. And she said to our granddaughter: ‘Honey, did you know your grandpa makes all of this milk that thousands of people drink every day?’ And I’ll never forget the amazement in my granddaughter’s eyes when she said: ‘Wow! That’s amazing!’ And hugged me. And ever since then, I’ve been very proud of what I do.”

I know for a fact that he is happier at work than many people making ten times as much, with much easier and more conventionally “successful” careers. He goes to work every day with enthusiasm for bringing milk to the kitchens of Indiana. 

In these same travels I also got to know some of the people who performed housekeeping at the hotels I would stay at. She was always so chipper and we would chat briefly when we would see each other. She had a similar story: whenever she cleaned a bathroom or made a bed, she knew that every day, dozens of people like me would drag themselves into the hotel after a long flight and a long day at work, exhausted. It was in her hotel rooms that they could let their shoulders relax, and they could leave the day behind them, comfortable and without worry in a soft bed and a warm shower. She knew she was bringing comfort and joy to weary travelers, and that she got a lot more exercise than most desk-jockeys. She loved her job. 

For my part, I loved working in milk plants, too, even though the hours and the travel were pretty exhausting. I was keeping factories afloat, I was fixing problems that got in peoples’ way. I found enthusiasm in being a teenage line cook because I was learning a lifelong skill to make delicious food. I found enthusiasm as a landscaper because I could listen to audiobooks all day and get exercise. When I worked in customer service, I found enthusiasm in brightening people’s days: and I was subsequently far better at accomplishing just that brightening than colleagues who focused on feeling put-upon by customers who complained at them. 

In this way, enthusiasm becomes a self-fulfilling prophecy. When you can articulate why what you are doing is meaningful–for you, for others, for the world–the increased quality you bring to the work improves the result, and yields the meaning you have tied to the work.

So when you show up to work, there’s no reason to not show up. If you’re going to be there, it costs you nothing additional to really be there, and you get so much more out of it.

Enthusiastically Learning and Growing

Enthusiasm, in combination with humility (which we discuss elsewhere), is a key to unlocking learning and growth. Let us consider again a few of the examples above. If you are a line cook, cooking with enthusiasm will provoke you to ask questions of more senior cooks about how to perfect a sandwich. If you are operating a blow-molder, enthusiasm will make you curious about how you can better understand the machine’s current state, and better control it. In an office (as in school), enthusiasm leads to curiosity and hunger to know more about what you are doing. Your mind will be more active and engaged, and you will be more open to seeing lessons that you would otherwise miss if you were shuffling your way through the day. If you work out enthusiastically, that last five minutes of trying to beat your personal record is exciting rather than miserable and tedious, so you will run all the harder with a smile on your face.

The logic of this is straightforward: enthusiasm comes when you see meaning in what you do. If you care about that meaning, whether it is a personal accomplishment, the realization of some external good, or the acquisition of a skill for later use, your mental engagement and thus rate of learning will be much higher. 

Enthusiasm’s Price

At ProdPerfect, enthusiasm is one of our core values, so we ask everyone to find it in themselves and bring it forth into their work and their teams. This request can feel at times a bit trite: who would not want to be enthusiastic about their work? 

While I believe the choice to be enthusiastic is a clear one, it does not mean that enthusiasm does not require giving up something. To be enthusiastic, one needs to give up emotional distance. There are people who are quite happy who see work as a means to an end: their enthusiasm is poured primarily into their families, volunteer work, and/or hobbies. These people have some emotional distance at work: because they are less attached to the meaning which we discussed above, they can more easily muster equanimity when things are not going well. 

If one is very enthusiastic about the outcome of one’s work, it can be devastating when one encounters a major setback. If you are enthusiastically training for a marathon and then shatter your foot, or if you enthusiastically build a tech company and then see a multibillion-dollar juggernaut release a new product line that matches your own, it can feel like your world is falling apart. Imagine the feeling of the sculptor who tips over a statue just a few buffs away from being completed. 

Even in less dramatic circumstances, is it hard to be enthusiastic without becoming attached to the subject of your enthusiasm, and thus to be emotionally ruffled when your work is not going well. Buddhist monks train for years to strike just this balance: if you are familiar with some monks’ intricate sand art, you see this in action. They spend days carefully creating something beautiful–practicing enthusiasm–and then upon completion immediately shake the table of sand, returning the art to the state of chaos from which it came–practicing acceptance and equanimity. For us laypeople, simultaneous enthusiasm and equanimity is difficult to reach. 

We each of us have only so much energy. While enthusiasm in work does not require extra time, and it likely gives us more total mental and emotional energy than we would have if we were simply dragging ourselves through the day, it also costs energy, and some days can cost quite a bit. 

Preventing QA Burnout Means Choosing the Right Values

“Transparency, Humility, Enthusiasm, Impact-Orientation, and Ownership. These are very admirable values, but they seem much more about how to live than how to run an organization. And they seem to have very little to do with your product. Why did you pick them?”

An investor recently asked me this question.

At ProdPerfect, we’ve chosen these company values because they fight burnout within our organization, within the QA teams we serve, and in the world around us.

Our Company Mission: Fighting Burnout

We designed our company values explicitly around our core mission of fighting burnout. We want to fight burnout for both our customers and our own team. When organizations neglect these values, eventual burnout becomes inevitable:

  • Without organizational transparency, teams lack understanding of the facts and reasoning behind big decisions, and may not fully trust leadership, creating an atmosphere that breeds anxiety and resentment, contributing to employee burnout.
  • Without humility, employees are likely to spend emotional energy bickering, fighting, and playing politics, leading also to burnout.
  • Without enthusiasm, work becomes a grind or drudgery, and employees spend time at work preferring to be elsewhere, contributing to burnout.
  • Without connecting the impact of their work to the mission of the organization or the welfare of others, individuals default to believing that their role does not have intrinsic value, contributing to burnout.
  • Without clear ownership of KPIs or problems, people easily become confused, problems persist, and frustration arises. When employees don’t feel that their area of ownership is respected, they feel helpless, and they may develop resentment. Each of these experiences contribute to burnout.

We continually strive internally to fight burnout by individually cultivating, and collectively teaching, reinforcing, and celebrating transparency, humility, enthusiasm, impact-orientation, and ownership. Holding to these values makes for a much more delightful, fulfilling, and productive workplace.

But, beyond our internal organization, how does ProdPerfect’s QA automation service fight burnout? How does it help other businesses adopt and reap the benefits of our values?

ProdPerfect QA Automation as Organizational Transformer

When ambitious, forward-thinking organizations partner with us, they are able to break through barriers to excellence that are a direct result of the core dysfunctions of legacy software quality assurance. ProdPerfect helps our clients reach further towards each of these values, decreasing burnout common to the conventional state of a software organization.

Transparency: In conventional QA testing, there is little clarity to the software organization as to which tests have been developed or why. Teams of similar sizes can have a few dozen end-to-end tests or thousands of them. What ultimately drives this? It’s unclear. This creates frustration for the developers whose code is being tested, and a lack of alignment between developers and QA engineers. Cross-silo fighting often results.

With ProdPerfect, data exclusively drives what the machine identifies as important to test. It’s clear that each test case reflects a pattern that users perform frequently, and teams can see exactly how frequently users interact with patterns that do and don’t have test cases in the ProdPerfect suite. Testing decisions become extremely transparent and there is less room for argument.

Humility: In conventional testing, intuition drives the decisions around what to test. The industry has for decades asked QA automation engineers to get in a room with some excel sheets and come up with what’s important to test. Sometimes the product team helps, sometimes developers help, and sometimes product analytics helps. But ultimately these decisions are made by people’s intuitions and they become attached to them. When bugs are missed, egos come out to play. “Why wasn’t this covered?” is the conversation every QA lead dreads, but must frequently face. When this question is asked, people get defensive, justifying their decisions. By its design, this system fails the people involved.

Because ProdPerfect’s test suite is objectively built off of data, there are no egos involved. The tests exist because users told us that these workflows are important to them. If a bug is caught, great. If a bug makes it into production, we can know that the facts told us it wasn’t worth the maintenance resources or test runtime (see: testing pyramid) to build a test for it. No room for ego.

Enthusiasm: Who loves maintaining end-to-end test suites? Who loves chasing down and diagnosing a flaky or unstable test? That’s right, nobody. ProdPerfect means machines take that burden away from humans, and so they can move on to work that deserves more enthusiastic attention.

Impact: Because of the intuitive nature of conventional test case development, it’s impossible to know if the test you’re writing has a large impact, a small impact, or zero impact. You might be writing tests that cover a pattern of behavior that nobody will ever use on your application, and you know that.

ProdPerfect’s data focus means every test is impactful. No longer are engineers spending time writing tests that have little or no value to the software organization. That waste has been removed.

Ownership: Who owns quality? Is it QA, or developers? Is it both? How often do these two departments fight back and forth over who is responsible for which area of quality, and how often do they fight over who has the power to make decisions about quality? When a bug is found in an end-of-sprint regression cycle, who is responsible for hunting it and fixing it? In many organizations, the relationship between software developers and QA engineers is quite toxic, and it’s because their ownership seems to overlap, with neither being clear what they have full ownership of and control over.

With ProdPerfect deployed, we can get part of the way towards clarifying that question. Developers should own their own unit and integration tests over the parts of the application they write. ProdPerfect will own testing the application as a whole: with each build, developers will get objective feedback about whether they broke the application. If they did, they own fixing their code, and have the power, tools, and context to do so. QA can continue supporting in many other realms: from other forms of testing to serving as analysts and advisers to developers to help them write quality code from square one.

Ultimately, software development and QA testers or engineers are set up for a frustrating relationship in the old model. Most experienced engineering leaders reading this will recognize elements of the above from their past, and most are likely familiar with toxic or dysfunctional developer/QA relations. By breaking that wheel of ineffective, unclear, intuition-based testing and mutual antipathy between these two groups, we enable a transformation towards a much healthier, more productive, and less burnt-out organization.

We exist as an organization because we wanted to bring something into the world that would help us and others further what we find most important. With our team, our investors, and our partners, we will strive to help all of us to avoid burnout, and thereby to thrive.

What Can and Should be Automated in Software Development?

Software development is a highly creative human endeavor that requires a concentrated mix of talents: efficient design, organization, architectural strategy, coordination with key business needs, and a deep attention to detail. It’s hard. Almost anyone can sling code if they take a few online classes. But few people can develop stable, extensible software.

Many of the human skills in software development are difficult to acquire and to quantify. Some come with experience, but still only when complemented by skill. There seems to be a natural talent that cannot be taught: many recruiters still look for the mythical “10x” developer who is ten times as productive or effective as others. From these sorts of mysteries and unquantifiable factors come a great deal of “philosophy” and legend about what goes into making great software.

It’s no surprise, therefore, that there is skepticism and even apprehension around the idea of automating any part of a developer’s job. Can machines really replicate any of what great developers do? And should we even try?

What should we automate?

What’s the difference between sculpting marble and breaking rocks?

The difference is in the engagement of the mind. The tools are the same. The medium is the same. How the mind engages with the task is what matters. While both use steel to change the shape of stone, one is drudgery and the other is creative and delightful. Breaking rocks all day burns people out. Sculpting sets the soul on fire.

David Liedle and I were discussing automation the other day and I realized that this is a great analogy for what we should automate. Robots can break rocks. We don’t need humans to break rocks. We do need humans to sculpt.

Are there parts of the software development process that are more like breaking rocks than sculpting? Of course. Would we ask a sculptor to chisel their own rock out of the earth and carry it to their workshop? No: it is a terrible use of their time and does not take advantage of their unique talents.

For software development, we should automate the parts of the process that do not engage the creativity, the strategy, the cleverness, and the organizational strength of a great developer. We should automate the drudging parts that burn people out.

What can we automate?

Perhaps not surprisingly, the tasks we should automate and the tasks we can automate have significant overlap by their very nature. The kinds of tasks that lack the special, human parts that are so hard to quantify are the very ones that are easiest to break into parts and automate in turn.

Right now, and for the foreseeable future, we automate tasks that can be defined and repeated, either deterministically or probabilistically (the latter being what we think of as “AI”). In human history, the tasks which have been automated have been those wherein the human mind is no longer creatively engaged. We have automated picking crops, forming boxes, stacking shelves. We are beginning to automate repetitive tasks on applications using Robotic Process Automation. QA engineers automate the task of manually clicking through an application repeatedly. All of these free up the human mind from drudgery so it can turn its focus towards more beautiful work.

We have seen it in other parts of the software development process: performance analysts used to repeatedly probe applications for performance issues; now Application Performance Management runs on its own when set up. Software deployments used to be heavily-managed events; now they can be done with a click of a button. All of these tasks are not what makes software engineering interesting or valuable to the human mind.

This holds true for the current wave of automation: the jobs being automated are those which have been so proceduralized by management process already that they no longer set the human soul alight. And there’s much more of the software development process that can yet be automated away from human burden.

At ProdPerfect, we seek to combat the drudgery of sitting in a room guessing what’s important to test, and repeatedly re-writing and re-tooling the same end-to-end automation tests. We’re here to fight burnout, to help software teams deal with less BS from broken code and from having to test it, so they can go build the things that help other people avoid burnout, and thrive.

As with every wave of automation, there’s some discomfort and incredulity that anything but an experienced, well-trained human can do the trick. In ten years, we won’t be able to imagine doing it any other way.

The Cost of a Bug in Prod

The Cost of a Bug in Prod

How much did your last bug cost you?

Everyone knows bugs in production cost revenue and are a nightmare for the engineering team. But browser automated testing is so costly and inconsistent that many teams abandon efforts to maintain a testing suite. At what cost?

How much QA and developer time was allocated to fixing the bug? How far was your next release pushed out? How much downtime did you experience, and how much revenue was lost while finding and fixing the bug?

IBM estimates that a bug making it to production increases your costs by 7x versus finding the bug in testing. Why hasn’t conventional browser automation testing solved the problem?

Conventional End to End Testing Isn't Worth It

No matter what tool you use to maintain end to end testing, you’re stuck with three fundamental problems:

  1. A talented engineer needs to write every test specification by hand
  2. Browser-level tests are brittle and flaky, and highly costly to maintain
  3. You simply don’t know your test coverage level

But what if it just worked? What if your users’ behavior was building and updating your testing suite—automatically?

Sound too good to be true? Learn how you can break the cycle — schedule a demo today.

Share on facebook
Share on google
Share on twitter
Share on linkedin

Why Browser-Automated Testing Consistently Fails

Why Browser-Automated Testing Consistently Fails

We’ve seen a lot of attempts at building browser-automated testing suites in our time. Most of them fail. The story typically goes something like this:

  • A growing team has been manually testing their application for some time
  • As they grow, they realize that manual testing is missing key user flows, and more importantly is significantly slowing down deployments
  • The team hire QA automation engineers or assigns developer engineers to build an automated test suite
  • The effort takes a few months
  • Over time, release schedules and firefighting get in the way of updating, maintaining, and expanding the testing suite — and the suite starts to degrade

At which point, one of two things happens:

  1. The test suite grows increasingly decrepit and obsolete until it is abandoned, or
  2. The number of tests and effort per build balloons and bloats until running the test takes hours and maintaining it delays your build cycle even more than previous manual testing
Why does this always come to pass? Much of the problem is the natural brittleness of browser-level tests–the effort in maintaining them is why Google suggests they take the least of your attention. But the main reason is that when building end to end tests, most teams are focusing on the wrong questions entirely.

A quick google search for “Improve QA testing” will bring you to a host of articles with titles like “___ Ways to Improve QA Testing.” I’m going to save you some time and provide you with the highlights here:

1. Incorporate testing early in the process

2. Outsource

3. Don’t forget to do it

4. Use this tool or that tool for test case management or execution

There’s a whole lot of advice on how to test your application, especially at the browser level. But bugs don’t get through because you don’t know how to test. Bugs get through because you don’t know what to test. Testing suite get bloated and broken because you don’t know what to test, and you end up building hundreds or thousands of tests in the hopes you’ll cover what you need. Tools can’t fix that for you, and outsourced firms can’t fix that for you, no matter how much money you throw at them.


Figure Out What to Test

This may seem obvious, but that’s precisely the problem: most teams think figuring out what to test is fairly self-evidence, or simply requires an engineer’s intuition: they’ll test what they think is important, flaky, bug-prone, etc.

But what should you test to make sure your application won’t break when your users use it? You should test what your users are actually trying to do.

In reality, your users tell you everything you need to know about what to test – you just need to start listening. No team succeeds with 10,000 end to end tests (and yes, we’ve seen 10,000), spitballing to try to catch everything. The teams that win–who can keep their automated testing suites maintained, relevant, and effective–are those who test for functionality along real user behavior.

Your product team is using analytics to understand what your users are doing, and improve workflows to improve the user experience. They’ve been doing it for years. Why isn’t engineering using the same analytics to build better tests?

The Path Forward

The first step to making this transition is to evaluate your current testing suite against your users’ common flows.

Which of your current automated end to end tests are covering actual user behavior, and which are irrelevant? Where are your gaps? ProdPerfect can help you quickly find the answers. We’ll tell you what your users are doing and what your tests are doing, so you can close the gaps and cut the chaff.

Share on facebook
Share on google
Share on twitter
Share on linkedin