Thank goodness for that SQL training

The other day, one of the testers in the team raised a concern to the developers. He shared that he was trying to insert a record and there was an error. Now I’ve known SQL to be informative in case there’s such an insert error; and true enough, the error mentioned the problem with a Foreign Key constraint. I guess the problem was he didn’t know how to interpret that Foreign Key constraint.

This just made me appreciate the SQL training that I got from my first company. In my first two weeks in the job, I remember my SQL training consisted of being asked to read Teach Yourself SQL in 21 Days. Afterwards, part of the exercises was an existing bigass report that was programmatically generated that I had to recreate using one SQL query–down to the data format conversions.

Of course initially I didn’t appreciate the Data Definition Language (DDL) part as much. For testing, my work was more focused on the DQL and DML parts (Data Query Language, Data Manipulation Language). But, of course, as you encounter errors with your insert or update statements, you get to appreciate the DDL part as that lets you know what you did wrong in your statement.

Over (*BLEEP*) years later, I still find SQL and that basic understanding of a relational database such a valuable part of my skill set. And its value to me has definitely extended beyond testing. It helps me figure out what entities and attributes (shown or visible) would be needed to accomplish certain functionalities as I do my PO or BA work. It helps me communicate with devs e.g., when explaining how something should be retrieved or when I need to describe certain classes of objects to them. It helps me spot inefficiencies in some implementation (e.g., when they were retrieving the latest status details from a history table, or like when they concatenate something when they store it into one field then forgot they had to edit it separately).

Come to think of it, aside from being useful, SQL, RDBMS and database design are pretty interesting too. Or maybe that’s just me having learned to love my work. 🙂

[Edit] If anyone’s reading this, please share good references on the topics in the comments. Just maybe for reference of anyone else who wants to get started.

That dot-dot-dot menu (…)

My teammates and I were grooming a user story and we had to document certain expectations around that particular icon. I initially typed it in as “context menu (…)” which I learned later on that it wasn’t. And my teammates told me that they just call it the dot-dot-dot menu. Well, that works. But I was curious as to what it’s officially called, so I googled.

– dot dot dot menu
ellipsis button (singular) according to Microsoft documentation guidelines
More according to Apple
– more options
– others: meatballs, dumplings
– burger
– hamburger
navigation icon according to Google
– kebab
– vertical ellipsis button
overflow menu according to Google

I mentioned I got it wrong about the “context menu”. One of the results I came across had a description for the context menuContextual menus aren’t triggered by a consistent UI element. They appear next to where a user taps, and their actions can vary based on the tap target.

Anyways, one image result that turned up summarized those icons quite nicely:

Classic watch-out: Test emails

This is a bit of a classic watch-out. I say classic because this is a bit of a faux pas that I’ve heard of or even encountered way before, that newer generations of testers still encounter. Whenever the app or system being developed requires test emails, one thing we need to be careful with is to not send out test email to unintended recipients.

Just a few sample cases I’ve heard of

  • Site leader receiving test email notifications
  • Test email used was too common or was very likely to be real e.g.,
  • Fictional email addresses using an existing email service e.g., were used, but it wasn’t known whether those email addresses were or were not in use

If the domain of the email address isn’t limited to the client’s domain, then one option is to use a Gmail email address for testing. For example, if your main Gmail email address is Then there are two email hacks you can use to come up with multiple email addresses, all of which can be used to receive email via your main Gmail email address.

Plus (+) hack
Append “+” and some keyword before the ‘@’ sign. E.g., I also used the appended text to capture the teams or hierarchy in some of my previous tests.


Dot (.) hack
This one, I don’t really use so much. But it’s an option if the application under test is having problems with the “+” special character. Insert “.” within the email address before the ‘@’ sign. E.g.,


OPP and that Wardley thread

Just a couple of reads I found very interesting this morning.

First is (OPP) Other People’s Problems posted in Medium by Camille Fournier. I’m a firm believer of how it’s so important to choose your battles because (1) not everything is worth it, (2) time is finite and you have to prioritize, and (3) maybe it’s not even your problem to begin with. That post shares some tips and someone had shared a flow chart for how to decide where you spend your energy on.

Second is this thread in Twitter posted by Simon Wardley (the guy behind Wardley Mapping). It’s about one particular customer making a very unique request, and Mr Wardley saying it’s a bad idea. For those of us who’ve been there–getting that very special, super-specific request that feels like it’s more effort than its worth–then this feels very relatable.

That unfinished podcast (with suggestions on how to improve at work)

I listened to a podcast just last week and I didn’t even get to finish it. I meant to resume it but the link no longer works (here’s the link just in case it ever becomes available again). But within the fifteen minutes I paid attention to, I got to hear the following tips in bold and jotted down a few notes (not so comprehensive as I was only passively listening).

  1. Don’t just learn, loop. – Do your job a little better every day.
  2. Do less, then obsess. – Be brutal in your prioritization. Saying yes to many things -> mediocrity. Master few things. Cut out all that other stuff.
  3. Become a forceful champion. – We achieve through others, we work with people we don’t have authority over… Inspire, build alliance.
  4. Fight and unite. – In good meetings, we are discussing (fight). Unite part is about decision, no undermining. [Link to YouTube video of author explaining Fight and Unite, around 3 mins]
  5. Disciplined collaboration. – Big problem is overcollaboration. Disciple the collaboration — on few things, most important things.
  6. Redesign your work. – Look into how can you do your work differently, better… frequently, not just annually.

The guest in the podcast was the author of the book and I had to google a bit to find out that the guest and book were Morten T. Hansen and Great at Work: The Hidden Habits of Top Performers (2018). I also came across the video of the author explaining “Fight and Unite” (added the link above).

Reaching for goals

Heads up, this is a brain dump! But come to think of it, all my other posts are. 🙂

I think there’s often an emphasis on knowing what the goals are, and even the why behind those goals. We see a roadmap, a strategy plan, some high level visualization of what we’d like to accomplish. But the devil is in the details. It’s in the how where things get muddied (all the more so if intent wasn’t clear to begin with), and which makes all the difference whether we actually reach our goals or not.

One of my favorite quotes has always been:

A goal without a plan is just a wish.

What prompted this post is one of the Medium posts that showed up in my feed today. It’s about The four simple habits of exceptional leaders. And Habit 3 is “Becoming process orientated, not goal orientated.” The post comes with a convenient takeaway point:

“Takeaway point: By focusing on improving the way we and our teamwork to achieve our goals, and forming habits of always seeking to improve how we work, we will ensure our goals are continually met and exceeded.”

And I agree. I’m not dismissing the what and the why aren’t important, because they are! It’s just that the how is just as important. And part of the how includes the nitty-gritty stuff like

  • working agreements
  • communication plans
  • team dynamics
  • good meeting practices
  • plan-do-check-act stuff
  • execution details especially who does what, how to check if on track, etc.
  • retrospectives
  • lessons learned

And generally looking at how you’re working (or not) towards your goals including reevaluating if those goals are still relevant. Half of me feels like these are basic stuff, the other half tells me we don’t know all these by default… we get to realize their importance over the course of many projects and hopefully not too many failures. This is why leadership is so challenging when you want to do it right — it requires experience (not measured in years), knowing to be in the present and at the same time have hindsight and foresight, seeing both the details and the big picture, serving across different levels sometimes with conflicting priorities, the pull of many directions that you somehow need to balance to keep on moving forward.

Read: Clarity First

The book Clarity First: How Smart Leaders and Organizations Achieve Outstanding Performance by Karen Martin is one of the books that often show up among the recommendations whenever I’m shopping for books to read at Amazon. It’s a bit too pricey for me though at $19.25. Luckily, it’s available through our office subscription to Skillport.

As I read it, there was a lot of what feels like a statement of the obvious or the author preaching to the choir. But I guess the value of this is that I get to read better elaborations of stuff that I feel just make sense but couldn’t explain as well. There were also a lot of parts that were good refreshers — stuff that I’m pretty sure most of us know but forego in the rush of being too busy.

For my notes here, I just noted what felt new, was a value add to me, or something that highlighted a point that I often overlook.

  • Chapter 1 is on clarity vs ambiguity
    • Self-assessment link
    • The A in VUCA as different from its three other friends (Volatility, Uncertainty, Complexity) “since ambiguity is a man-made condition that exists within the other three”.
  • Chapter 2 is on Purpose
    • I came across gemba or “the real place” where the action happens again.
    • The chapter also has some guide questions to aid in thinking about purpose.
  • Chapter 3, on Priorities
    • It reiterates the often ignored point on multitasking i.e., that it’s not as productive as most folks think it is.
    • TIL Ishikawa, that I only know for a fishbone diagram, was a Quality Management professor in the 1950s.
    • It has a section on creating a strategy deployment plan, which is a good point of reference to compare with how you’re currently doing it.
    • There’s a reference to “leader standard work” in the footnotes. I’m not sure if that’s a Lean reference thing so it’s something to google for later.
  • Chapter 4, on Process
    • Interesting quote: “A business is the sum of its processes.”
    • In this chapter, she goes into value streams which is also something she had co-authored another book on.
    • TIL of three productivity-robbing “enemies”: muda, muri, and mura. Muda refers to all forms of waste, including overproduction, overprocessing, errors, rework, excessive inventory, waiting, excess motion, excess transportation, and underutilization of people. Muri refers to overburden on equipment and people. Mura refers to unevenness.
    • “A well-designed process creates the potential for success, but execution determines whether the design is fulfilled in such a way that it meets its potential. And execution is wholly dependent upon whether the organization has people with the necessary level of skill, experience, and authority doing the work.”
    • Well-managed processes are documented, current, followed, consistently monitored, and regularly improved.
  • Chapter 5 is on Performance, so concept of KPIs are definitely not far behind.
    • TIL of levels of the scorecard. With Level 3 at the organizational level and usually with a maximum of nine KPIs. Level 2 KPIs are relevant to a business unit, division, or department, depending on organizational structure. And Level 1 KPIs are particular for a department or work team.
    • Hawthorne Effect is where people behave differently when they know what’s being measured.
  • Chapter 6, on Problem Solving
    • Need to differentiate problem solving from problem mitigation.
    • “Problem-solving skill building is the most important aspect of people development. Viewed through this lens, problem-solving coaching is the primary role of the leader.”
    • It highlights why there should be a singular problem owner; when everyone is accountable, no one is accountable.
    • Interesting: ‘One of our common warnings is: “When you automate waste, you get automated waste.”‘
    • The whole sections on CLEAR problem solving (Clarify, Learn, Experiment, Assess, Roll out) is a good refresher.
  • Chapter 7, You, asserts that the hallmarks (the five P’s of Purpose, Priorities, Process, Performance, and Problem Solving) of organizational clarity can also apply at the personal level.
  • Chapter 8 is on Committing to Clarity — it’s something that you take one step at a time, intentionally and consistently practice until it becomes habit.

Read: Where the Action Is

I’ve just finished reading up to Part Three of the book, Where the Action Is: The Meetings that Make or Break Your Organization by J. Elise Keith. The fourth and final part of the book has chapters which can be read separately as each chapter dives deeper into each type of meeting. But even up to just Part Three, there’s so much to takeaway from the book. If I had money to burn (which I don’t) AND I’d be guaranteed that recipients would actually read it, I’d give away copies of this book.

What I find interesting about it is the idea the author shares on how it seems like a cycle that meetings are bad because we’re already resigned to the idea that meetings are bad. So people use it as a crutch or as an excuse. Instead of actually doing something about it, they just think it’s not going to be worth it anyways. There’s also the idea of some individuals misusing meetings to further their egos, as a means to dominate, rather than to advance the team’s goals. So for such individuals who shine in dysfunctional meetings, it’s not in their best interest to “fix” meetings.

Coincidentally, I came across this quote: “For the great doesn’t happen through impulse alone, and is a succession of little things that are brought together.” It’s from a translation of Van Gogh’s letter to his brother, Theo. And I think it highlights intentionality. In the same vein, if you want to have your meetings actually turn out productive, you really ought to take the steps to drive it to that direction.

Something about meetings

I suppose most of us have had our fair share of it-could-have-been-an-email meetings. This is not a totally new topic, but I’ve come across a couple of posts in Medium about it, and I’ve recently taken to reading a book about it.


Wikipedia describes it as: the “informal process of quietly laying the foundation for some proposed change or project, by talking to the people concerned, gathering support and feedback, and so forth.” As opposed to using the actual meeting with the larger group, the alternative is to meet on one-on-ones or separately to set context, provide needed background, and maybe establish some rapport. And by the time the larger group meeting takes place, a lot of the groundwork of bringing people into the same page has already been initiated.

Silent Meetings

This reads like something that sounds like a working session. (Silent, yet sounds like something.) Often times, or at least I think what happens more often, you send out an agenda of something to think about requiring suggestions and ideas. And then people wouldn’t bother. And when the meeting time comes, instead of already discussing ideas or solutions, people are only then thinking about it. By the time the ball is rolling and ideas are being thrown around and reinforced, the time is up.

As an alternative, you hold the “table read” along with discussing and addressing comments as part of the meeting. People will pretty much still need to invest the time to read, review, and address comments. But I guess what you save on is the waiting time. And you’re pretty much guaranteed that Person X actually took the time to read it.

A bit off topic, but the illustration in the 26-minute post for the Silent Meeting Manifesto is just so cute.

I like how this type of meetings is described as more of a “home room”. Because sometimes you just need a common time to go over the same material so that you know it won’t be as disruptive to ask or discuss a comment about it.

Book: Where the Action Is

I’ve only finished up to Part 1 (of 4) of the book. What’s interesting is the idea the author shares of why people hate meetings. I guess obvious reasons would be if it’s such a waste of time. But what she brings up is that hating meetings is being used as a crutch.

Some people are resigned to thinking meetings suck anyway, and use that as “a fabulous excuse for staying ignorant about how to make meetings work well.”

And for some mema* or dominant individuals, meetings can be a chance to showcase themselves or their ideas or might feel “wasteful” if they have to listen to “lesser” ideas (i.e., not their own). Effective, well-structured meetings might take away their time to shine.

*mema = “May masabi lang”; the annoying person who just has to have a very very vocal opinion on anything and everything

Anyways, still three quarters to go, and I suppose that’ll be where she’ll cover what’s needed to go beyond that excuse and actually improve on your meetings.

That measure-manage quote myth

I guess I’ve been working long enough to have come across that Deming/Drucker quote being thrown around, AND to have come across some other material saying the quote has been misattributed to those two. I’ve never really taken the time to look into it any further, but this lazy, rainy quarantiney morning has given me some time to google it.

The quote in question is: If you can’t measure it, you can’t manage it.

And although they may not have said that quote, measurement is still something they had emphasized. Paul Zak (a link to his work is shared below) puts it best: So, measurement, yes. Only measurement, no.

W. Edward Deming’s case

The funny thing is what he actually said was:

It is wrong to suppose that if you can’t measure it, you can’t manage it—a costly myth.

Wow, they literally just got what was in the middle, and totally reversed the meaning. He had written this in The New Economics: For Industry, Government, Education.

Peter Drucker’s case

I came across two blog posts sharing he never actually said it.

They both linked to page in the Drucker Institute website, but that had already been moved. But the title was easy to google for, so I was able to find the page to Measurement Myopia written by Paul Zak in Jul 2013.