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!
Speaking at conferences is a great way for tech professionals to meet others, share their stuff, and travel to new places. It’s hard but rewarding work for speakers. I’ve been fortunate to have many speaking opportunities in the past few years. However, there is a hot-button issue in the speakership world: the “pay-to-speak” controversy. I’d like to offer my perspective on the matter.
What is Pay-To-Speak?
Have you ever wondered how speaking at conferences works? Conference organizers announce a “call-for-proposals” several weeks before the conference date. Potential speakers submit their proposals for talks, which often include an elevator pitch, an outline with time estimates, and personal information. Organizers will then invite the speakers with the best proposals to the conference.
Now, here’s the big question: Who covers the speaker’s costs? Conference travel isn’t free. Speakers will need transportation, a hotel room, meals, and other incidentals. Many speakers will also need to take time off from their day jobs to attend the conference. Some conferences will generously pay for their speakers’ travel-related expenses, either through reimbursements or a stipend. However, others are “pay-to-speak,” for which conferences do not cover any speaker travel costs. Speakers must ask their employers to sponsor them or, in the worst case, pay out of pocket. (For clarity, pay-to-speak does not mean that a speaker must pay the conference a fee for the privilege of speaking, at least not that I have seen.)
The pay-to-speak model can cause serious problems:
It can devalue the hard work speakers do to deliver captivating talks. Speakers essentially work for someone else without getting paid. They take several hours away from regular work and family time.
It can cause tension between speakers and their employers. A speaker will probably ask their manager to give both time off and travel reimbursement. That can be a tough conversation. It might involve office politics. Not every employer is thrilled to send their people to expensive conferences.
It can put a financial burden on speakers. If an employer won’t cover costs, then the speaker must pay out of pocket, which could force the speaker to make hard sacrifices.
Less-privileged speakers may need to decline invitations because they cannot afford to pay the travel costs themselves. That’s tragic and unfair.
These are real problems. As a result, many popular speakers boycott pay-to-speak conferences. Some conferences proudly advertise that they are not pay-to-speak. I won’t copy any hot tweets here, but just follow the #PayToSpeak hashtag on Twitter to see some. There are some strong words out there.
An Alternative Perspective
Personally, I love conferences that can cover my travel costs when I’m a speaker. It certainly eases my financial burden. I also think that for-profit conferences should not only cover speaker travel costs but also pay speakers for their presentations. However, the pay-to-speak model is not inherently evil. There are situations for which pay-to-speak is, in my opinion, a good model for conferences. Look no further than the Python conferences.
Python is one of the world’s most popular programming languages right now. Python is unique among programming languages because it is developed and supported entirely by the community. It is free, open-source software. The Python core developers, the people who “make” the language, are all volunteers. The Python Software Foundation (PSF) is a non-profit organization that holds the intellectual rights to Python. Python does not have a company behind it like Java (Oracle), C# (Microsoft), Go (Google), or Swift (Apple). Companies certainly support Python development and events, and a few individuals are employed by such efforts, but Python is nevertheless an independent, not-for-profit endeavor.
The best way to engage the Python community is through Python conferences. The biggest one is PyCon, held annually at different locations in North America. There are several other PyCons throughout the world, and the United States has many “regional” Python conferences like PyOhio and PyGotham. I’ve attended quite a few in recent years.
All the Python conferences I know are pay-to-speak. However, they are also non-profit. There’s no company making money off the conferences. The organizers are volunteers. Everything is financed through ticket sales, corporate sponsorships, and donations. The PSF also gives support. PyCon’s very tagline is, “By the community, for the community.”
Furthermore, Python conferences deliberately seek to keep registration prices low so that the conferences can be accessible to as many people as possible. That means costs must be kept low. Any conference needs money to run – lots of money. Speaker travel is a huge financial cost for a conference. Do the math: if a conference has 50 speakers, and each speaker needs about $2,000 for travel expenses, then the total cost is about $100,000! That’s enough to make any volunteer organizer lose sleep. Choosing a pay-to-speak model helps keep costs low.
As a result, registration prices for Python conferences are very affordable. Below are individual rates for 2019 conferences:
PyCon 2019: $400
DjangoCon 2019: $595
PyColorado 2019: $125
PyGotham 2019: $150
PyOhio 2019: free
Alternatively, there are for-profit conferences that charge thousands of dollars for their tickets.
Many Python conferences also offer financial aid grants to speakers and attendees who need assistance covering travel and registration costs. If an accepted speaker cannot afford to come on their own, they can probably get assistance. Many Python conferences also stagger ticket costs between educational, individual, and corporate tiers so that individuals paying out of pocket have less burden that those whose companies cover their costs. Simply put, if you want to go to a Python conference near you, then cost should not be a barrier.
Personally, I have no problem with Python’s pay-to-speak conferences. When I speak at Python conferences, I treat it as my service to the community – much like how others contribute code to open-source projects. The Python community has given much more to me than I could pay back, so instead, I’m happy to pay it forward. And the ones who “profit” from Python conferences are ultimately the ones who attend.
The pay-to-speak controversy is a complex issue. No side offers a perfect solution. What’s right or wrong is not the pay-to-speak model itself but rather the intention behind the decision to be pay-to-speak. If a conference seeks to profit from a speaker’s labor, then the speaker should be paid as with any business transaction. However, if a conference is truly a non-profit endeavor with benevolent intentions and a genuine inclusion strategy, then pay-to-speak might be okay.
When I was a kid, I was an enthusiastic Boy Scout. And every year, I looked forward to summer camp. For one full week, I would have a mini-adventure in the woods with my friends while earning new ranks and developing new skills. Summer camp was the highlight of every summer. As an adult, this is exactly how I feel about PyCon.
PyCon 2019 was my second time at PyCon. While I doubt any conference will ever have the same impact on me as my first PyCon, my second one was nevertheless every bit as good. I had a phenomenal experience. As always, I like to capture my reflections in an article so that I never forget the wonderful times I had. Here’s my story.
PyCon 2018 was a career-changing experience for me. I felt it at the time, and I can validate it now a year later. PyCon 2018 was my first serious engagement with the Python community. PyCon 2018 inspired me to speak at other conferences. PyCon 2018 introduced me to friends I still have today. As soon as PyCon 2018 ended, I knew that I needed to return for PyCon 2019.
Between 2018 and 2019, PrecisionLender (my employer) started doing much more Python work, especially in our data analytics division. I got approval from my manager to go to PyCon, but I also knew that others in the data division would benefit from PyCon as well. When I suggested the idea to the VP, he replied with one line: “Let’s do this thing!” With his blessing, I convinced four other PrecisionLender-ers to join me: Adam, Henry, Joe, and Raff.
I’m so thankful PrecisionLender approved our trips. Going with other friends from my company boosted not only my excitement for the conference but also my desire to learn new things. I’m proud to represent a company that supports its employees so well.
Good conferences are good but exhausting. They cram hundreds of adrenalized people into back-to-back activities requiring deep focus for hours at a time and for consecutive days. Amidst the mania, it is crucial to pace oneself. My friend Kojo sums this up perfectly in what he calls the “self care sprint.” It’s okay to step back to catch your breath. It’s vital to one’s mental health to take breaks, rest, and recover, especially at conferences as intense as PyCon.
Heeding Kojo’s advice, I took a #SelfCareSprint on the day before PyCon tutorials began. How so? I spent my afternoon at the Cleveland Museum of Art, which exhibits pieces from around the world dating from ancient times through the present day. Make no mistake: the Cleveland Museum of Art is world-class. In addition to their permanent collections, they had a special exhibit on Shinto artifacts from Japan. I barely had enough time to walk through all the galleries. What I did see impressed me, inspired me, and challenged me. Some pieces even spoke deeply to my soul.
The dichotomy of art and technology balance each other. Exploring pieces of art and the viewpoints they represent helped me center myself. I could clear my mind in preparation for the conference. I gained rest and recovery. I am human, after all.
PyCon 2019 hosted two days of tutorials before the main conference. Whereas talks are thirty minutes long and open to anyone, tutorials are three-hour sessions that require preregistration for limited seats. Tutorials are meant for hand-on learning with expert instructors. I had never attended tutorials at a conference before, and so this time, I wanted to try.
My first tutorial was Writing About Python (Even When You Hate Writing) by Thursday Bram. Since I do lots of blogging (and I ultimately want to write a book), I wanted to get first-hand advice on technical writing in the Python ecosystem. Thursday gave great advice on writing techniques and gotchas. The most valuable takeaway was her proofreading checklist. Her tutorial also inspired me to do something cool later in the conference. (Keep reading!)
My second tutorial was To trust or test? Automated testing of scientific projects with pytest. Unfortunately, this tutorial wasn’t right for me. I thought it would be about testing within data science, but it turned out to be a basic walkthrough of pytest. I didn’t learn any new material. What I did learn, though, was that I should be pickier with tutorials – I had to pay in advance, and I couldn’t just walk out to another talk.
My third tutorial was Escape from auto-manual testing with Hypothesis! by Zac Hatfield-Dodds. Hypothesis, a property-based testing tool, is hot right now. I first learned about it at the previous year’s PyCon, and I always wanted to learn more. Zac provided not only helpful lectures but a rigorous set of examples for us to complete. Hypothesis also works seamlessly with pytest. Zac made be a believer: Hypothesis is awesome! I need to spend more time learning it on my own.
As always, the talks were on point. I didn’t attend as many talks this year because I was too busy in the “hallway track,” but there were quite a few noteworthy ones that I attended.
In Don’t be a robot, build the bot, Mariatta showed how she and the Python core developers automated their GitHub workflow with the help of useful bots. It was cool to see how mundane processes can be automated away and how much more efficient teams can become.
In Break the Cycle: Three excellent Python tools to automate repetitive tasks, Thea Flowers showed how to use tox, nox, and Invoke to automate just about anything in Python. I’ll definitely refer back to this talk for testing.
In ¡Escuincla babosa!: Creating a telenovela script in three Python deep learning frameworks, Lorena Mesa showed us how serious machine learning can also be used for fun projects. Although the telenovela script she generated was short and humorous, it clearly proved that ML can get the job done.
In Scraping a Million Pokemon Battles: Distributed Systems By Example, Duy Nguyen showed how he scraped data from competitive Pokémon battles to level the playing field for new players. In the process, he developed a pretty slick distributed systems setup!
In Shipping your first Python package and automating future publishing, Chris Wilcox showed best practices on building and releasing Python packages. This talk was well-timed for me – I’ll definitely use this info for a current pet project of mine.
Dependency hell: a library author’s guide by Yanhui Li and Brian Quinlan will also be a great resource when considering dependencies for packages.
In to GIL or not to GIL: the Future of Multi-Core (C)Python, Eric Snow showed his thoughts for how to fix problems with the GIL and true multi-core processing.
In The Perils of Inheritance: Why We Should Prefer Composition, Ariel Ortiz made clear the nasty side effects inheritance can have and how composition is often a much better approach. The talk was fairly introductory, but I couldn’t agree more.
The expo hall was full of companies and organizations. The swankiest booths this year were:
Capital One – the Guido portrait and puzzle and the Zen of Python wall
Jetbrains – content developer tables for PyBites, Real Python, and others
Microsoft – four interactive Azure stations + active lab tables
However, my favorite company in the expo hall, hands down, was The Pokémon Company International. Their table was small and easily overlooked, but every time I passed by, it was packed. Everyone loves Pokémon! I got to meet a few of their engineers and managers. Apparently, they do much of their backend in Python. They’re also growing quite a lot. They were raffling off a giant Pikachu, and one of the engineers even developed a Google Home app that would make Pikachu respond whenever someone spoke to it! It was so charming to see them there. I’m glad that things are going well for Pokémon.
If you don’t overfill your swag bag, then you’re doing PyCon wrong. This year’s haul was as good as last year’s. I walked away with:
A deck of cards with the Zen of Python from Capital One
An artistic deck of playing cards from Heroku
16 packs of Pokémon cards
A JetBrains yo-yo
A few pairs of sunglasses
Water bottles from DoorDash, Wayfair, and Citadel
A guide to building Slack apps
The best t-shirt award goes to Microsoft for their Visual Studio Code shirt, with honorable mentions for LinkedIn and SmartBear. I also shared a good amount of this swag with my coworkers at PrecisionLender.
Cleveland (and greater Ohio) are renowned for craft breweries. Every time I return to Ohio, I’m always delighted by the beers I discover. I spent many lunches and dinners with a flight set on the side. Here’s where I went:
Hofbräuhaus Cleveland, twice! (I even bought the souvenir Maßkrug!)
Masthead Brewing Company
Noble Beast Brewing Company
Southern Tier Brewing Company
Great Lakes Brewing Company
The best was the Lichtenhainer from Noble Beast – a sour that tasted like a ham sandwich on sourdough. The worst was the “shampoo beer” from Southern Tier – did they forget to rinse the lines after cleaning them?
Back at PyCon 2018, I met an Aussie by the name of Julian Sequeira, co-founder of PyBites. We hit it off. In fact, meeting Julian is one of the reasons why I continue to engage the Python community today. Through Julian, I met other friends like Jason Wattier, Brian Okken, Cristian Medina, and many others. Leading up to PyCon 2019, Julian organized a BIG dinner at Great Lakes Brewing Company for a bunch of Python content developers: PyBites, Real Python, Python Bytes, Test & Code, tryexceptpass, and Automation Panda (me!). Not only was it a time of sweet reunion, but I finally got to meet others like Bob Belderbos, Michael Kennedy, and David Amos in person. One of the best parts of the dinner was when a few of us chose to walk back to the hotels over the bridge instead of calling taxis. The night was cold, but the experience was worth every second.
Sadly, I did not get to deliver a full talk or tutorial at PyCon 2019. Believe me, I submitted. But that didn’t stop me from trying – there’s always one more chance with lightning talks! One exercise during the Writing About Python tutorial was to pitch a lightning talk idea. At the time, I struggled to come up with a good topic. I first considered something about testing or being a tester, but those ideas just didn’t feel right. Then, I struck gold: what about giving helpful tips for blogging, based on my experiences with Automation Panda?
I put my idea on the call-for-lightning-talk-proposals on Saturday morning: “3 Quick Tips for Software Blogging.” When I didn’t receive any notification by lunchtime, I thought my pitch had been rejected. Then, while chilling in the quiet room at 3pm, I received an email: “Congrats! You’re giving your lightning talk today at 5pm!” Excitement, then panic, took over. I threw some slides together, rehearsed them in my head, and marched myself to the main auditorium. My lightning talk was second in queue, and I delivered it like a BOSS!
Ever since my first PyCon, I’ve dreamed about having a Python conference in the Carolinas. There was a PyCarolinas 2012 and a PyData Carolinas 2016, but both were one-hit wonders. My dream remained in my back pocket until PyCon 2019.
While meandering the expo hall on Friday, I ran into Tim Hopper and Brian Corbin, two friends who were also from the Carolinas. We talked about lots of things, but one point of discussion was about relaunching PyCarolinas. Later, Dustin Ingram, chair of PyTexas, tweeted that there would be a conference organizer’s open space on Saturday. I asked if I could join because of my PyCarolinas dreams, and he said absolutely yes. Brian and I both attended, made connections, and got tons of helpful information.
Dustin then asked me if I’d like to include a slide for PyCarolinas in the “regional conference parade” on Sunday morning after the lightning talks. Heck yeah! PyCarolinas was the very last slide as a call-to-action: We have a dream; come help us make it real!
At 10am on Sunday, I held an open space to talk about (re)launching PyCarolinas. 26 people came! We got everyone’s info, created a Slack room, and started throwing around ideas. In the week after the conference, over a hundred people signed up for our Slack room. The excitement is palpable. Our goal is to host PyCarolinas in summer of 2020 for 150+ people. I’m so thankful I got the opportunity to be the spark that lit this wildfire, on such a big stage.
Together with my blog, I use my Twitter handle @AutomationPanda for professional development. Twitter is especially helpful during conferences for communicating with friends and sharing experiences. During PyCon 2019, I crossed a big milestone: I hit over 1000 followers! That was cool.
I also made my first viral tweet, thanks to a sticker from Facebook:
If you read these reflections down this far, thank you. Seriously, I mean it.
The best part about PyCon 2019 for me was the time I spent with my friends.
PyCon 2019 was a high point for friendships. Everyone I knew was there. I couldn’t walk for 10 minutes around the convention center without running into someone I knew. I feel like I’m truly part of the Python community now. Here were just a few highlights:
Going there with my PL team: Adam, Henry, Joe, and Raff.
German dinner and souvenir Maßkrugs with Adam at Hofbräuhaus.
“Shampoo” beer with Joe and Adam at Southern Tier.
Snagging Pokémon cards on opening night with Mason Egger, and then running into Jason Wattier on the way.
Ramen dinner and Hilton rooftop drinks with the PL crew plus Mason.
Impromptu lunch with Adrienne so she could share the awesome things she’s accomplishing.
PyCon Canada 2018 was my fourth and final Python conference of 2018. I proposed a talk on a whim after seeing the CFP on Twitter. What the heck, why not? It couldn’t hurt to try. Much to my surprise (and delight), I was accepted to speak! So, up to the Great White North I went for the first time since childhood.
#PyConCA2018 took place in Toronto, Ontario from November 10-13 at the Chestnut Residence downtown. I attended the conference (Nov 10-11) but skipped out on the sprints (Nov 12-13). It looked like about 400-500 people attended the conference, but I don’t know the exact count. A few vendors had tables with swag, but the talks were clearly the main focus of the conference.
PyConCA offered three tracks for talks plus a tutorials track. There were two time slot lengths for talks: 10 minutes and 30 minutes. I had not attended a conference with short 10-minute talks before, but they turned out to be a great way to cover a broader range of topics in a short amount of time. The tutorials were long-running sessions for which anyone could register at no additional charge, but they each had a limited number of seats. (I regret not signing up in advance for the Kubernetes tutorial.) There were also four decent keynote addresses.
I spent a lot of time reworking the slides, writing new example code, and rehearsing my words before the talk. And I felt great when I presented it: without any script, I hit all the major points without skipping a beat and ended right on time. I felt my passion flow through me as I spoke. This tweet pretty much summed up my feelings:
Meeting people is one of my favorite parts of Python conferences. Everyone is friendly. Everyone will chat with you. Everyone will get excited about whatever makes you excited. This time around, I ended up in a posse with a few other guys who mostly attended the same talks and also sat at the same lunch table. I hope our paths cross again. I also got to meet Elaine Wong, the conference chair.
After the Conference
I was on my own for both evenings after the conference talks. My Airbnb rental was just two blocks away in Chinatown, so I could walk to and from the conference center (in the bitter Toronto cold). On Saturday night, I ate a delicious dry hotpot of beef, lotus flowers, and wood ear mushrooms at the House of Gourmet, followed by a fancy bubble tea in a light-bulb-shaped glass across the street at Royaltea. On Sunday night, I treated myself to foot-and-body massage at Evergreen Beauty and Wellness. My therapist, who was from Beijing, helped me practice my Mandarin. Thereafter, I went to Sichuanren for an all-you-can-eat hotpot buffet: beef, pork, lamb, seafood, and veggies. It’s so much fun to visit a big city with a large Chinatown – it provides access to things I can’t always get at home. That US-to-Canadian-dollar exchange rate is quite favorable, too. The only challenges I faced were (a) no mobile phone service and (b) worrying if establishments would accept my credit/debit cards. The temps also hovered around freezing.
PyConCA was a strong finish for my 2018 conferences. I’m so thankful for my opportunity to speak, and I’m glad that I took the time to attend.
My favorite physical takeaway items of swag were:
My PyConCA sticker, now proudly displayed on my Macbook
My PyConCA t-shirt, which will soon appear in my rotation
My PyConCA “toque” (Canadian word for “knit winter cap with a pom-pom on top”)
My main inspirational takeaway from this conference could be summed up in one word: confidence. I feel much more confident in myself as a conference speaker after nailing my talk this fourth time. After listening to a number of talks, I also feel much more confident in my Python web development skills. Picking up Flask (which is on my todo list) should be doable. Finally, I feel capable of learning data science and AI with Python when the time comes. Many talks showed how machine learning can solve novel problems with straightforward tools and techniques.
That should conclude this panda’s round of conferences for the year. I look forward to what 2019 brings!
PyTexas 2019 was an incredible Python conference. It was held at the Central Library in Austin, Texas from April 13-14. I’m so glad I went. Even though this was my seventh Python conference, it was one of my favorites so far. Here’s a brief recap of my experiences.
Why I Went
I consider myself very fortunate to have been able to go to PyTexas 2019. After my talk proposals for PyCon 2019 were rejected, I saw this tweet from Dustin Ingram, the conference chair for PyTexas:
Thankfully, my talk was the very second talk of the conference. I could get it out of the way early so I could enjoy the rest of the conference without the nerves. And everyone always loves the pandas.
I also gave a Lightning Talk for the first time! I talked about the difference between unittest and pytest. My talk starts at 30:17, but be sure to listen to all of the talks.
I’d also like to thank my employer, PrecisionLender, for sponsoring my trip and enabling me to speak.
Talks are usually the main part of any conference. PyTexas 2019 was a single-track conference, meaning that everyone saw all of the talks. All talks were memorable for me, but I’ll write a separate post about the talks once all the recordings are posted. Here, I’ll cover other awesome things that happened.
My Recovery Day
Things had been very stressful for me in the first few months of 2019. I came to PyTexas essentially exhausted from life, and I needed a “Self Care Sprint” (as Kojo would say). So, that’s exactly what I did: I flew into Austin on Friday morning and spent the whole afternoon just being a low-key tourist. I ate a Texas-sized lunch at Stubb’s BBQ, viewed the artwork at Mexic-Arte Museum, walked along the Colorado River, and nearly fell asleep in the Central Library after perusing the stacks. That evening, I met up with other speakers at the Spider House for an informal pre-conference get-together. Even though I wasn’t “productive” by any professional definition, I felt thoroughly refreshed and ready for the excitement to come.
Austin has been invaded by electric scooters. They are on every street corner. There must be half a dozen different brands. Even Uber and Lyft have scooters for rent! Instead of hailing ride shares downtown, I just hopped the nearest Lime scooter. They go really fast, and they’re tons of fun!
The First After-Party
Literati Books generously hosted an after-party at Jo’s Coffee after the first day of the conference. I got to spend time with a bunch of cool people from the conference while enjoying sliders and craft beer. Carl even shared some of his jerky with us!
Other Testing Talks
I always get a rise out of testing talks at conferences. Python conferences always have a few but only a few. PyTexas had three. I think Kojo‘s tweets summed up my enthusiasm perfectly:
The Zen of Python Teams
Adrienne delivered one of the best keynote addresses I’ve ever attended. Seriously, go watch it. She talked about how the Zen of Python can be applied not only to code but also to teams. The best part was the “Easter egg” at the end. The Zen of Python famously leaves the 20th line blank so that we can make it for ourselves. Adrienne challenged us to come up with our own 20th point after handing out real Easter eggs to everyone in the audience! Mine? People matter.
I had never eaten at Whataburger before. This trip, that changed. William, Brian, and I hopped on those electric scooters and went to the Whataburger across the river for lunch on day 2. The patty melt was tasty, but the Dr. Pepper milkshake was out of this world! The views from the bridge were gorgeous as well.
The Second After-Party
After the conference ended, William, Aly, and I went to Mort Subite, a cool Belgian beer bar, to celebrate and unwind. Then, we rode electric scooters over to Baton Creole for a late-night dinner with Adrienne. We had some good food and even better discussions. It was the best way to end PyTexas!
PyTexas was the first conference where I felt like I fully belonged from day one. Every previous conference was a bit of a shot in the dark for me because I was still new to the Python community. PyTexas 2019 felt almost like a reunion. I strengthened existing friendships and made new ones: Adrienne, Kojo, Dustin, Ernest, Aly, William, Piper, Andy, Carl, Mason, Michael, Brian, and so many more. I also felt like I made a bigger impact at PyTexas than at other conferences because I genuinely felt like part of the community.
We should never take conferences (or any moments) for granted. Truly wonderful things happened at PyTexas. I felt creative. I felt inspired. I felt challenged by new ideas. I felt the itch to try new things. I left on a post-conference high and, surprisingly, I wasn’t particularly tired. The organizers did a phenomenal job running the conference smoothly and successfully. Seriously, hats off to them – many thanks for a job well done. As attendees, we should be grateful for all the hard work so many people did for the conference, and we should capitalize on what we take away from the conference.
Single-track and multi-track yield two very different conference experiences. PyTexas 2019 was my second single-track conference and my first one for a Python conference. Overall, I think the single-track format worked very well. Putting everyone on the same track in the same room builds a strong sense of camaraderie. It also gives speakers a much more prominent platform. However, multi-track provides more choices for attendees, and it gives more people the opportunity to speak. Both are good. I think it would be cool if future conferences do both: maybe one day for single-track and another day for multi-track.
I’m going to (attempt to) develop a new Python package. For a while, I’ve wanted to implement a particular testing pattern in a Pythonic way. My goal is to develop and release it to PyPI as an open-source package. I never had the time or clarity to do it until now. PyTexas gave me a huge boost, and I hope I can carry my vision through to delivery!
People matter. The Python community is a truly wonderful group. People come for the language and stay for the community – it’s true. PyTexas 2019 has challenged me to be a better person and to help people through software.
PyCaribbean was held in Santo Domingo, Dominican Republic from February 16-17, 2019. I was blessed with the opportunity to deliver not just one talk but two at the conference! Typically, I write lengthy chronological reflections of my conference experiences, but this time, I’m going to share my big takeaways.
Python has GREAT people.
Python is truly just as much about the community as it is about the language, and conferences are one of the best ways to become part of that community. Everyone at PyCaribbean was excited to learn, grow, and be inspired. Here’s a short list of Twitter handles for some of the awesome folks who made a direct impact on me at the conference:
There were many others, too. I felt like I really got to connect with these folks, not just meet them in passing.
The Dominican Republic has GREAT people.
First of all, many thanks to Leonardo Jimenez for organizing the conference! He did so much not only to bring together an excellent program of speakers and events, but he also got the support of the local software community and even the government in the DR.
PyCaribbean really showed the best of the software world in the DR. Everyone there was hungry to learn and share. I had no idea how vibrant the software industry was becoming there, too. There’s a bright future ahead.
Don’t wait to make proposals to conferences.
I consider myself especially fortunate to have attended PyCaribbean because I almost didn’t get to go. I submitted my talk proposals one night on a whim after seeing the PyCaribbean Twitter handle appear on my feed. After submitting two talks, my third one got blocked with a message saying submissions had been closed. Had I delayed a few minutes, I would have been too late!
Join the PSF.
The Python Software Foundation (PSF) is a 501(c)(3) non-profit corporation that holds the intellectual property rights behind the Python programming language.
The PSF does awesome things for the community, such as running PyCon. Anyone can become a member, too! There are different membership classes for varying levels of involvement. Lorena Mesa, one of the PSF Directors, encouraged me to join during the conference. If you care about Python, then I encourage you to join as well!
Beach trips are fun.
The day after the conference ended, a bunch of us (mostly speakers) took a day trip to Be Live Collection Canoa at Bayahibe. This was my first time at an all-inclusive beach resort. The water was a clear light blue, and the sand was white. Mixed drinks and Presidente beers were unlimited – you could even order them from a bar in the swimming pool! The buffet lunch was also on point. Plus, the trip offered the perfect chance to get to know the others on a deeper level. I almost didn’t get to go, but thankfully Delta rearranged my flights due to weather delays and gave me an extra day in the DR. I needed that day at the beach to just be me, but relaxed. #WorthIt
Music brings people together.
One of the conference highlights was the electric violin performance on day 2. I don’t know the name of the musician, but he shredded it! He played “Wake Me Up” by Avicii, “Uptown Funk” by Bruno Mars, and “Corazon Espinado” by Santana. As I sat in the auditorium listening with the others, I just thought to myself, “This is really nice. This is a once-in-a-life performance for incredible renditions of these three awesome songs.” Everyone else there seemed to agree with me.
Passionfruit is delicious.
I ate passionfruit for the first time in my life in the DR. It was delicious. The edible flesh of the fruit is basically a gooey collection of black seeds in a yellow mucus. It tastes tart but slightly sweet. I normally don’t eat breakfast, but I devoured about four halves on the morning I first discovered them. They had them at the beach resort buffet, too!
I need to stick up for myself.
During my trip, it was very obvious that I was a tourist – a white American who spoke no Spanish and wandered around just to look at things. Unfortunately, because of that, some people tried to take advantage of me. I was clearly overcharged for my souvenirs, even after attempting to haggle. A guard at Independence Park took my phone to take pictures of me and then demanded money. On my return flight, a guy sat in my seat on the plane and refused to yield it to me.
These experiences really frustrated me. I’ve always been somewhat shy in social circumstances, and that leaves me vulnerable to others who would take advantage of me. Reflecting on how I handled these situations has made me determined to be more assertive. I won’t become a jerk, but I don’t need to be afraid to stick up for myself. I should use my inner strength and discernment instead of folding.
The world is a fallen place.
One thing truly broke my heart during my trip: I’m 99% sure I witnessed prostitution on multiple occasions. I won’t go into details, but it was shocking to me. Call me naïve. Let’s work to make a better world where this sort of thing doesn’t need to happen.
I know so little.
My PyCaribbean trip was challenging but rewarding. It was my first time visiting the Caribbean and Latin America. Not only did I gain some software experience, but I also gained some life experience. I’m thankful I got to go and that all the details fell perfectly into place. Hopefully, I’ll get to return to learn even more!
I am a Software Engineer in Test (SET). Many people don’t know quite what that means, though. Developers frequently refer to me as a “tester” or “QA,” and a former director once thought I did DevOps. While my work covers these areas, they aren’t the main focus. Let’s clarify what it means to be a SET.
What is a Software Engineer in Test?
A “Software Engineer in Test” (SET) builds solutions to testing problems. Those problems could include slow feedback, flaky tests, costly runs, poor product quality, lack of communication during development, and more. In some circles, the role is called “Software Development Engineer in Test” (SDET).
Frequently, SETs focus on developing test automation solutions for running tests quickly and repeatedly. Test automation is a software product, after all. Just as front-end developers write web pages and back-end developers write microservices, SETs write automated tests. The same practices and coding skills apply. I frequently say that a Software Engineer in Test must have the heart of a developer.
However, a SET is more than just an automation engineer. SETs also look holistically at quality through the software development lifecycle. They build systems for fast feedback, such as Continuous Integration pipelines and reports. They work with developers and product owners to develop good product designs. They provide tools and frameworks to empower others to cover any testing needs. At times, they may also jump in to help a team with manual and exploratory testing.
So they just write test scripts?
No. Never say this to a SET. Test automation involves much more than just “writing test scripts.” A serious testing solution requires serious design and effort. The top-level automation of a test case is usually just a small piece. SETs are responsible for:
Collaborating with developers and product owners
Contributing to planning and design
Reviewing product code
Formulating test scenarios
Developing test automation frameworks
Automating test scenarios using the frameworks
Knowing and using design patterns where appropriate
Setting up dashboards for reporting test results in real time
Teaching others good quality and testing practices
Developing tools to assist manual and exploratory testing
Saying that testing is “just scripting” belittles the role of the SET and underestimates the workload it requires.
How did this role start?
Software “tester” and “QA” roles have existed for decades, but the SET role first became distinct in the 2000s when large-scale test automation became both feasible and necessary. According to Wikipedia, Microsoft coined the title “Software Developer Engineer in Test” (SDET) in 2005, and others like Amazon and Apple quickly adopted it. Google coined the name “Software Engineer in Test” for the same type of role. I personally prefer the SET title over the SDET title simply because it is more concise.
How is it different from “QA” or “testing” roles?
To me, the SET role is distinct from the traditional “QA” or “testing” role. Software testers historically focused on manual testing and thus didn’t need strong programming skills. Their fortes were product domain knowledge, intuition, out-of-the-box thinking, test planning, and test system setup. And these certainly are important, indispensable skills! SETs, however, live in both the development and testing worlds. They use developer skills to provide software solutions for testing problems. Automation is usually much more central to the SET role. Nevertheless, there will always be a need for manual testing because there are some problems a human can catch much more easily than a script (or an AI agent). A traditional tester will be responsible for doing test cases for a team, while a SET builds the solutions to empower other testers and developers to do the testing.
Personally, I avoid using the titles “QA” and “software tester” for myself because they don’t accurately describe all that I do. I also avoid the title “automation engineer” because, again, it is reductionist. I tackle software testing with the heart of a developer, and I set up test automation solutions from the ground up. I’m proud to be a software engineer who specializes in testing.
As a bonus, check out Test and Code episode 47, in which Brian Okken and I discuss what it means to be a Software Engineer in Test (among other topics).