Let’s face it: working in software is tough. I’ve worked in software for over a decade, and I’ve learned a lot of things during my journey – oftentimes the hard way.
On April 7, 2022, I tried something new: every hour for 24 hours, I tweeted a lesson I learned during my software career. I covered topics like breaking into the industry, working on projects, and seeking advancement. I used the hashtag #PandyEveryHour to track my tweets. I started at 8am (US Eastern) on April 7, and I concluded at 8am on April 8. It was an awesome experience: lots of folks liked, retweeted, and commented. Some of my insights struck nerves.
In case you missed it while my tweets went live, I compiled all the tweets below in order. Give them a read! If you like any of them in particular, be sure to “like” them on Twitter so I know!
Breaking into the software industry
Working with others
Improving your skills
So, which lessons resonated the most with you? Which did you disagree with? Let me know!
The main photo for this article was taken at DjangoCon 2019 during one of the breaks between sessions.
At my new job as Developer Advocate at Applitools, I now permanently work remotely. Working from home is new to me. At my previous company PrecisionLender (later acquired by Q2), I worked in an office that was a seven-minute drive from my house. My office was a real office: an enclosed room with a door, walls, a large desk, and two huge whiteboards. Working from the office was a joy. We had free snacks and sodas. My colleagues and I all got along great, and we’d go out to lunch almost every day. After COVID-19 hit the USA in March 2020, I was heartbroken to abandon the office. I was so stubborn about eventually returning to the office that I refused to set up a decent workstation at home. For a year and a half, I worked exclusively on my laptop either from a desk in my living room or from the couch – no monitors, no mouse, and no separate keyboard. I mean, come on, the pandemic would be over in a few short months, right?
However, my attitudes about remote work are changing. At PrecisionLender, I was spoiled with the best kind of office situation someone could have. Many others in the software field are not so fortunate. Those who live in the big cities like New York and San Francisco pay thousands of dollars a month to split tiny apartments and spend an hour or more on one-way commutes. Not to mention, many of them move away from family and friends to take those opportunities.
Office layout trends in recent years have also been dismal. The open layout – no walls with clusters of desks sloppily smashed together – is the norm. Perpetual audio and visual distractions are a nightmare for anyone trying to concentrate. Widescreen monitors and noise-cancelling headphones only help a little. I experienced that frustration at MaxPoint and LexisNexis. Cubicles, while passé these days, are only a small step up from open floors. While the “walls” block out visual distractions, you can still hear everything that goes on around you. Plus, the enormous blocks of cubicles on a floor feel brutally confining. I frequently called the IBM 500 complex in RTP “Cubicle City” when I worked there.
Remote work can be a godsend for many hardworking folks who just want to do a good job while doing right by themselves. Folks, especially in software, can literally work anywhere. COVID-19 shutdowns have proven it. My wife and I even took advantage of it: we bought a vacation condo in Seattle, and I worked remotely from there for several weeks. I could automate tests during the day, grab beers with close friends, and catch a Mariners game on the weekend. Even with a 3-hour time zone difference, I was right in step with my team the whole time.
Recently, I saw a Twitter thread by Chris Herd in which he made several predictions on remote work in 2022 and beyond:
This thread really resonated with me. While I still have some concerns about remote work, I do believe it will be a net good for not only my country and people but also for the world. I’d like to highlight some of the points he made that really stuck out to me.
I agree completely with this, and I’m excited to see it happen. The US has so many awesome places, from sea to shining sea. There’s no reason why someone should need to move from their hometown to a big city just to work for a specific company (unless, of course, they want that adventure). Places like Raleigh-Durham, Nashville, Denver, Miami, Pittsburgh, Salt Lake City, Cleveland, and countless other smaller American cities are fantastic places to live. Each has a unique vibe and local specialties. Allowing folks to live where they want with good employment opportunities will rejuvenate local and regional economies. It will bring broader prosperity to all.
This is happening already. The Triangle of NC, where I live, is booming. My wife and I rent local listings on Airbnb, and all through the pandemic, the #1 type of guest we’ve hosted by far is someone interested in relocating to the Triangle.
I hadn’t thought about asynchronous work until Chris mentioned it, but he’s right. Life is 24/7, and people live all around the globe. Remote work can liberate us from a harsh 9-5 and instead embrace more flexible hours. For example, this past week, I had to work around the clock for a few days prepping a big webinar. However, I wasn’t working for 16 hours straight each day. I woke up a bit late, did some light administrative activities before lunch, hit it hard all afternoon, stopped for dinner and time with my puppy, and then burned the midnight oil after dark. That’s what worked for me.
Yes! I’m living it myself. My wife and I just adopted a French bulldog puppy, and I also started restoring a vintage 1970 Volkswagen Beetle.
I sure hope so! Break down those entry barriers. Do away with the gatekeepers. End coastal elitism.
I sure hope this one becomes true, but I’m skeptical.
This one is so ironic. Based on many articles I’ve read, upper management seems to despise work-from-home because they think their workers will work less. However, all the good, hardworking folks I know are actually working more than ever. Not only are folks more efficient, but they tend to keep working just a little extra because there are fewer barriers between work stuff and personal stuff. In my new job, I know I’m certainly working more hours right now than I probably should, and I’m hoping to settle into a more sustainable routine as I acclimate to my new role. Nevertheless, we absolutely need to protect ourselves against unintentional burnout.
One big concern I have with remote work is the loss of in-person contact. Humans need to be around each other, and screens are a poor substitute. I know I’ve felt lonelier working from home than when I worked in an office. That’s why I absolutely love this idea about regular remote retreats. Companies can still bring folks together, and they can hire professionals who know how to maximize that time. I go to software conferences frequently for similar experiences.
I think this goes hand-in-hand with async work. However, unless safeguards are put in place to prevent overworking, then life-work balance could quickly become work-more-work imbalance.
Honestly, this one was never much of a problem for me. The only “paddings” I’ve had in my workdays are long, boring meetings where I participated little. Thankfully, those were confined mostly to my days at IBM and NetApp earlier in my career.
YES! Even though my commutes have always been relatively short, I still appreciate the time I get back in my day. Here are some things I’ve done with my extra, more flexible time:
Sleep in a little later
Play with my puppy when I need a break
Share lunch nearby with friends
Run a quick errand in my Beetle
Grab an impromptu bubble tea with my wife
Take a walk around my neighborhood while thinking about work-related challenges
Documentation is the unspoken superpower of remote teams. I strongly value written communication for its clarity, searchability, and permanence.
Chris had lots of other good tweets in that thread, so be sure to read them. Overall, his tone was bullishly optimistic on remote work – not only in its benefits, but also in its inevitability. Personally, I hope remote work is here to stay, and that it’s not just a phase brought on by the COVID-19 pandemic. It’s a game-changer for individuals and industries alike. However, I’m still somewhat fearful that big companies will reign in wide scale returns to the office after the pandemic. Giants have already sunk millions to billions in commercial real estate for their offices that they can’t get back. I’m also worried about salaries in different geographies. Employers already pay folks who live outside of big cities much less for the same work due to cost-of-living differences. I don’t think that will be fair as people leave big cities in droves for smaller cities or the countryside. Already, the cost of living is skyrocketing in the Triangle, yet our average tech salaries are far below those of Silicon Valley. We’ll see what happens.
Overall, I am optimistic about remote work just like Chris.
So, what do y’all think? Please leave comments below. I’d love to learn different perspectives!
I’ve always been frustrated with poor quality audio recordings. Microphones built into laptops are very convenient, but they usually yield tinny sound lacking the depth of real voices. When I asked my audiophile friends for advice, they recommended studio-level equipment that was beyond my comprehension and my budget. As a software guy, I just wanted an audio setup that captured high-quality audio while still being convenient for everyday usage. I’d need it for remote meetings as well as for recording talks and tutorials. I was willing to pay for good equipment as long as I could use it well. Unfortunately, my biggest frustration was ignorance. I didn’t know anything about recording.
When I did my research, the Blue Yeti microphone was at the top of everyone’s recommendation list. The nicest thing about a Blue Yeti mic is that it connects via USB. You simply plug it right into your laptop and select audio input and output channels. The mic doesn’t need an external power source, either.
Initially, I bought only the Blue Yeti mic and the foam windscreen. Instead of using the boom arm, I used the tabletop stand that came with the mic for all my recordings. This was a big mistake. The tabletop stand picked up a lot of local noise, like typing on a keyboard. The audio quality it picked up also sounded like it had a bit of an echo, which may have been due to sound bouncing off the tabletop or my hardwood floors.
The boom arm and shockmount made a huge improvement in recording quality. Plus, with the boom arm mounted firmly to my desk, I can easily move it towards me for recording or out of the way otherwise. It feels quite sturdy. I chose to use all Blue products so that I could be certain that they’d work together. You can save quite a bit of money if you buy the microphone, boom arm, and shockmount together as a bundle on Amazon (~$200), instead of a la carte like I did (~$250).
I plan to get a docking station for my laptop so that I can plug the microphone’s USB cable into the dock, simplifying desk’s cable management.
Even with this new setup, I still felt like I didn’t understand how to use my Blue Yeti microphone to its full potential. Thankfully, YouTube came to the rescue! This video greatly helped me understand things like tuning the mic’s gain and positioning the mic while speaking:
In summary, here’s what I like about the setup:
It yields very good (maybe professional?) audio recording quality.
It is simple enough for anyone to set up and use.
It is convenient to use for remote meetings, video recordings, etc.
It feels quite sturdy.
It is relatively affordable (compared to other audio equipment).
Please note: I am not an expert in audio equipment, and this article is not sponsored by any company. I simply hope that someone can benefit from the things I learned (and possibly save a few bucks) if they want to improve their own recording game!
Happy Global Testers Day! For 2021, QA Touch is celebrating with webinars, games, competitions, blogs, and videos. I participated by sharing an “upside-down” story from years ago when I accidentally wiped out all of NetApp’s continuous integration testing. Please watch my story below. I hope you find it both insightful and entertaining!
On April 22, 2021, I delivered a talk entitled “Managing the Test Data Nightmare” at SauceCon 2021. SauceCon is Sauce Labs’ annual conference for the testing community. Due to the COVID-19 pandemic, the conference was virtual, but I still felt a bit of that exciting conference buzz.
My talk covers the topic of test data, which can be a nightmare to handle. Data must be prepped in advance, loaded before testing, and cleaned up afterwards. Sometimes, teams don’t have much control over the data in their systems under test—it’s just dropped in, and it can change arbitrarily. Hard-coding values into tests that reference system tests can make the tests brittle, especially when running tests in different environments.
In this talk, I covered strategies for managing each type of test data: test case variations, test control inputs, config metadata, and product state. I also covered how to “discover” test data instead of hard-coding it, how to pass inputs into automation (including secrets like passwords), and how to manage data in the system. After watching this talk, you can wake up from the nightmare and handle test data cleanly and efficiently like a pro!
Here are some other articles I wrote about test data:
In February 2021, Matthew Weeks interviewed me for the Work in Programming podcast. Matthew asked all sorts of questions about my story – how I got into programming, what I learned at different companies, and why I started blogging and speaking. I greatly enjoyed our conversation, so much so that it lasted an hour and a half!
If you’re interested to hear how my career has gone from high school to the present day, please give it a listen. There are some juicy anecdotes along the way. The link is below. Many thanks to Matthew for hosting and editing the interview. Be sure to listed to other Work in Programming interviews, too!
Back in 2011, I was a recent college grad working at IBM as a “performance engineer” for z/OS mainframe software. Now, I didn’t know anything about mainframes, but I was thankful to have a job on the heels of the Great Recession.
At the time, IBM had recently released the Jazz platform with Rational Team Concert (RTC), a collaborative project management tool geared towards Agile software development. Teams company-wide started adopting RTC whether they wanted it or not. My team was no different: we created a team project in RTC and started writing work items in it. In my opinion, RTC was decent. It was very customizable, and its aesthetics and user experience were better than other tools at the time.
One day, I made a typo while trying to assign a work item to myself. When typing a name into the “owner” field, RTC would show a list of names from which to choose. For whatever reason, the list included all IBM employees, not just members from my team. IBM had nearly 400,000 employees worldwide at the time. I accidentally selected someone else with a similar name to mine. Blissfully unaware of my mistake, I proceeded to save the work item and start doing the actual work for it.
About a day later, I received a nastygram from another IBMer named Andrea Knight, demanding to know why I assigned her this work item in RTC. I had never met this person before, and she certainly wasn’t on my team. (To be honest, I don’t remember exactly what her name was, but for the sake of the story, we can call her Andrea.) At first, I felt perplexed. Then, once I read her message, I quickly realized that I must have accidentally listed her as the owner of the work item. I immediately corrected the mistake and humbly replied with an apology for my typo. No big deal, right?
Well, Andrea replied to my brief apology later that day to inform me that she was NOT responsible for that work item because she had NEVER seen it before and that she would NOT do any work for it.
I was quite taken back by her response.
I let it go, but I couldn’t help but wonder why she would answer that way. Perhaps she was having a bad day? Perhaps her manager scrutinized all work items bearing her name? Perhaps the culture in her part of the company was toxic? Was my mistake that bad?
Even though this incident was small, it taught me one important lesson early in my career: a little bit of grace goes a long way. Poor reactions create awkward situations, hurt feelings, and wasted time. If we make a mistake, we should fix it and apologize. If someone else makes a mistake, we should strive to be gracious instead of unpleasant. I try to practice this myself, though, sometimes, I fail.
Mentoring is important in any field, but it’s especially critical for software testing. I’ve been blessed with good mentors throughout my life, and I’ve also been honored to serve as a mentor for other software testers. In this article, I’ll explain what mentoring is and how to practice it within the context of software testing.
What is Mentoring?
Mentoring is a one-on-one relationship in which the experienced guides the inexperienced.
It is explicit in that the two individuals formally agree to the relationship.
It is intentional in that both individuals want to participate.
It is long-term in that the relationship is ongoing.
It is purposeful in that the relationship has a clear goal or development objective.
It is meaningful in that growth happens for both individuals.
Mentoring is more than merely answering questions or doing code reviews. It is an intentional relationship for learning and growth.
Why Software Testing Mentoring Matters
Software testing is a specialty within software engineering. People enter software testing roles in various ways, like these:
A new college graduate lands their first job as a QA engineer.
A 20-year manual tester transitions into an automation role.
A developer assumes more testing responsibilities for their team.
A coding bootcamp graduate decides to change career.
There’s no single path to entering software testing. Personally, I graduated college with a Computer Science degree and found my way into testing through internships.
Unfortunately, there’s also no “universal” training program for software testing. Universities don’t offer programs in software testing – at best, they introduce unit test frameworks and bug report formats. Most coding bootcamps focus on Web development or data science. Certifications like ISTQB can feel arcane and antiquated (and, to be honest, I don’t hold any myself).
The best ways we have for self-training are communities, conferences, and online resources. For example, I’m a member of my local testing community, the Triangle Software Quality Association (TSQA). TSQA hosts meetups monthly and a conference every other year in North Carolina. Through these events, TSQA welcomes everyone interested in software testing to learn, share, and network. I also recommend free courses from Test Automation University, and I frequently share blogs and articles from other software testing leaders.
Nevertheless, while these resources are deeply valuable, they can be overwhelming for a newbie who literally does not know where to begin. An experienced mentor provides guidance. They can introduce a newcomer to communities and events. They can recommend specific resources and answer questions in a safe space. Mentors can also provide encouragement, motivation, and accountability – things that online resources cannot provide.
How to Do Mentoring
I’ve had the pleasure of mentoring multiple individuals throughout my career. I mentor no more than a few individuals at a time so that I can give each mentee the attention they deserve. Mentoring relationships typically start in one of these ways:
Someone asks me to be their mentor.
A manager or team leader arranges a mentoring relationship.
As a team leader, I initiate a mentoring relationship with a new team member (because that’s a team leader’s job).
Almost all of my mentoring relationships have existed within company walls. Mentoring becomes one of my job responsibilities. Personally, I would recommend forming mentoring relationships within company walls so that both individuals can dedicate time, availability, and shared knowledge to each other. However, that may not always be possible (if management does not prioritize professional development) or beneficial (if the work environment is toxic).
From the start, I like to be explicit about the mentoring relationship with the mentee. I learn what they want to get out of mentoring. I give them the top priority of my time and attention, but I also expect them to reciprocate. I don’t enter mentoring relationships if the other person doesn’t want one.
Then, I create what I call a “growth plan” for the mentee. The growth plan is a tailored training program for the mentee to accomplish their learning objectives. I set a schedule with the following types of activities:
One-on-one or small-group teaching sessions
The best format for making big points that stick
Gives individual care and attention to the mentee
Provides a safe space for questions
Helpful for independently learning specific topics
May be blogs, articles, or documentation
Allows the mentee to complete it at their own pace
However, may not be 100% pertinent to the learning objectives
Pair programming or code review sessions
Hands-on time for mentor and mentee to work together
Allows learning by example and by osmosis
However, can be mentally draining, so use sparingly
Independent work items
Real, actual work items that the team must complete
Makes the mentee feel like they are making valuable contributions even while still learning
“Practice makes perfect”
These activities should be structured to fit all learning styles and build upon each other. For example, if I am mentoring someone about how to do Behavior-Driven Development, I would probably schedule the following activities:
A small group activity for doing Example Mapping on a new story
A work item to write Gherkin scenarios for that mapped story
A review session for those scenarios
A “BDD test frameworks” deep dive session with me
A work item to automate the Gherkin scenarios they wrote
A review session for those automated tests
Another work item for writing and automating a new round of tests
Any learning objective can be mapped to a growth plan like this. Make sure each step is reasonable, well-defined, and builds upon the previous steps.
I would like to give one warning about mentoring for test automation. If a mentee wants to learn test automation, then they must first learn programming. Historically, software testing was a manual process, and most testers didn’t need to know how to code. Now, automation is indispensable for organizations that want to move fast without breaking things. Most software testing jobs require some level of automation skills. Many employers are even forcing their manual testers to pick up automation. However, good automation skills are rooted in good programming skills. Someone can’t learn “just enough Java” and then expect to be a successful automation engineer – they must effectively first become a developer.
Characteristics of Good Mentoring
Mentoring requires both individuals to commit time and effort to the relationship.
To be a good mentor:
Be helpful – provide valuable guidance that the mentee needs
Be prepared – know what you should know, and be ready to share it
Be approachable – never be “too busy” to talk
Be humble – reveal your limits, and admit what you don’t know
Be patient – newbies can be slow
To be a good mentee:
Seek long-term growth, not just answers to today’s questions
Come prepared in mind and materials
Ask thoughtful questions and record the answers
Practice what you learn
Express appreciation for your mentor – it’s often a thankless job
Take Your Time
Mentoring may take a lot of time, but good mentoring bears good fruit. Mentees will produce higher-quality work. They’ll get things done faster. They’ll also have more confidence in themselves. Mentors themselves will feel a higher satisfaction in their own work, too. The whole team wins.
The alternative would waste a lot more time. Without good mentoring, newcomers will be forced to sink or swim. They won’t be able to finish tasks as quickly, and their work will more likely have problems. They will feel stressed and doubtful, too. Forcing people to tough things out is a very inefficient learning process, and it can also devolve into forms of hazing in unhealthy work environments. Anytime someone says there isn’t enough time for mentoring, I would reply by saying there’s even less time for fixing poor-quality work. In the case of software testing, the lack of mentoring could cause bugs to escape to production!
I encourage leaders, managers, and senior engineers to make mentoring happen as part of their job responsibilities. Dedicate time for it. Facilitate it. Normalize it. Be intentional. Furthermore, I encourage leaders to be force multipliers: mentor others to mentor others. Time is always tight, so make the most of it.
I hope this article is helpful! Do you have any thoughts, advice, or questions about mentoring, specifically in the field of software testing? I’d love to hear them, so drop a comment below.
I wrote this article as a follow-up to an “Ask Me Anything” session on July 15, 2020 with Tristan Lombard and the Testim Community. Tristan published the full AMA transcript in a Medium article. Many thanks to them for the opportunity!
PyOhio 2019 was one of my favorite conferences, ever. It was my ninth Python conference and my second PyOhio conference. There were so many good things that happened in such short time that, even three weeks later, I’m still processing everything. Here are my reflections on this outstanding conference.
PyOhio 2019 was held in Columbus, Ohio at the Ohio State Union. I really wanted to go because PyOhio 2018 was such a good time, and I started asking my friends in North Carolina if anyone wanted to join me. My friends Rick and Justin all emphatically replied YES! To make traveling more fun, we decided to turn it into a road trip! We dubbed ourselves the “PyCarolinas delegation”, piled into my Chrysler 300, and made the 8-hour drive in good time. Our friend Greg also joined us at PyOhio, though he traveled separately with his wife.
This was the first time I ever did a road trip to a conference. I’m so glad we did it. I felt like I got to spend great quality time with my friends. Many parts of the drive were quite scenic. We also discovered a Beef Jerky Outlet!
At PyOhio 2019, I delivered the holy trifecta of speaking opportunities: a talk, a tutorial, and a lightning talk. I felt both honored and humbled to be chosen for all three.
My talk was entitled Surviving Without Python. I talked about how we can use Python’s principles, projects, and people to inspire us even when we don’t use Python to solve our problems:
My tutorial was entitled Hands-On Web UI Testing. Python’s popularity continues to rise, and many people use it for testing. In my tutorial, I showed how you can develop a simple yet powerful solution with Python, pytest, and Selenium WebDriver to automate Web UI tests. The tutorial project in GitHub contains the code, instructions, and slides.
My lightning talk was announcing PyCarolinas 2020. My friend Calvin and I are teaming up to bring PyCarolinas back! We are targeting June 2020 in Raleigh, NC. Please help us make it happen!
There were so many great talks at PyOhio. Here were a few highlights.
Sprints are a Python conference event in which people work together on open-source projects. Conferences are the perfect time to have sprints because people are both co-located and excited. PyOhio 2019 was actually the first time I attended sprints. There were sprints on both Friday and Saturday nights. Accenture graciously hosted both sprints in their swanky office and provided refreshments.
I went to the sprints both nights with the honest intention to work on stuff. However, I spent the whole time socializing with friends. It was nevertheless time well spent! Many of us went to Jeni’s Splendid Ice Creams after the final sprint, too.
The PyOhio 2019 logo was lit! I joked that I was going to the conference just to get that logo sticker and t-shirt. Some other cool takeaways were the Numerator puzzles and the JP Morgan Chase puzzle blocks.
My sticker game is strong:
My backpack was also a hit!
Food and Drink
I had some good eats while in Columbus. My friend Mason recommended Raising Cane’s, which turned out to be awesome! So many people followed us there, too.
I also hopped an electric scooter to get bubble tea. Those scooters are so much fun. I hadn’t ridden one since PyTexas 2019! (Or maybe PyCon 2019; I don’t remember precisely.)
To relive PyOhio 2018 memories, I went to Eden Burger for a Vegan brunch on Sunday morning with friends! It was delicious and nutritious.
Our friend Greg recommended we visit Brewdog, a renowned Scottish craft brewery with a huge site on the outskirts of Columbus. We took the tour with the “beer school” course, and we stayed for a delicious dinner afterwards. So good, so very good. It was the best way to end the conference!
The best part about PyOhio 2019 was the time I spent with all my friends. I wish I could name everyone here, but there are just too many names. The Python community is the best. Conference friends are real friends. Also, for what it’s worth, they’ve given me the nickname “Pandy.”
My PyOhio 2019 experience can be summarized in one line:
Truth – I went all-in from leaving my house on Friday morning until returning Monday evening. The conference high is very real. My hope is that I’ll get to attend more great conferences like this, and also that I’ll be able to help make PyCarolinas as good as PyOhio!