Ten Year Plaque!

Like most major milestones of my life, it's a time of reflection.

I was hired by StatSoft in April, 2006. I was so nervous for the interview and so thrilled to get the call late on a Friday afternoon that I had been offered a position.  Statistics + software + getting paid = My dream job.  It has been challenging, fun, and almost never boring.

Dell acquired StatSoft in 2014, and happily they credited us with our years of service from StatSoft for purposes of vacation time and apparently nifty plaques.

In the words of President Bartlet, "What's next?" Well, I'm glad you asked.

• Stay up to date with current trends and conversations in the software industry
• Advocate within the organization and to anyone else who will listen about software quality and strategies for achieving and maintaining quality. 
• Become proficient in Python 
• Read, read, read.  Become knowledgeable enough to have opinions and to back them up with data or examples. 
• Be proactive.  Speak up to make sure stakeholders know the relevant bits of information and my overall assessment of the status of product.  When important conversations about the product are being held, making sure I'm in the room so that I have all the information I need to make good decisions about where to focus my time. 
• Attend a software testing conference.  It will never be convenient to miss work or to be out of town, but short-term sacrifices are sometimes needed for long-term growth. 

Tulsa Agile Practitioners Meetup

Last week, I made it a priority to attend a meetup group that I had been wanting to visit for a while: 
Tulsa Agile Practitioners (TAP)

It was conducted in an Open Space format - with several topics on the wall with a person willing to lead a discussion.  Pick a topic, find a chair, sit down, listen, and talk.

The conversation could have lasted hours or days, however long the donated Chick-Fil-A supply sustained us. 

My group didn't talk directly about Agile.  We talked about software quality, approaches to advocate for the craft of constructing software, approaches to adding value that can't be automated or easily outsourced...It was nice to find a group of folks in town where Uncle Bob is mentioned casually like he's an actual relative, you overhear things like "Clean Code changed my life", and people crack wise about using Agile principles to put the meeting room tables and chairs back together to their original state. 

A+, will attend again.

UX checklist for desktop applications - Microsoft MSDN

Found this to be a fun, if perhaps overly nit-picky read.  I will cite it in the future if I need to justify a preference I have about a dialog or other UX element. 

UX checklist for desktop applications

I won!

I'm a frequent attendee of RBCS webinars.  There was a presentation on Monday titled "Why Does Software Quality Still Suck" which I listened in on (video here).  Rex Black fired another shot in the testing standards war, which I'm looking forward to hearing some context-driven responses on.
For each of Rex's webinars, an attendee is chosen by drawing to receive a free e-learning course. I won!! That's two exclamation points, indeed. So for the next three months, I'm going to immerse myself in the ISTQB Certified Tester Advanced Technical Test Analyst E-Learning training course.  

Testing and Testing-Related Books

Ten Must Read Books You Didn't Know Were About Software Testing

I've read several of the testing books but none of the other list of recommended books.  I've seen Thinking Fast & Slow recommended on almost every similar list so I really need to make that my next read.

I'm a huge fan of Pragmatic Thinking & Learning and Mindset so I always mention them when the discussion turns to recommended reading. I've applied both in the context of my job.

New habits

Once you've achieved competence and a reasonable tenure at your job, it's easy to rest.  You have valuable institutional knowledge that newer workers don't have, so it's easy to feel "smart enough".  Furthermore, feeling "smart" is awesome. 

But what's next?

Stagnation, unless you intentionally plan otherwise. 

I've been tinkering with scripting for years.  It's a great rush when something works correctly.  But when it doesn't...and when Google searches turn up nothing, it's easy to be content with what you have.  That was probably too ambitious for me to try that in the script.  Manual testing is just fine for this.  I don't want to waste someone's time by asking them -- they have better things to do, and what if they think I'm stupid?

1) Ask the stupid question. 

I'd suggest email, so you don't interrupt someone "in the flow" -- and a preface of "this is not a high priority, but I'm curious if you know how to do X, or if you've ever encountered problems with X and could share any tricks"  Add what you've already tried, so that it's not something they sigh about under their breath and wonder why you didn't just google it. 

They might think you're stupid, sure.  But probably, that is in your own head.  And they'll be flattered that you ask them.  And they might learn something from you that will make them better teachers in the future.  

And, most importantly from my perspective, you could learn something from them that makes you more valuable.  They could show you a technique that opens up all kinds of possibilities for problem-solving in the future. You solve more problems and faster, and now are a vector for spreading this knowledge if someone else has the same problem in the future. 

2) Ask for feedback. 

Show people your code/your work.  People who know more than you do.  If you're a fixed-mindset (by default), people-pleasing person like I am, this will make you want to throw up.  But, it will make you better.  It's like having a personal trainer available to tell you "You know, you are doing that exercise all wrong.  People are probably laughing at you behind your back, and worst-case, you could snap your spinal cord".  Except with code.  It can break you of bad habits and learn to do better work more efficiently. Even if what you're doing *feels* like exercise and the end result seems the same, it could be working by coincidence or doing something unintentional and awful very quietly.  

Professional Miracles

Today marks the 7th Anniversary of the "Miracle on the Hudson".

This story inspires me every time I think of it.  I want to totally rock my job like Sullenberger rocked his job that day.

There are three takeaways from that day for me.

1) Learn different strategies for problem-solving.  Know when to use them and how to pick the best one.

2) Practice.  Get really good at applying what you've learned so that it becomes automatic when it needs to be.

3) Seek out opportunities to be useful.  If Sullenberger hadn't shown up for work that day, maybe Flight 1549 would have had a different fate.