Thursday, September 4, 2025

Email: How to Handle Unplanned Absences & Missing Deadlines

 

Motivation

Life happens, no one is perfect.  Someone on my team got Covid and had to miss work.  She prepared the best she could, looped in another teammate for help, and wrote a great message letting us know the state of things and what to expect.  Clearly, she did the heavy lifting for this blog post (she knows who she is).

The Email

@Everyone Sometimes we get sick or must take an unplanned absence.  Sometimes we realize that we will not be finished in time to meet a deadline... no one is perfect.  The important thing in both cases is clear and thorough communication.  The sooner we know that we will be unavailable or we will miss a deadline, the sooner we can plan for it.

K has modeled this for us exceptionally with her communication Monday.  Thank you K, get well soon!

----------------

Unfortunately, I have covid. I took documented sick leave today. Don’t worry about the release - I’ve prepared everything.

  • Smoke (link) : 3 failed tests due to known +/- button issue on the server. These tests pass successfully on my local machine.
  • RegressionA (link): 5 failed tests — 1 known issue, 4 possible bugs. I’ll ask B about them.
  • RegressionB (link): 16 failed tests — 2 known issues. Some tests pass successfully locally. For return/exchange tests, I’ll write to N to create shipped orders.

I’ll be here tomorrow morning to analyze the results. Depending on how I feel, I might take leave again starting Wednesday. But I’ll definitely be here tomorrow, so don’t worry

I also wrote to S to ask the infrastructure team to check the simulators to ensure there are no unexpected issues, so you can run the tests today

I also wrote to Y, and if I need his help, I’ll be sure to let him know

My PR: https://github.com/___/shop-auto-qa/pull/952

Wednesday, September 11, 2024

Automation Strategy (Email): Assertion Messages Should Be UNMISTAKABLY Clear

Hey Team,

I put A’s 2.35 execution report in the wiki and it looks great, but I want to say something about being unmistakably clear when talking about correct vs incorrect system behavior.

Unmistakable clarity is being so clear that there is no way anyone could misunderstand the message.  It is being so clear that if someone was intentionally trying to misrepresent or twist your words into another meaning, they would be unable to do so.

For issue #8, A says:

Heart(add to saved items) icon for the eGiftCard. [7th screen]

But to someone who is not familiar with this particular feature, it is not clear what this means.  I have seen this for many years in test automation, specifically in the test pass/fail message at the end of the test.  Some examples at Under Armour are:

  • “Points earned amount is present!”
  • “Some items are checked from WHO DO YOU FOLLOW items”
  • “Product is found!”
  • “Search results are empty” 

The messages in our automation are actually pretty good, but it’s better to be like a real bug report and give expected results and actual results.  I am NOT saying we should refactor our code, but going forward, I would prefer to see error messages like:

  • “Points earned amount should not be present but is!”
  • “No items from WHO DO YOU FOLLOW should be checked but some are”
  • “Product should not be found but it is!”
  • “Search results should not be empty but they are”

This may seem excessive, but if 5 extra seconds of work can save some else (possibly you?) 2 minutes in the future, it is worth it.

Thursday, February 22, 2024

Email: Unmistakable Clarity



Hey Team,

I have talked about "unmistakable clarity" before.  It is very important to me that we all understand each other perfectly.  There is a language barrier because your English is not perfect.  I am not complaining because I ONLY speak English (and a little Spanish).

So, I just want to say that if I ask for more explanation, don't take it personally.  And on the other hand, you can always ask me to be more clear or to talk more slowly.  I want to give a couple examples that cause a lot of confusion.  A LOT of people who speak English perfectly do this:

  • "I was talking to John and Ted about the issue, he told me that it was resolved."
    • He = John? 
    • He = Ted?
  • "I was working on issue A last week and then started work on issue B.  It took extra time, so issue C will be late."
    • It = issue A
    • It = issue B?
  • "I talked to John on Monday and Ted on Tuesday about the issue last week.  We decided the issue was closed."
    • We = you and John?
    • We = you and Ted?
    • We = you and John and Ted?

It, he, she, we, they... these words are called pronouns.  Sometimes they are fine to use and there is no chance for confusion.  But sometimes they can cause confusion, and in this case it’s better to just repeat yourself by saying "I talked to John on Monday and Ted on Tuesday about the issue last week.  Ted and I decided the issue was closed."  It sounds kind of dumb but I still do it because I know it’s the smart thing to do.

And again, any time I’m not being clear, please let me know and I will explain more.


Monday, November 7, 2022

Information Science: Exponential, Logarithmic, and Linear Curves

Motivation

I often hear people use the word "exponential" in phrases such as "exponential growth" or "x is exponentially more difficult than y" (which often times doesn't actually make sense) but I rarely hear people use the words linear or logarithmic.  If you value using English correctly, they're all helpful to know and all are simple to learn.  See the Final Note below for more.

The Curves

For use in conversation, it's not necessary to know the math behind these curves, so I won't go into it.  Here are the curves, with exponential in blue, linear in red, and logarithmic in green:*


Pure math is hard to explain without examples.  I didn't grok algebra until I took calculus.  I didn't grok calculus until I took physics.**  I'll give a couple examples to explain these curves.

Learning:

Learning curves are often described by these curves.  I think this was the impetus for this blog post.  Note: This is kind of sciencey, that is to say, it's pretty nonscientific.  That's also to say I bet some people will disagree.

Exponential:
"Easy to do, hard to get very good at"

Example:
Shooting pool.  Pretty much anyone can pick up a pool cue and knock the balls around.  It might take you a half hour to finish a game of eight-ball, but you can do it.  In my experience, to get to even a "hey, you're pretty good" level takes dedication.  It's an incredibly nuanced game and just seeing the right shot to take, let alone making it and leaving the ball set up for the next shot... it ain't easy.

Logarithmic:
"Hard to pick up, easy to get pretty good at"

Example:
Water skiing.  It's not the most relatable thing.  If you've done it, you know that the hardest part is getting your butt out of the water to a standing position for more than 3 seconds.  I've seen people spend hours and hours getting pulled up, then flopping.  Get pulled up, wipe out.  Get pulled up, eat it.  It's pretty hilarious.  And by "I've seen people" I mean "I've been people."  But once you can consistently get out of the water, skiing itself, going outside the wake, that stuff isn't all that tough.  For this example, let's ignore how hard it is to get to the level of a pro.

Linear:
The more time you put into it, you just keep getting better.

Example:
Well, people will challenge whatever I say here, so I'll say playing guitar.  It'll take about an hour for someone to learn the chords G, C, and D and they'll be able play dozens of songs, many of which are songs everyone knows.  Developing your barre chords takes some work.  Learning scales takes more.  Being able to improvise a solo takes more.  Being able to solo in D flat mixolydian in 7:4 takes even more.  There's always another hill to climb, but with dedication, you can do it.

Scaling:

In many systems, scaling up can be pose some of the biggest challenges you'll face.  Let's take a few real-world examples of scaling where these curves might apply.

Linear:
The more you add, it just keeps getting more difficult about how you'd expect.

Example: 
Chopping wood.  
If you have 100 logs to chop, maybe it'll take you an hour.  If you double the number of logs, you double the time.

Exponential:
You add a little it might be ok, you add more it's difficult, you add even more it's nearly impossible.

Example:
Getting a seat at a restaurant.
You have 2 people, not a big deal.  You have 8 people, ok that'll take some time - you should call ahead and they might have to rearrange the tables when you get there.  You have 30 people, you should definitely call ahead.  Some places might make you pay extra for a private room, and some places will tell you not to come.

Logarithmic:
You add some and it gets difficult pretty fast, but then you keep adding more and it's really not much harder.  Or, at first it's hard but as you add more, even a lot more, it's not much harder.

Example:
I had a hard time coming up with an example for this.  I guess the most obvious would be something that takes a lot of setup, but then isn't that hard to actually do, or after the setup, the work gets easier.  This example doesn't feel as good as the others, but I'll go with automation.

The linear example was chopping wood, and when you double the wood, you double the work.  If you decided to build a wood chopper, getting that very first log chopped would take a huge amount of work because you have to design and build the machine for that first long.  But once the machine is operational, feeding some logs into the hopper just takes a little bit of work, and feeding in more logs takes more work, but is trivial compared to that initial log.

Final Note:

I appreciate correct use of English.  That's why I get frustrated when people say something like "the Titanic is exponentially bigger than that sailboat over there."  Actually, it may be linearly bigger, it depends on the data points between those 2 objects.

If you only have 2 data points, it is not possible to know what the relationship is between them, i.e. what the curve they lie on looks like.  The graph below illustrates this: based on different functions, the 2 data points could have a linear relationship or an exponential relationship.



*Thank you graphsketch.com
**When I took physics 1, it really annoyed me that they hadn't give us examples in calculus, because it made it so clear.  Memorizing formulas without context is a waste of time.

Sunday, July 19, 2020

Language: Precision vs Accuracy


Motivation

People conflate these words but they are distinct, and I think the distinction is both useful and kind of cool.

In short:

Precision: the degree of refinement with which an operation is performed or a measurement is stated
Accuracy: correctness

Precision has to do with specificity, not necessarily correctness.  Accuracy is all about correctness.

Example 1:

If I said 1 foot is 492.763 millimeters, I would have given you a very precise but inaccurate number.
If I said 1 foot is about 300 millimeters, I would have given you an imprecise, but reasonably accurate approximation.
If I said 1 foot is 304.8 millimeters, I would have given you a precise and accurate number.

Example 2:

If I said the Texas State Capitol building was at latitude/longitude 30.276930, -97.7441325 I have given you a very precise location, but it's not accurate.  It's not correct.  In fact, it's cosmetic surgeon's office.  Notice the red pin in the upper-left:


If I said the Texas State Capitol building was at latitude/longitude 30.275, -97.74 I have given you an accurate location, but the GPS coordinates are of low precision, having only a couple of digits after the decimal place.


If I said the Texas State Capitol building was at latitude/longitude 30.2746742, -97.740345 I have given you accurate, highly precise coordinates for the center of the capitol rotunda.  If you sing in there, it sounds REALLY cool.  It's virtually all marble and granite, so the acoustics are incredible!



Monday, May 13, 2019

QA Strategy: Things a Developer Can Work on During the End of the Sprint


Motivation

I call this QA Strategy because sometimes QA has to fight the battle of preventing development from "getting ahead" or as I'd call it, "violating core agile principles."  One place I worked, everyone seemed ok with having sprint planning on the Friday at the end of the sprint, even if QA was still working on current sprint... a battle I lost.  The devs were apparently not creative enough to come up with things they could do to help the team/project/company that didn't involve writing application code.  Not that it made me bitter or anything.

Ideas

Roughly in the order of what I'd request if I was the QA manager
  1. Testing
    1. ...other dev's code of course
    2. Helping QA do their testing
    3. Helping with automation (but not preventing QA from learning/doing automation)
  2. Prepping your demo (if devs do demos)
  3. Documentation
    1. Code comments
    2. Documenting features on the wiki
    3. Organizing / maintaining the wiki
  4. Writing unit tests
    1. Should be done in-sprint prior to giving to QA, but sometimes this doesn't happen
    2. Backfilling unit tests for old code
    3. Fixing old broken unit tests (let's be real)
  5. Writing in-house tools
    1. Integrations to things like Jira, cloud tools, analytics tools, etc.
    2. CI/CD tools
    3. (Test) data creation tools...
  6. Knowledge sharing
    1. Silo busting with other developers
    2. Training other groups in the organization (account managers, support center staff, sales team)
    3. Learning from other groups in the organization (account managers, support center staff, sales team)
    4. Mentoring junior devs
    5. Mentoring people from other groups in the org who want to be devs
  7. Learning new skills
  8. Simple refactoring

Wednesday, March 6, 2019

Language: Necessary and Sufficient

Motivation


This is a nice piece of language I learned in school long, long ago.  It's very useful when talking about requirements or specifications for a project, acceptance criteria for a user story, etc.  Bonus: it makes you sound smart.

Example


The long and short of it is that what you want in order to work efficiently and effectively is the necessary and sufficient information (or tools or whatever).  Since I like working on cars, I'll use the simple example of changing a tire.

If you have the following, you have the necessary and sufficient toolset:
  • a new tire
  • a lug wrench
  • a car jack

If you have the following, you have tools that are necessary, but not sufficient:
  • a new tire

If you have the following, you have tools that are sufficient, but not necessary:
  • a new tire
  • a lug wrench
  • a car jack
  • a hammer

If you have the following, you have tools that are not necessary, and not sufficient:
  • a hammer

Recap


Necessary defines the lower bounds of what you need while sufficient defines the upper bounds.  If you have both, you have the ability to do the work completely while being perfectly efficient.

Email: How to Handle Unplanned Absences & Missing Deadlines

  Motivation Life happens, no one is perfect.  Someone on my team got Covid and had to miss work.  She prepared the best she could, looped i...