career

Prioritizing Small Things

Tonight, I fixed a long-festering car problem: a slow oil leak.

The previous owner had known about the leak for a few years. Her mechanic traced it to the back of the engine but could not locate its source and therefore did not fix it. Thankfully, she informed me about the leak when I acquired the vehicle.

The oil leak was not a major issue, but it did create a burning smell. I put it on my backlog of car projects. (Yes, I have a whole Kanban board for my cars.) It was low priority for the longest time until it finally bubbled up towards the top.

With some Internet sleuthing, I quickly pinpointed the cause: failed expansion plugs on the backside of the engine. I bought OEM replacement plugs because the cheap aftermarket ones had terrible reviews. The job was straightforward: open the hood, remove the engine covers, and pop the old plugs off with a flathead screwdriver. The new ones simply pushed right on. It took me a half hour tops, including the time to take photos.

There were actually two oil leaks. They had clear root causes: the driver side plug was cracked, and the passenger side plug had hardened gunk on its mating surface. All better now!

There are lots of small problems festering in our projects, whether they are car projects, software projects, or something else. I often wonder if it is worth prioritizing lesser fixes if they require smaller effort but improve quality of life. If I had known how easy and inexpensive the fix would be, then I probably would have done it much sooner. I also recognize how smaller tasks can become impossible problems without the right knowledge. I still don’t know why that one specialist mechanic shop couldn’t fix the issue.

Perhaps, in the end, what we choose to prioritize is a reflection of ourselves. We do what we want – and what we can.

Fixing a Bug

I own a 1970 Volkswagen Beetle. Come on, wouldn’t you expect a software tester to drive a Bug? It’s been my daily driver for about four years now. To be honest, it’s given me more trouble than any software project I’ve ever had, but I still love to drive it.

There’s a lot I’ve learned from my journey with my Bug. I had to learn to drive stick. I blew up the engine not just once but twice. I’ve repaired, replaced, or renovated practically every part on this vehicle. The journey has been tough but rewarding. There are many lessons from software I applied to my repairs – and many lessons I learned from getting dirty fingernails that are just as applicable to software engineering.

Last year, I shared the story of my Bug at QA or the Highway in the closing keynote. Later, I recorded a video version of the talk for Abstracta’s Amplify event in Tulsa. I have finally now published it publicly to YouTube for everyone to enjoy.

I hope you love it:

Vibe coding while live streaming

AI-assisted coding tools are great, but they can do unexpected things.

I gave a 90-minute workshop today on Playwright at Testµ 2025, an online testing conference hosted by LambdaTest. I’ve given my Playwright workshop many times before, but I’ve always taught it with “traditional” coding techniques – the way we automated tests before LLMs hit the scene. In today’s workshop, I tried to spice it up with vibe coding in Cursor. We had mixed results.

Perhaps my approach was too ambitious. I tried to develop a small web app first and then teach how to automate tests for it. I’ve had great success recently building small web apps quickly with AI. Unfortunately, though, the workshop app turned out to be a mess. Thankfully, I had another pre-built web app handy as a backup plan. I was able to get Playwright tests up and running with it pretty quickly. The AI did a decent job refining a script produced by Playwright’s code generator, removing duplicate interactions, adding assertions, and abstracting steps into page objects.

My “workshop” was really more like a livestream. It’s hard to set up lessons with exercises on a short virtual call. Even though the code didn’t turn out like I planned, I was honest and direct with the attendees. I demonstrated where AI-assisted coding tools shine and where they stink. We came up with decent results for Playwright testing. And the attendees seemed to get a lot of value out of it. They asked tons of questions and remained active in the chat for the whole session.

While I am slightly disappointed in myself for not being more prepared to avoid pitfalls, I’m glad that I could show the real me. I’m not perfect in my software practices, but I can still be productive, and I can deliver meaningful value. Hopefully, my workshop encouraged others to be bold in trying new things. And I even learned a few things to make my future workshops better.

5 Dev Hacks For Your Software Work Life

Those of us who work in software all spend countless hours grinding away on our laptops to push bits and bytes around. We get set in our ways. We use the tools we are given. We get the job done. Many of us could benefit from a few “dev hacks” – kind of like “life hacks” that you see in short-form media, but for developers (or engineers or whatever kind of software title you bear). Here’s a list of dev tips that have helped me, and that I hope can help you.

#1. Buy a laptop case for your stickers

Stickers are like tattoos for inanimate objects, and the greatest canvas for dev stickers is the dev laptop. The only problem is that when the laptop goes, so too go the stickers. If it’s a corporate laptop, then IT department will curse you for making them scrape the stickers off.

What’s the solution? Buy a laptop case, and put your stickers on the case instead of directly onto the machine. That way, you can easily remove the stickers whenever you want! You could even turn old cases into wall art. Laptop cases are typically inexpensive, so there’s no reason why not to buy one.

Here are my laptop stickers on a hard plastic case:

#2. Use Excalidraw for nice diagrams

Excalidraw is an online diagraming tool that is easy to use and makes beautiful diagrams. It is free to use, and you can pay-to-win with advanced features. I use it all the time. It’s incredible. Check it out:

Screenshot 2025-04-12 at 10.32.58 AM.png

#3. Invest in a decent audio/video setup

Ever since the COVID shutdowns, everybody has virtual meetings. You need to dial in, appear on camera, and speak on a microphone. You might as well look good and sound good while doing it. It’s more professional, and others will subconsciously think more highly of you. So, what should you get?

What you need	What I use
A high-quality USB microphone with a boom arm	Blue Yeti
A 4K webcam	MacBook Pro webcam / Sony ZV-1
Dual desk lights, angled downward	2 x Elgato Key Light
Noise-cancelling headphones	Sony WH-1000XM5

Here’s my setup:

Also, use those headphones to listen to some Lo-Fi music while working!

#4. Keep your snacks and drinks close

When you’re in the flow state, you do not want to be interrupted. Don’t let your hunger or thirst be an interruption. Keep a stockpile of your favorite snacks and drinks within arm’s reach. You could hold a stash of Reese’s peanut butter cups in a drawer. You could put a coffee machine on your desk. I keep a mini-fridge stocked full of Cheerwine, Ito En green tea, and Liquid Death cans in my office.

#5. Become part of tech community

Joining a tech community is one of the best ways to level up your skills. You will meet awesome people and become inspired by the ideas they share. I know I wouldn’t be the Panda I am today if I didn’t get involved in the Python community and the Testing community. There’s a big difference between being a user of a technology and being part of the community for the technology. Go find local meetups for tech that interests you. Attend a conference. Contribute to open source projects. Put yourself out there!

X is unhinged. Find me on Bluesky.

X (formerly Twitter) is unhinged.

I received a DM through X today from someone claiming to be an Amazon seller asking me to review a set of “adult products” in exchange for “prepaid compensation.”

I joined Twitter back in 2017 to join the “Tech Twitter” community. It was awesome! I connected with so many colleagues, kept up with all the latest developments, and learned so much.

Ever since Elon took over, X has degraded. My feed is polluted with the man himself and all the politics that come with him. Many of my friends and followers have left. I constantly receive spammy messages from crypto bros and catfishers. Today’s DM is a new low. I can’t justify using X for professional purposes anymore.

I’m moving to Bluesky. I’ve already been there for a while. Join me and the rest of Old Tech Twitter. 🦋

Here’s my profile: https://bsky.app/profile/automationpanda.bsky.social

I Want To Be An Engineer When I Grow Up!

When I was a little boy, I wanted to be an engineer when I grew up.

That’s right, I wanted to be a locomotive engineer! Like all little boys, I absolutely loved trains. I watched all the episodes of Thomas the Tank Engine. I wore a striped blue-and-white railroad cap everywhere. And I wanted to grow up to be the guy in charge of the trains.

More than once, my parents took me to see the Chattanooga Choo Choo in Chattanooga, Tennessee. To me, the vibrantly-painted steam engine was just the coolest thing ever. I’d climb into the engine bay (which was allowed) and imagine how much fun it would be to drive it. I don’t remember much of anything from that young age, but I vividly remember pictures in my mind of the Choo Choo.

I actually did grow up to become an “engineer” – just not the kind of engineer my four-year-old self would have expected. This week, my software engineering journey brought me back to Chattanooga on a customer visit. My hotel was located right next to the old train station housing the famous Choo Choo, so, of course, I paid it a visit. It was just as I had remembered it: charming, nostalgic, and iconic. Oh, how I yearn to build things that become as cherished and enduring as the Chattanooga Choo Choo.

Our dreams may not always manifest as we expect, but I am grateful for all the opportunities I have been given and for all the incredible experiences they have brought. Even though my current job title is “Product Management,” I still identify as an engineer at heart: building solutions to tough problems. Never let go of the things that inspire you.

Bulldog-Driven Development

Today is a special day in the Knight family. On November 5, 2021, my wife and I drove down to Waxhaw, North Carolina to adopt the cutest French Bulldog puppy in the state. We named her “Suki” – a Japanese name meaning “beloved.”

Suki was the first dog my wife and I had ever owned. She was only 7.5 weeks old when we picked her up, and she weighed only 3 pounds! I could scoop her up with one hand. When she first arrived home, she was so nervous that she tried to bury her face in her new doggy bed to hide. Now, three years later, Suki is a BEAUTIFUL 20-pound beefcake who has crisscrossed the country with us. We love her dearly. She is a gift from God.

I often joke about #BDD being “Bulldog-Driven” rather than “Behavior-Driven.” Remember, though, we are all driven by something. In my software work, I absolutely take a behavior-driven mindset, but I’m also driven by my Family, my Faith, and my Frenchie. Never lose sight of what drives you.

Photo: Suki with her portrait as “AstroSuki” – my speaker gift from QA or the Highway 2024!

Test coverage and trusting your instincts

Picture this: It’s 2010, and I’m fresh out of college, eager to dive into the software industry. Little did I know, a simple interview question would challenge not only my knowledge about testing but also my instincts.

Job openings were hard to find in the wake of the Great Recession. Thankfully, I landed a few interviews with IBM, where I completed a series of internships over the summers of 2007-2009. I was willing to take any kind of job – as long as it involved coding. One of those interviews was for an entry-level position on a data warehouse team in Boston. I honestly don’t remember much from this interview, but there was one question I will never forget:

How do you know when you’ve done enough testing?

Now, remember, back in 2010, I wasn’t the Automation Panda yet. Nevertheless, since I had experience with testing during my internships, I felt prepared to give a reasonable answer. If I recall correctly, I said something about covering all paths through the code and being mindful to consider edge cases that could be overlooked. (My answer today would likely frame “completeness” around acceptable risk, but that’s not the point of the story.) I’ll never forget what the interviewer said in reply:

Well, that’s not the answer I was looking for.

Oh? What’s the “right” answer?

If you write roughly the same number of lines of test code as you write for product code, then you have enough coverage.

That answer stunned me. Despite my limited real-world experience as a recent college graduate, I knew that answer was blatantly wrong. During my internships, I wrote plenty of code with plenty of tests, and I knew from experience that there was no correlation between lines of test code and actual coverage. Even a short snippet could require multiple tests to thoroughly cover all of its variations.

For example, here’s a small Python class that keeps track of a counter:

class Counter:

  def __init__(self):
    self.count = 0

  def add(self, more=1):
    self.count += more

And here’s a set of pytest tests to cover it:

import pytest

@pytest.fixture
def counter():
  return Counter()

def test_counter_init(counter):
  assert counter.count == 0

def test_counter_add_one(counter):
  counter.add()
  assert counter.count == 1

def test_counter_add_three(counter):
  counter.add(3)
  assert counter.count == 3

def test_counter_add_twice(counter):
  counter.add()
  counter.add()
  assert counter.count == 2

There are three times as many lines of test code as product code, and I could still come up with a few more test cases.

In the moment, I didn’t know how to reply to the interviewer. He sounded very confident in his answer. All I could say was, “I don’t think I agree with that.” I didn’t have any examples or evidence to share; I just had my gut feeling.

I sensed my interviewer’s disappointment with my response. Who was I, a lowly intern, to challenge a senior engineer? Needless to say, I did not receive a job offer. I ended up taking a different job with IBM in Raleigh-Durham instead.

Nevertheless, this exchange taught me a very valuable lesson: trust your instincts. While I didn’t land the job that day, the encounter left an indelible mark on my approach to problem-solving. It instilled in me the confidence to question assumptions and trust my instincts, qualities that would shape my career trajectory in unforeseen ways. Never dismiss your instincts because you are less senior than others. You just might be right!

Judging Developers by GitHub Contributions

The main image for this article shows all my GitHub contributions for the past year (roughly April 2023 through March 2024). Check it out. ☝️🐼

Notice anything?

My contributions pretty much stopped around August 2023.

Why?

That’s when I changed jobs.

Until July 2023, all my professional coding work went into open source repositories in GitHub. After changing jobs, all my professional coding work went into closed source repositories in Azure DevOps.

Did I suddenly stop coding at that time? No. In fact, I did more coding – and arguably more serious development work – at the second job.

Tech social media periodically explodes with posts saying how developers who don’t have walls of solid green GitHub tiles aren’t “serious” about their work. How the folks writing these posts wouldn’t hire developers who don’t have enough green tiles. How any developer worth their salt should regularly contribute to open source projects outside of their 9-5 job. These posts are sometimes sarcastic, but they are, unfortunately, all too often sincere – and you can’t always tell.

These posts are rubbish. It is foolish to judge a developer by the number of GitHub contributions they make. Sure, it can be a helpful data point when reviewing someone’s body of work, but it is merely one data point. Someone’s lack of green tiles should not justify putting them down. It should not immediately disqualify them as a candidate from a job opening. Not everyone’s work involves open source contributions to a particular hosting site. Not everyone’s life permits extra work-like work outside of work, especially for zero pay.

Open source contributions are a great way to give back to the software community as well as to build up one’s skills. It’s also a great way to show one’s work publicly. But please, don’t fall for the trolling – either for the flame wars or for the insinuations of inadequacy. There are plenty of talented individuals who don’t have a wall of solid green tiles to “prove” their skills, myself included.

Software Engineering Seniority Levels

All software engineers are the same, right? Well, not exactly. There is a strata of different seniority levels, each with its own expectations for experience, responsibilities, and pay. This article is a concise collection of my observations on seniority levels for software engineers.

The levels

Every company is different, but I’ve seen most companies coalesce around the following levels:

Level	Responsibilities	In Plain Terms
Entry	Do what you are told. Learn as much as you can.	“What’s a cookie?”
Intermediate	Complete tasks independently. Get things done. Be a good team player.	“I bake chocolate chip cookies.”
Senior	Take ownership of bigger projects. Know what you’re talking about. Help other engineers get unstuck.	“I help folks mix cookie batter.”
Staff	Provide technical direction for an organization. Collaborate cross-functionally for technology alignment. Do the needful to keep projects moving. Mentor other engineers.	“I make cookie recipes.”
Principal	Provide technical direction for a company or even an industry. Collaborate with management for business alignment. Carry significant influence backed by deep experience.	“I know everything about cookies.”
Distinguished	Make exceptional technical contributions to the company. Shape the direction of the company and its technologies.	“I invented the ice cream sandwich.”
Fellow	Create and guide a crucial technology that drives a significant portion of the company’s revenue for several years.	“I am the Cookie Monster.”

These levels usually apply for all types of engineers (frontend, backend, test, data, DevOps; whatever) up to Principal. Again, specific details vary by company.

Population at each level

The breaking point tends to be between Senior and Staff. Many engineers make it to Senior. A few make it to Staff. Fewer make it to Principal. Distinguished and Fellow are very, very rare. Some companies don’t even have Distinguished or Fellow.

Earning promotions

There are two main ways to earn a promotion:

Start fulfilling responsibilities for the next seniority level above you. Then, clearly advocate for a promotion to your manager leading up to your periodic performance reviews. Finally, hope that you get selected for a promotion.
Switch to a new job that has the title you want. Usually, this needs to be at another company.

Switching companies is typically the fastest way to climb the seniority ladder as well as to increase your pay. Many companies impose quotas for annual raises and promotions.

Salary ranges

Seniority titles are important because they impact pay. Usually, a company sets a salary range for each seniority level. When you get promoted to a new level, your salary starts at the low end of the range for that level. As you progress within the level, you will (hopefully) earn raises that put you higher within the salary range. Eventually, once you hit the top of the range, you can’t earn more raises until you earn a promotion to the next seniority level. Also, good luck finding out what those salary ranges actually are. Many companies keep them secret.

Title mismatch

Someone’s seniority prefix does not always match their actual capabilities. Sometimes, their title is lower than the level at which they perform. This happened to me once when a bigger company bought the startup where I worked and reassigned everyone’s titles to fit their own career tracks. More often, though, I’ve seen “title inflation” where an engineer is given a higher title than their capabilities reflect. Companies usually do this either to hold onto important engineers or to woo prospective new hires. In those cases, titles match salary band, rather than salary matching seniority. That’s why it’s more important to look at a person’s accomplishments rather than the prefix on their title.

Becoming a manager

It is commonplace for engineers to become managers. However, engineering and management are separate tracks requiring distinct skill sets. The difference is the focus of the work: technology (engineer) or people and business (manager). If a company has a well-defined seniority ladder for engineering, then engineers don’t need to become managers to earn a “promotion.”

Other thoughts?

This information is all anecdotal based on my general experiences. What have you seen? Let me know in the comments below!