Four Days Left to Totally Crush 2017

As I gaze beyond my laptop at work, Skeletor looks at me and says "Progress, not perfection".

There are only so many hours in the day and there are many things I care about.  I can't be perfect at all of them or any of them.

Our "free" time is a reflection of our values.  Our time at work can be too, depending on how much autonomy we are allowed.

Image credit: jcsullivan24

I'm the type of person who appreciates the heck out of a sunset, sunrise, moonset, moonrises, pretty cloud formations, bright red trees in the fall.  I'll just go and stare at the sky like an idiot, but that's who I am.  My dog Paddy is almost 17, and yeah, you bet she's getting a belly rub or ear rub if she asks for it no matter what else is going on.

Make time to read.  Make time to sleep.  Make time to just sit on the couch under a blanket with your kid.  Put down your phone and listen when your spouse is talking about something that's important to them.  Make time to learn.  Make time to write.  Make time to check in with friends.  Make time to keep your heart and lungs healthy.  Make time to take care of your surroundings if the clutter is a distraction.   Buy time if you can - pay a neighbor kid to mow your lawn...order your groceries online instead of meandering through aisles (unless grocery shopping to you is like a breathtaking moonrise for me -- whatever works).  Dispose of traditions that don't matter to you.  Reframe that stressful wait in traffic into an opportunity to listen to a podcast or audiobook.

To whatever extent we can control our time, we can approach it with the goal of making progress toward being a better whatever-role-is-important-to-us-right-now.

Takeaways from Presenting at my First Career Fair

I responded to a generic Facebook call for people who were interested in sharing their careers with Booker T. Washington High School students.  Let me know if you need anybody to cover areas related to software, statistics, and/or management, I said.  

So that's how I came to be one of three computer science panelists for a few dozen students who selected that career area. 

There were a few prepared questions that I had thought about over the course of the week leading up to the career fair.  I reflected on my career so far, which started out less as a plan and more as a series of things that just kind of happened.  I like these Economics courses, I'll keep taking them.  There's a job opportunity in Tulsa working for people I already know and like, sure.  

Image Credit: Yixler

If I didn't like where things were going I'd make adjustments to change course.  I didn't want to appraise or analyze the commercial real estate market forever, so I took some night classes in programming.  I didn't want to answer tech support questions forever, so I made my preference for being a full time QA person known to the right people in the company.  

So I spoke less of "follow your dreams" and more of  "stay open to your dream changing".  Always keep learning and adjusting based on how the world changes and how you feel about it. 

I brought what I think was a different perspective.  My two fellow panelists were, what I would call, "traditional" computer science people.  Males who had been tinkering with electronics since they could remember and who spend all of their waking hours either programming at work or programming for fun.   Nothing negative meant by this; they seem happy, and there appeared to be a cohort of young men in the classroom already playing out this role and eager to take the next steps of pursuing computer-related careers professionally.  

But I wore a bright pink shirt.  I said I entered college knowing I was vaguely interested in numbers and setting up web pages and how the world worked in general. I leave work at 5:15pm so I can make pickup at my daughter's aftercare, and I engage with my family or other parts of the world or yes, maybe keep working on computer-related problems if I feel like it that day.  I took a public policy angle on technology, saying that the field needs people who care *where* technology is going- summarizing the takeaways of a book I recently read, Life 3.0: Being Human in the Age of Artificial Intelligence by Max Tegmark.  People who think about ethics and how we can make sure that technology is working for us and with us humans instead of against us.  I talked with expressiveness and passion for all types of knowledge.  

Retroactively, one could assume my goal was to reach analytical, passionate people who had missed the "tinkering since toddlerhood" window or to whom programming 24/7 forever doesn't appeal and encouraging them to seek out a spot at the table anyway.  Reassuring them that I'll be there in the crowded cafeteria with my bright pink shirt, waving them over to the geeks' table, pointing out the free chair. 

Show up and Engage

Photo Credit: Jacob Earl: https://flic.kr/p/Tuasqx

The podcast DecodeDC had an episode about the success of the National Rifle Association.  Essentially, it comes down to their membership showing up and being engaged. Regardless of what you think of how they use their power, it was a good reminder of the value of loud, consistent voices no matter the number.  

They pay attention and are willing to raise a fuss.  It works. 

It's easy, and in fact tempting, to be apathetic.  "The legislature is never going to change...My vote doesn't matter...They've already chosen the actress for the lead role...Those people are so much smarter than I am, why even show up?"

We have to anyway.  Once we give up on the idea that improvement in our lives, workplaces, communities, and society is impossible, then the light that makes life worth living dims and fades to black.  

So continue to talk about what is important to you.  Research ways to work around or erode obstacles. Gather with others to discuss what the ideal future looks like.  Learn about people and history and economics and technology.  Learn how to be an effective communicator and advocate.   Show up, full of energy, ready to make the next step forward, even if it's small.  Or even to stand, strong and resolute with pride, to prevent further losses.  Because if you don't continually show up and remind everyone of what's important, then over time, people may start to forget that it *is* important. 

More on the Future of Testing

"As service providers we are adapting to the reality of our teams, and this means a number of different things. For example:
– I see that testers are doing a lot more automation and in different levels within their projects. We are writing all sort of scripts to help the development process, working with multiple automation technologies, and using automation to help us do our tasks faster.
– I also see many more testers going deeper into the technical work of their teams. This is further than automation, going into the logs of the product and sometimes even reviewing the actual code while looking for issues.
– In some cases, and in some organizations, I am seeing how testers are doing more work with production environments, doing A/B testing in live features and becoming data scientist and DevOps alchemists within their teams." - Joel Montvelisky

In addition to "ninja" and "scrappy"..."alchemist" is a good descriptor to aim for professionally.

Future-Proofing Your Career

As an experienced software tester and a naturally anxious person, I frequently don't feel safe unless I've thought through all of the potential disasters that can occur and mitigate risks of those occurring to the extent possible.

One such disaster would be job loss.  The mitigation for this is to prepare for the job I'd want to get if I had to get a new one.  This is a tough question for me, since I love literally about 95% of my current job. 

But thinking ahead, what are my skills, what do I *like* to do, what does the world need more of from an ethical/moral perspective, where is there going to be a good availability of jobs but not an overabundance of people training for them already?   

Unfortunately, I don't see a lot of growth in the role of software testing as a full time career path, although testing as an activity/mindset will still be needed.  In the six-year-old linked video, James Whittaker points out many demoralizing but logical reasons that we should not be too comfortable with our current skills and approaches.  We need to stay hungry....change or die. 

So what's next? I see a lot of "Should testers learn to code?" discussions out there -- I absolutely don't see why that's a question.  When there's a choice between learning a thing and not learning a thing...always learn the thing!  

I like programming and LOVE the addictive thrill of solving a problem with code.  Though counting on it as a career move, I am not sure how to jump my perception of a chasm between learning the basics and becoming a competent, ready-to-employ developer.  It seems like everyone currently employed as a developer has knowledge of optimization, the ins and outs of multithreading, all the tools, and thorough knowledge of the past and future of computers. It may also be my perception that others are more competent than they actually are...Or I'm actually more competent than I perceive myself.

Additionally, I love isolating problems and breaking them down to core components, experimental design, thinking about thinking, juggling multiple priorities, seeing multiple steps ahead. 

I have PLENTY to learn as a manager. My biggest strength as a manager is awareness of how much I have to learn, such as delegating and teaching and knowing whether to "help" or back off.

Luckily, identifying and enhancing the skills that would help me get a NEW job if I needed one may also assist in keeping me employed in a role that is evolving into something new, and dare I say, exciting. 

Burnout: Turning down the flames

The best advice I've read about working extra hours is to "Be a volunteer, not a victim" from Lessons Learned in Software Testing.

I thought I was doing that. But apparently working is a lot like eating; you can only prevent a bad outcome if you stop BEFORE you think you should.

I have experience with burnout; ten years ago, oh man...that was quite a project.  So many long days and weekends, all for an impossible goal.  The lesson learned from it was that no one is going to stop by and pat me on the head and tell me to go home.  I have to take charge of my schedule and life.

Therefore even though it was a project of similar importance, I had actually been treating myself pretty kindly, only working when I had nothing better to do.  I didn't miss any school events for my kid, and I was generally there for my family when it mattered.

But in reality, I was working instead of exercising.  Working instead of *finding* something better to do.

Then when earlier this week, one...two...then three things don't go to plan...I lacked the reserve of patience & understanding to respond proportionately.

So, even more lessons learned.  During crunch times, go home or log off after 9 or 10 hours even when I'm enjoying my work.  Hit the treadmill even when I'm lost in thought.  Don't commit to work I can't do in 40 hours, even though if it doesn't feel like I'll mind.  Extra hours can generally be for catching up on surprise work only instead of surprise work *plus* what may be described as "I'm going to be a hero and try to do everything!" work. 

I can continue getting plenty of things done while ensuring that I have enough bandwidth to be flexible to changes in plans.

Move to Management

I had an unexpected shift in career trajectory resulting from my former manager's retirement at the end of February 2017.

I hadn't really seen myself in management...I'd always preferred the alternative of focusing on my own work as an individual contributor, getting closer to the guts of our program under test, Statistica.  But when presented with the opportunity, it seemed like the right course of action.

A few random realizations from 2.5 weeks:

• None of us is an individual contributor.  We get where we are based on learning from others early in our career and first few years of tenure at a particular job.  And once we're the senior people on the team, we have a responsibility to be the teachers and guides.  The circle of professional life.  
• Caring about your team gets you pretty far.  I've already had a few moments where I didn't know what to do, and I half-expected someone responsible to show up and take the decision out of my hands.  But alas, I was the person responsible.   I had a similar feeling about becoming a parent.  You try to prepare yourself, you learn what you can, you care intensely, you do your best, you admit your mistakes and learn from them. 
• I can't do everything I feel like I could write a Dr. Seuss-like book "Oh the balls you will drop!" I'm such a people-pleaser and I've been described as "helpful to a fault".  I have to get over this! Sometimes things are going to sit as low-priority tasks for a while, and I will have to deal with the feeling that I'm letting someone down.  Sometimes I'm going to hurt feelings or not be strong enough in my email replies since I didn't read over it an obsessive number of times, scanning for alternative interpretations or hedging words.  

Obviously I have a lot to learn, but my team is amazing and I'm getting a lot of support from other managers, so I think everything will be okay :-) 

Gorilla Suit Testing

When I hear talk of testing in terms of requirements, I think of the Gorilla Experiment, which is cited in pretty much every book I've read in the past ten years.


Counting the passes is testing the requirements. Which are indeed important. According to the video's instructions, you had one job, so yeah, you'd better get that right.

But our customers aren't getting a copy of the requirements.  All they see is the video without the instructions, as an analogy.  And when you're not focused on the requirements, gorilla-level issues are pretty obvious.

So, you have to test your product with multiple goals and using various levels of magnification.  Once you've counted the basketballs, watch the video again and take in the big picture with no particular goals, just letting the gorillas make themselves seen.  Watch it again and see if there's anything weird going on with the team wearing black.  Watch it again, why are they in a garage in front of elevators?  Why are there S's on the wall?  Does the basketball ever change into a beach ball?

Once you've tested your requirements, congratulations, but your job is not yet finished.

Remembering Our "Why": Lessons from the Challenger explosion

Photo Credit: NASA Goddard Space Flight Center

I always remember the anniversary of the Challenger explosion.

It has stuck with me as a sad day, not just because of the deaths of those on board and the reminder of the darker side of being an adventurous species.  But because there was evidence that they shouldn't be launching at all in weather that cold.

This evidence was presented prior to launch by an engineer, Roger Boisjoly, who worked for a NASA contractor Thiokol.  NPR released an article almost five years ago, shortly after Roger Boisjoly's death.  He and other engineers forcefully argued on January 27, 1986 to delay the launch, but NASA was "appalled" by the recommendation and the Thiokol management overruled the engineers apparently under the pressure from NASA. The launch proceeded as scheduled the next morning.

"Then, a few seconds later, the shuttle blew up. And we all knew exactly what happened."

 A few takeaways from this awful series of events that have impacted my career:

• Find a place to work where management behaves with integrity
• Find a place to work where management trusts the expertise of its engineers and will defer to their reasonable recommendations and predictions concerning this expertise
• We need to be attuned to pieces/features that are subject to failure and creatively think about the conditions under which they are likely to fail, especially when they're similar to conditions that the end user will be experiencing
• Communicate with my management and other internal stakeholders clearly about risks I see and speak with as much emphasis as I feel the risk is worth.  I do my best to let things go that ultimately don't matter so that I'm more likely to get their attention when it does.  
• I have never needed them and I don't foresee needing them in my current position, but I have a few extra levels of freakout in reserve for "this could kill people" or "this will likely kill people", where I imagine myself trying to change the minds of those in charge of a NASA launch/no launch type of decision at various temperatures. 

I hope that customers, management, and engineers keep the lessons that can be learned from the Challenger explosion in mind as our work becomes more prevalent in life vs. death situations like driving and medical diagnoses.

A "Post-Agile" Post: "If it works, do it. If it doesn't, don't".

I like simple rules of thumb. I found an article this morning with a very simple approach to the software development life cycle: "If it works, do it.  If it doesn't, don't".

Of course, it's not exactly that simple.  What does "works" mean?

I would define "works" as delivering products that people want to pay money for at a high enough quality to meet the business value of the customer and the ethical standards we should value as technical professionals.

Underlying that is customers are paying enough money in relation to what the software company is paying its workers.  So on the revenue side, we need

• Good market research people.  
• Good sales and good marketing people.  
• Good customer service folks. 

All are making sure that we understand the problems customers are facing and that the customers are and feel valued and heard.
Also underlying the simple approach is we are efficient at delivering the software on the cost side. 

• Development/QA and product management work super closely together so that there is no question what the customer wants and why. 
• We only deliver what the customer needs or have strong evidence that they want.  
• Developers are all focused on current customer needs, paying down any technical debt that's accrued in the past that threatens the current value of the product, or researching future technological trends -- what customers don't need now but will in 1-5 years.  
• QA is empowered to ask questions from the beginning and in a position to find issues quickly after they're introduced.  This prevents Development/QA from having to spend time identifying, fixing, patching, and retesting issues after the initial release.  
• Nothing is done without the customer in mind.  No documentation that doesn't directly serve a customer or promote good understanding of the product within the company.

We still need continual, honest assessment of what we're doing that's "working" and what is "not working".  But by taking the simple approach we focus less on blindly following and enforcing specifics of a process (even an Agile process) and more on the understanding and internalizing of what "works", particularly how each of our roles and interactions contribute to the value of the product.