Wednesday, January 2, 2019

Routine: Living resiliently

I love routine.  I have a system that keeps me sane. Much of my work and home life is structured by Yanado tasks linked with my work and personal Google accounts.  Things I need to do all go there. Things I want to do go there too.

My personal list of tasks helps me keep in touch with my friends, keep my dogs correctly medicated, keeps me learning, keeps me volunteering, keeps me exercising.  My work list of tasks does the same thing - it reminds me of the commitments I've made to others on the team, keeps long term goals in my view, and helps me respond to emails in an order reflecting their importance.

And then things happen to throw off the routine.  We get sick...we get a new puppy who requires newborn baby levels of attention...we get in a car accident and have to take it easy and find time to buy a new car, we get an emergency high-priority issue at work.

While my routine was thrown off over Christmas, I had extra time to read. I read Team of Teams: New Rules of Engagement for a Complex World by General Stanley McChrystal .  It had some useful leadership lessons and also introduced me to a distinction I hadn't been consciously aware of - robustness vs. resilience.  Robustness is strength to withstand obstacles...Resilience is the ability to adapt as obstacles arise and evolve.

This year, I've seen a change in vocabulary around New Year's Eve -- Intentions rather than Resolutions.  The thought being that once you've broken a resolution (e.g. I resolve to floss every night) then it's done; there's no point in continuing.  You can always return to an intention (I intend to floss more this year).  Perhaps a more resilient approach to behavior change.

Watching my mom, who is now retired, go about her new life is inspiring.  She's playing piano and spending a lot of time with genealogy. It led to the table topic style question when I visited this weekend - "what would I do with unlimited time/money"

Photo credit: Taylor Maley
Piano.  Singing.  Auditing university classes. Dancing.  Scanning all the photos I have only hard copies of.  Ping pong.  Bowling. Writing. Reading.  Cross-stitching.  Run for office and use it as a public forum for ranting Network-style if it becomes clear I won't win, steer philosophical discussions on the role of AI in our daily lives.

I'm not going to be able to do all this at once. And that doesn't make me a failure.  I can use tools to keep my family/spiritual/social/professional/physical goals in front of me.  Eliminate junk.  Use Facebook just enough to keep up with the big news of my real-life friends.  Don't overthink; pick something that's fine and stick with it.  Don't get sucked into drama.  Re-route myself to a goal/intention that I've found to be important. 

At the moment, these goals/intentions are growth (learning skills or facts/concepts that grow new neural pathways), connection with fellow humans (and dogs, I suppose), and reduction of blood pressure. 

Happy 2019!

Saturday, July 21, 2018

Tulsa Techfest 2018 - DevOps and Drive Thrus

On July 20, Tulsa TechFest was held at OSU-Tulsa.

There were 16 different tracks of and four different session plus a keynote plus lunch.  Not bad for a free conference in town.

The themes of the day seemed to be C#, Agile, Feature Flags, and AI.
Image Credit: Marc Carlson

The keynote was given by Donovan Brown, DevOps guru at Microsoft.  It was inspiring, despite the fact that he was super excited about their move to fire / transfer to other areas within Microsoft their manual QA team for their VSTS project.  However he did clarify that it was a special case, that the team itself was both a subject matter expert on the product and acting as end users before doing a controlled rollout to concentric circles of customers, who are presumably more and more risk averse as you move outward.

He spoke about automating all of the things, focusing on the most offensive bottlenecks first, letting developers bear the burden of whatever bad code they write, both by being responsible for automating their own tests and taking the 3am phone calls when something blows up in production.

It resembled heavily the recent discussions on Modern Testing, specifically the reduction of using QA as a safety net to enable less-than-careful behavior from developers and identification/removal of bottlenecks. 

My top takeaways now that I've had a day to process.

1) Ed Eckenstein had the same experience I had with someone cutting them off at the McDonald's double drive through.  Though, as he's done a lot of work with coaching on mindfulness, connection, and gratitude since his survival of the Oklahoma City bombing, he had a better spin on his drive-through experience.  "What is the kindest interpretation of this behavior?" -- which is an interesting thought exercise.  I bet his McDonald's opponent didn't get out of their car and start cursing at him with two children in my grudge-holding doesn't seem quite so petty.  Though his point was indeed well taken for all non-fast food related matters.

2) Even if developers write the highest-quality code to the best of their ability, QA provides value acting as subject matter experts.  Donovan Brown said if his team were writing software for truckers, they would for sure still have some manual QA around.

3) I don't like the term "manual QA", which seems to me to be the label for anyone whose eyes see the software without the sole purpose of creating a script --   What's a better term that doesn't make us sound like early primates happily clicking their keyboards randomly...Subject Matter Engineers?  Air Traffic Control? Pre-Crime Investigators?

4) Continuous improvement is a team effort.  We have to support one another, both to promote a connected, low-stress working environment and to encourage experimentation. Getting better doesn't always work out on the first try.

Monday, July 2, 2018

30 Days of Automation in Testing - #1 & #2

Organized by the Ministry of Testing.

1 Look up some definitions for ʻAutomationʼ, compare them against definitions for ʻTest Automationʼ.

I googled a bit and found a nice rant that is probably not completely relevant here since it has to do with the testing vs. checking distinction.  I found the regression testing as a form of version control point interesting.  Regression testing is table stakes - it needs to be done, it's boring and time consuming.  Automate it.

Call it a check if the person you're talking with cares about the distinction. Call it a check if the acceptance criteria of creating an automated regression check is a clear programming task and it doesn't need a tester mindset to ensure that it was created correctly.  Once it's coded and checks what it's supposed to check, then and only then shall we call it a check.  But ensuring that the check checks what it's supposed to check, either with clear acceptance criteria or by double checking the check....that's a testing activity.

My thoughts on automation in general are to use whatever makes your job easier or less boring.  Don't turn off your brain just yet though.  You have to know what your automation is DOING.

The tool may be making pretty graphs and tables of load test results, but don't trust the numbers unless you know that it's really timing what you intend it to be timing.

Know whether your checks are passing because your software is still awesome or because the logic of your test code is always "everything's fine!"

2 Begin reading an automation related book and share something youʼve learnt by day 30.

I have a work project going on related to JMeter, so why not Performance Testing with JMeter 3 - Third Edition?  I'm an ACM member with benefits to use the OReilly/Safari/Packt collection of books, so I won't lose any money at least :-)

Saturday, April 7, 2018

Stop Your Bottlenecking!

Management is probably the biggest challenge I've ever experienced.  I feel like I'm responsible for so many things but in direct control of almost nothing.  I have so many ideas that I sometimes wake up in an energetic frenzy in the middle of the night, but sadly not a lot of time to move them forward.  There are times when I feel like my team's work is stuck, and I'm the reason why. 

Some ideas to address this:
Image Credit: Ralf Steinberger, Flickr Creative Commons Attribution License

Being honest with myself about how much work I can do.  We use JIRA to plan our development-related work as an engineering team.  I can do about ten points of non-management work in a two-week sprint. But I want to do more than ten points worth of stuff.  So I think I have been underestimating point values in an effort to enable myself to take ownership of more tasks than I should - e.g. referring to what should truly be a 3 point task as a 1 point task. Saying I can do 10 points of stuff that's really more like 20 or 25 has contributed to taking too much on and unfairly inhibiting people who are dependent on these tasks getting done. 

Being honest with my team about how much work I can do:  I confessed on a project slack channel that I was a bottleneck.  I said if we wanted the project to move faster than I was moving it that I would need to have help with some specific tasks. And now we have a hack-hour scheduled next week where we'll attack the problem together. 

Being less responsive Several times a week, someone posts to our slack channel a quirky problem with the software or with our internal infrastructure that I want to help them figure out.  I love troubleshooting and problem-solving.  But it can also be a distraction from larger goals that I need to be spending my time on instead.  If it's an important thing that really needs to be figured out, making a note to revisit the question in an hour or so is probably a good approach.  Chances are that in that hour, someone else has probably jumped in to help without my having to spend time on it.  I've given someone else the opportunity to experience the thrill of helping to solve a problem, and spent that time on a less urgent but equally important team goal.

Is it really that bad?  I have notoriously high expectations of myself and if there's any way I can judge myself as not being good enough, that will be my takeaway.  I am probably doing at least an average job, even when I think I suck.  A concrete list of things that do get done can help me see this more objectively.

Sunday, March 4, 2018

Defining Expectations

Asking for what I want has never been easy.  More accurately, defining and articulating what I want TO MYSELF has never been easy.  Which, as a manager, is problematic.

As I reflect, I see this as a two-pronged problem to examine. 

  • Combining my knowledge and skills and creativity with my team's knowledge, skills, and creativity to come up with a vision and priorities, and breaking these down to general goals for experienced team members, and helping break the goals down even further for newer team members (Defining what to do
  • General behaviors/attitudes that I see as useful in many situations (Defining how to be
What To Do 

It seems the ideal I need to work toward is to know when to give someone a lump of clay and the time to make a statue...or when to give someone a more paint-by-numbers task.  I don't want to rob someone capable of grand things of the opportunity to be creative, nor do I want to overwhelm a new team member who is still developing their skills and intuition.  This will vary person to person and task to task. 

How to Be

This blog post was inspired by thinking about this observation -- that what I expect and value in my team members is largely the same as what I value in my friendships.  And these expectations are largely invisible to me, and even more so to those I interact with.  Some of them are merely personal preferences rather than universal goods, which, sadly puts me on a better footing as a default with those who are most similar to me in background. 

As a first step I want to inventory the personal traits and behaviors that I value. The next step will be recognizing where there are different but equally valuable ways of behaving  & approaching work and being able to evaluate what I'm seeing in this light 
  • Initiative - I value when people are able to see or anticipate and problem and take the next logical steps to solving it, as their experience allows.  They feel ownership of the product or the situation and take action without having to be asked. 
  • Independence - I value when people try to do things on their own first (via experimentation or Googling) but, wait, wait, wait...DON'T go overboard.  Ask for help if your own research is coming up short or it is a time critical task.  
  • Curiosity and drive -- I value the compulsive need to dig deeper to find the root cause of an issue or to explore an area of the software that seems "off" to them that day....but, wait, wait, wait, DON'T go overboard focusing on details that don't matter. 
  • Flexibility - I value when people are able to change course and refocus their attention when circumstances require it
I am sure there are more, but this is a good starting point.  I can already see evidence of some rigidity in my thinking (even though I supposedly value Flexibility) that I can start working on being more mindful of increasing my range of comfort in others' behavior. 

Thursday, December 28, 2017

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.

Saturday, November 25, 2017

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.