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).
A brief memoir on self-improvement through self-humility.
I learned one of my most important life lessons before my career officially started. From 2007 to 2009, I interned on-and-off for the Rational Business Developer team in IBM’s Software Group. The team was great and let me do everything: development, testing, automation, builds, and even fun Web examples. However, my junior-level experience often made me doubt myself (e.g., imposter syndrome), and there were “known unknowns” by the truckload.
A photograph of me as an IBM intern. (j/k)
For my own survival, I quickly learned to fearlessly ask questions. This was a big step for a shy guy like me. My team mates were more than happy to help me, which put me at ease. Asking questions was a good thing.
…Until one time, it became a bad thing.
I forget exactly when it happened and what my specific question was, but I do remember the person and the method. I “pinged” (IBM lingo for “send an instant chat message to”) one of the senior developers with a question, and he replied with a link. When I clicked it, the browser loaded Google, moved the cursor, typed my question, and clicked the search button.
I was horribly embarrassed. It was an introvert’s worst nightmare come true. I never knew about LMGTFY before, and the sarcasm didn’t hit me until after the search was complete. My fledgling confidence was shattered.
My face after my first LMGTFY.
I couldn’t tell if the guy:
Thought lowly of me
Was annoyed with me
Was trying to coach me
Was having a bad day
Was just a jerk
The reason didn’t matter, though. He made a valid point: the question was Google-able, and I could have searched for an answer myself before asking others. As I picked up the pieces of my confidence, I introspected on how to do better next time. Was it wrong to ask questions? No. It is never wrong to ask questions, and anyone who says otherwise is a jerk. Was it wrong for him to send me to LMGTFY? It certainly was unprofessional and harmful to our team dynamic. But, was there a better way to ask questions? Yes:
When faced with an unknown, pose it as a question. Then, ask yourself the question first before asking others.
I call this the “self-Socratic method.” Whenever I don’t know something, I write a list of questions. Then, I try to answer those questions using my own resources, like Google, Wikipedia, and books. When I answer a question, I cross it off the list. Inevitably, answers lead to more questions, which I add to the list. As the list grows, new questions become increasingly specific because the unknowns become smaller. I also find that I can answer most factual, knowledge-based questions myself. The questions that require me to ask someone are typically wisdom-based or experience-based. For example, the question, “How do I build a Web app?” could reduce to, “Why do you prefer to use Angular over React as the JavaScript framework?” because the World Wide Web already has much to say about the technologies behind itself. At the very least, even if I can’t find much by my own searching, my due diligence shows good faith when asking others.
A photograph of me as a professional, self-Socratic software engineer. (j/k)
How much time do I spend searching for an answer before asking somebody who knows? This is a popular interview question. When using the self-Socratic method, I’d say (a) when the first two pages of Google results yield nothing, (b) when I spend more than 15 minutes absolutely stuck in code (from the time of the last “epiphany”), or (c) when I hit a wisdom- or experience-based question.
I’ve used the self-Socratic method for everything from learning how Web apps work to learning how to cut my lawn. I learned my lesson the tough way, but I’m glad I learned it early!
The main reason I went to PyCon 2018 was to deliver a talk entitled “Behavior-Driven Python” about behave, one of Python’s most popular BDD test automation frameworks. One of my major professional goals for 2018 was to speak at a conference – and any conference would do. Fortunately for me, PyCon accepted my proposal, and Piper Companies in Raleigh graciously footed the bill! The video recording for my talk is linked below. It also has a GitHub example project and a companion article. (I’ll write a separate article with links to other talks I enjoyed.)
The Destination
PyCon 2018 was held in Cleveland, Ohio. I had never been to Cleveland before, and I found the downtown area to be charming. Everything I needed was within walking distance: the Huntington Convention Center where the conference was held, the DoubleTree by Hilton on Lakeside Ave where I stayed, the skyline, the city hall, the Rock and Roll Hall of Fame, the Great Lakes Science Center, and Lake Erie itself.
The Huntington Convention Center, where PyCon 2018 took place.
Interesting shot on a bridge near the Rock and Roll Hall of Fame.
“FREE” stamp sculpture next to city hall.
Cleveland has a nice skyline.
I flew into Cleveland on the evening of Thursday, May 10. Unfortunately, I missed the opening reception because my Frontier Airlines flight was delayed. (I guess I got what I paid for.) When I arrived, I had only one destination in mind: Great Lakes Brewing Company. Great Lakes has been one of my favorite breweries since I first started drinking craft beer in college. I boarded the Red Line train at the airport and rode it directly to the Ohio City station, where their pub is located. The food and beer did not disappoint!
The Red Line
GLBC Flight Set
Great Lakes Brewing Company
Delayed flights are never fun.
GLBC Brats and Pierogies
Great Lakes Brewing Company
Ohio City
The First Morning
PyCon 2018 had three major phases: tutorials from May 9-10, talks and events from May 11-13, and sprints from May 14-17. I attended only from May 11-13 for the “main” part of the conference. I really didn’t know what to expect, but I was blown away by what I found.
The first thing I did on the first day was registration. I showed up at about 8am to get my badge and my conference t-shirt. The volunteers also handed me a “swag bag,” pre-populated with a map and some random goodies. Since I had my backpack, I didn’t think I would need an extra bag – boy, was I wrong!
The main conference area was an expo hall full of companies and organizations giving away endless freebies, much to my naive surprise. (This was nothing like the last conference I attended, PyData Carolinas 2016.) The major stalls were Microsoft, Amazon (AWS), Google, Facebook/Instagram, LinkedIn, Anaconda, O’Reilly, and Heroku. Others included the Python Software Foundation, Django Girls, JetBrains, Elasticsearch, ChowNow, Yelp, Patreon, Squarespace, Linode, platform.sh, PostgreSQL, Nylas, DigitalOcean, DataDog, Cactus, Six Feet Up, OfferUp, Twilio, Nexmo, Okta, Pluralsight, Zapier, Bloomberg, Shopify, PyBee, EdgeDB, Anvil, and others I can’t remember. Over the three days of main events, I talked with people at nearly every stall to learn about what they do and to score that dank swag. I walked away with twelve t-shirts, five pairs of socks, laminated Python guides, a JetBrains yo-yo, a Google puzzle, Yelp gloves, a Facebook earbuds case, an OfferUp water bottle, a couple koozies, and a countless number of stickers.
All the swag!
The expo hall entrance
The welcome banner at my hotel
Setting up the expo hall
The Django Pony at the Django Girls table!
The talks in Grand Ballroom A. Mine was Friday at 12:10pm!
While waiting for the first keynote address, I ran into Kenneth Reitz at the Python Software Foundation table. Kenneth is the original author of requests and pipenv. It was a pleasure to meet him in person. He also interviewed me for his PyCon 2018 podcast! My segment is at 19:11.
I was about to go to the keynote address when I walked by the O’Reilly stall and discovered a book signing: Harry J.W. Percival was scheduled to give away free signed copies of the second edition of his book, Test-Driven Development with Python. I got my “golden ticket,” waited in line, skipped the keynote, and scored that dankest swag of the conference. O’Reilly was giving out other books throughout the conference, but as a Software Engineer in Test, this one was the big kahuna for me. #worthit
The O’Reilly book signing
Kenneth Reitz (left) and the Automation Panda (right)
My talk, “Behavior-Driven Python,” was scheduled at 12:10pm in Grand Ballroom A. I wasn’t terribly nervous because I had given this sort of talk many times, but I was worried that I would run out of time. Before speakers give their talks, they go to the “green room” where they test projector cables and meet the “runner” who will take them to the auditorium. I got to meet other speakers, which made me feel more comfortable. My talk got off to a delayed start due to some technical difficulties with the projector, but I think it went really well. The ballrooms could each seat several hundred people, and it looked like my talk was fairly well attended. A number of people asked me questions afterwards. Then, I ended up having lunch with a new friend I met named Gabriel, too!
The Rest of Day 1
I spent the rest of the afternoon attending talks, which can be mentally exhausting after too much. However, at the end of the day, I got to spend some sweet time with my dear friend Kennedy from college. Kennedy reached out to me before the conference to let me know that he would be there. I ran into him each day, but we got to spend the most time together sitting outside Ballroom A just catching up on life. We hadn’t seen each other since 2010 at RIT. Kennedy is really getting into software infrastructure and DevOps-like work. It was such a blessing to see him there.
My bro Kennedy sports that Linode shirt like a boss!
Dinner was another fortuitous blessing. ChowNow invited me to dinner and drinks at TownHall. I met their chief product officer, their engineers, and their recruiters. We talked a lot about test automation. They’re in a very similar situation as my current company, PrecisionLender: a hundred people and growing, realizing their need for automated feature tests, and discovering how hard it is to build an automation solution themselves or find someone who can. They were really great people doing awesome things, and I can’t wait to see them grow.
ChowNow also had a fun giveaway challenge. To enter, one needed to hit a REST API endpoint, which then returned further instructions. It was a bit of a puzzle – I got confused for the first few minutes, but after a hearty facepalm I figured out the challenge and successfully submitted my entry. (Python REPL and requests FTW!) The grand prize was an iPad Pro, but I won the consolation prize of $20 in ChowNow bucks. Not bad.
The Second Day
For me, Day 2 at PyCon was almost entirely about talks. The morning keynotes were really inspiring: Ying Li told a great story modeled after the Wizard of Oz about how everyone plays a part in security, and Qumisha Goss shared how she inspires kids at the Detroit public library to get into coding with Python. There were more talks I wanted to attend than I could. I learned about sloppy Python, developing arcade-style games, statistics on Python users, Appium, and compiler tools.
In the expo hall, my most memorable conversation was at the Python Bytes / Talk Python To Me table. These are major Python podcasts. Julian Sequeira of PyBites told me all about the #100DaysOfCode in Python, which I really want to try so I can learn about things beyond my domain. He then introduced me to Brian Okken, who wrote Python Testing with pytest and runs the Test and Code podcast. We talked quite a bit about testing practices and frameworks. I almost convinced him of BDD’s benefits, and he tried to convince me that unit testing is waste. It was a great conversation, and I really want to learn more about Brian’s pragmatic testing perspective.
Julian championing the Sceptre of Python!
That evening, Instagram invited me to dinner. I thought it would be drinks and appetizers at a bar, like with ChowNow. Oh, no, it was … Let me tell the story. Before PyCon started, Instagram invited me to join them for a special dinner. I think they invited me because I was a speaker. Instagram provided promo codes for a free Lyft to Crop Bistro, one of the best restaurants in the city. It resides in an old bank: marble columns and fresco paintings on the walls. When I arrived, the hostess walked me to the back, down the stairs, through the kitchen, and into the bank’s old vault, which had been converted into a private party room. They served a full three-course meal with a full bar, and it was damn good. That ribeye steak… I met a lot of great people, too. I talked with Instagram’s release manager at length about struggles with test automation. I also got to chat with a number of their engineers (many of whom were from China), as well as other Pythonistas who were invited. It was a wonderful event, and I truly thank Instagram for the invitation.
A 3-Course Meal!
Instagram Cookie
The Vault at Crop Bistro
Crop Bistro
Also, I want to say that the weather in Cleveland was pretty darn cold! Daily temperatures were in the 50s, while at the same time in Raleigh, they were in the 90s. I froze my ears off walking from the hotel to the convention center!
The Third Day
At the Instagram dinner, I met a few guys who help organize Python conferences. They encouraged me to submit proposals to PyGotham and PyOhio. So, when I woke up on Day 3, I did! Hopefully, my proposals will be accepted.
The Job Fair
Representing PrecisionLender! Someone asked me about the four values on the back of the shirt.
The main event in the morning was the Poster expo / Job Fair. However, since I had already met most of the companies, I spent most of my time at the Rock and Roll Hall of Fame instead. I’m a huge fan of rock music. The museum had awesome exhibits with really cool memorabilia. I even got to vote for new inductees – I voted for Iron Maiden! I headed back to PyCon for the afternoon talks, but then I skipped out of the finale to finish seeing all of the Rock and Roll Hall of Fame exhibits before the museum closed.
Outside the Rock and Roll Hall of Fame
The Beatles entry in the Hall of Fame
Cliff Burton’s Bass Guitar (Metallica)
Angus Young’s Stage Outfit
Chinese Lunch
Aerosmith’s Set
My original dinner plan was to visit another local brewery. PyCon was hosting an event dinner at the Great Lakes Science Center, but I didn’t register in time to get a ticket. Nevertheless, my friend Kennedy offered me his meal ticket since he was returning home that afternoon. Hashtag-BLESSED. The museum was so cool. My favorite part was the NASA Glenn Visitor Center – they had one of the Apollo Skylab capsules! Many of us Pythonistas built a really tall tower out of wood blocks that we had to knock down once dinner was ready. The food was excellent, too: steak, salmon, mac ‘n cheese, green beans, and cheesecake for dessert.
Block Tower!
Inside the Mercury Capsule
Apollo Capsule from Skylab
Apollo Capsule from Skylab
Mercury Capsule
Delicious Dinner
My (Delta) direct flight home left on time Monday morning. I could barely fit all the swag into my suitcase! I caught a cold while attending the conference, but thankfully it didn’t take effect until I was back home.
Major Takeaways
So much happened at PyCon 2018. Even though I was doing stuff nonstop for three days, there was still so much more there to do. It will take me a few weeks to fully process everything. Here were my major takeaways:
I accomplished my goals. Before going to PyCon, I set three major goals for myself: (1) get a pulse on the state and direction of Python, (2) establish rapport in the community, and (3) become inspired to pursue greater work. CHECK! I met a lot of great people who all love using Python. A number of people really enjoyed my talk. I learned how so many groups, from top-tier Silicon Valley companies to local user orgs, are using Python to do cool stuff. There are also now just as many data scientists as web developers using Python. Seeing Python used in so many different domains really inspired me to learn more about those domains in which my knowledge is limited. I feel like I have more work to do after the conference than I did to prepare for it!
The Python community is so welcoming and friendly. When PyCon’s banner says, “For the community, by the community,” it’s true. This conference was about people much more than it was about programming. I was initially afraid that I would be lonely because I didn’t know anyone, but once I got there, everyone was outgoing; even me! Python is a language for everyone from beginners to experts, and there was no sense of elitism whatsoever at the conference. The atmosphere reminded me very much of freshman orientation week at RIT, when total strangers would strike up conversations and bestow well-wishes at every turn.
All companies have major test automation struggles. There is a universal awareness of the need for good testing, but there is also universal struggle to develop reliable feature tests at scale. Knowing that companies like Facebook/Instagram and ChowNow have problems similar to companies where I have worked gives me boosted motivation as a Software Engineer in Test to keep going!
Never write shell scripts. Just write Python scripts. Yes! This came from the “sloppy Python” talk. It’s so true. Shell scripting is so low-level and often unreadable. Plus, Python is cross-platform!
Flask is a big deal. Flask is a minimalist Pythonic web framework. It is a lightweight alternative to Django and Pyramid. Everyone was talking about it. O’Reilly was giving away books about it.
Prep for PyCon 2019! I want to return to PyCon very much. Next year, I have a better understanding of the talks, so I can make better proposals. I’ll also check out the open spaces and lightning talks. PyCon 2019 will be back in Cleveland, too!
What’s Next?
I feel like I have so much more to learn! Here’s what’s next for me:
Watch videos for all the talks I missed.
Come up with a personal professional development plan.
This week, I was featured as the PyDev of the Week on DZone and The Mouse Vs. The Python. Many thanks to Mike Driscoll, who interviewed me about my development experience for the article.
While most of my posts are technical, this one is a personal update:
I have accepted a fantastic new role as a Software Engineer in Test at PrecisionLender! I will be the company’s technical leader for testing and automation: building a strategy, setting up frameworks, writing tests, running tests in a CI/CD pipeline, and educating others. It’s the perfect role for me, and together, we will do great things. PrecisionLender is a very collaborative company that builds a software platform to help banks make smarter loans. They have about a hundred employees right now, and they’re growing. Their Raleigh office is located very close to my home.
With this announcement also comes the bittersweet news of my departure from LexisNexis. After almost a year and a half, it is time to say goodbye. I want to make it very clear that I am not leaving LexisNexis because I am unhappy, but rather to pursue a great new opportunity that providentially found me. My role as a Senior Software Test Engineer at LexisNexis has truly been the greatest opportunity of my career so far. I became a technical leader on one of the strongest test automation teams in Raleigh. I led the development of test frameworks that were shared across the whole company, in addition to writing countless test cases. I did internal consulting with groups across the globe to teach them how to be better testers and automationeers. I even earned the nickname “Reverend BDD” for the many impassioned training sessions I delivered. I grew tremendously in my own professional software skills. I learned from my mistakes along the way with the grace of others. And I found many great, new friends, with whom I will surely miss working. I specifically want to thank my manager, Kalen Howell, Sr., and my team lead, Jeff Wolf, for trusting me to tackle big problems and valuing my expertise. Working for LexisNexis has been a privilege.
My last day at LexisNexis will be Tuesday, April 3. My wife and I will then take a short vacation to Charleston, SC, and I will start my new position at PrecisionLender on Tuesday, April 10. Other than that, I will continue to write this Automation Panda blog and help my wife with her businesses as needed. I will also deliver a talk at PyCon 2018 in Cleveland, Ohio this May entitled, “Behavior-Driven Python.” Be sure to check it out! Connect with me on LinkedIn and Twitter, too.
I am resolute in my career path to continue pursuing testing and automation. Vocationally, we as creatures made in God’s image ought to seek to glorify Him through our creative work. As software engineers, our form of work emulates the creativeness of our Creator. Much in the way that God spoke creation into being, we likewise speak software into being, albeit in a microcosm. The whole discipline of computer science is itself rooted in language, in instruction. The instructions we issue, and the very systems we construct, reflect the logical, rational, orderly nature of God’s creation. Furthermore, as testers, we likewise recognize man’s fallen nature and our need for correction. The systems we implement will never be perfect because we are not equal to God. In testing, we simultaneously assert the wonders of creativity as well as our need for redemption in Christ – both to the glory of the Good Lord. This is what motivates me to pursue test automation. I thank God for this opportunity. Soli Deo Gloria.
I first started programming back in 2002. In fact, I stumbled into it unintentionally. My high school, Parkville High School, required all students in their Magnet Program for Mathematics, Science, and Computer Science to have a TI-83 Plus graphing calculator. As an incoming freshman, a graphing calculator was a big luxury for me – I spent my entire 8th grade Algebra I class without one, completing all problems by hand. Embarrassingly, it took me ten minutes to figure out how to turn it off the first time! I presumed that my new calculator would be used exclusively for math classes, but in the first few weeks of my computer class, we started programming the calculator. I’m sure we wrote some sort of basic “Hello World” print program, but we quickly moved onto programming math formulas.
It blew my mind.
At the time, I didn’t know what “computer programming” was. In fact, I didn’t even like computers very much. And yet there I was, thirteen years old, telling a calculator how to automatically solve my math problems for me. It was one of the greatest thrills I had ever experienced. I could command a machine to do cool things and make my life easier. I quickly started writing programs outside of class for every math formula I could find: areas, volumes, circumferences, the Quadratic Formula, the Pythagorean Theorem; and I shared my formulas with my classmates. Then, I moved onto calculator games. At the end of the year, our class started programming simple graphics and animations in C++, for which I made a fireworks show.
Something just clicked for me and coding. It all made sense. I could solve any problem. I could make any feature. I could teach myself how to do anything. And doing it brought on this wonderful euphoria – the “coder’s high” – even stronger than the feelings of Christmas morning or playing video games. For me, coding was practically addictive.
When my mom told me that there were well-paying careers in software, I never looked back. I took my first Java programming course as a sophomore (which I still consider my “mother language”) and then AP Computer Science AB as a junior (which was the first year it was offered in Java; I scored a 5/5). I went to RIT for college, where I graduated with a combined BS/MS in Computer Science in 2010. The rest is my professional history.
There were many times along the way that I doubted my path. There were times in high school that my code simply wouldn’t compile or run and I had no idea why (in the dark days before Stack Overflow). There were times at RIT when I felt like the most computer-illiterate student in my sink-or-swim program, and I even considered switching to a math major. There were times when the corporate grind was so tough I considered dropping back into academia. But, every time I doubted myself, I remembered what inspired me to pursue software at the beginning – the spark. The click. The it factor. The undeniable tenacity in my soul to solve real-world problems with elegance and efficiency through the sheer power of logical processes. I’m convinced that one of God’s greatest gifts to me has been the software spark. Though tempted, I have never wavered in my vocational clarity.
I’m not the only one who’s experienced the “spark,” either. In fact, it has consistently been my litmus test for identifying truly great coders. Many people have recounted nearly identical stories to me of how they first got into software – they were hooked at “Hello World.” I’ve heard people say things like, “I didn’t want to do it at first, but I discovered it was the coolest thing ever!” or, “What I love is that you can do anything!” or, “It seemed so basic and almost stupid, but it was so awesome!” Inversely, I’ve seen those who lack the spark struggle tremendously with computing and software. And it’s not a matter of grit or intelligence – these often are smart, hard-working people who just lack that X-factor.
Now, please do not misunderstand me by thinking that it’s impossible for those without the spark to be successful in software. I’m not trying to be elitist or condescending. Rather, based on my experience, I’ve seen the spark to be the single greatest determining factor in what makes someone naturally talented at programming. Furthermore, having the spark doesn’t make the journey easy. A career in software still requires grit and elbow grease. The challenges are tough. Having the spark simply makes it worthwhile.
If you have the spark, you’ll be able to overcome any software obstacle. I encourage you to go do awesome things. And never, ever give up!
This post is dedicated to my parents, who always supported my software aspirations from the very beginning.
It’s an open secret that bad practices are rampant in the software industry. Unreadable code. Perpetually failing tests. Pointless, boring meetings. Buzzword bingo. No discipline is perfect, but as a purist, bad practices really bother me. Somedays, I just feel like this:
The struggle is real.
There are times when we all need to vent. Well, here’s mine: it’s the Airing of Grievances! I got a lot of problems with bad practices in the software industry, and now you’re gonna hear about it! So, put up that Festivus pole and serve that meatloaf on lettuce, because the Automation Panda has a whole series about how not to develop software!
Warning: This post has nothing to do specifically with software. It is rather a personal musing over communication styles.
Throughout my years in the professional work environment, I’ve noticed a trend that bothers me: the inappropriate use of the ellipsis in textual communication. For example:
Hi Andy… Automated tests from the ABC build job are failing this morning… I don’t know why… Please do the needful… Thanks…
Dot-dot-dot… What meaning did the author intend to convey?
Did their finger get stuck on the keyboard?
Did they intend to use a period or a comma?
Do they want to textually capture pauses between their phrases?
Am I supposed to assume something that they haven’t said?
Are they giving me a specific task to do or simply speculating?
Did they lose their train of thought?
Do they doubt their words?
Are they half asleep?
Are they wishy-washy?
Are they being passive-aggressive?
Are they complaining to themselves?
Are they upset?
Are they in a bad mood?
Are they mad at me?
Am I in trouble?
I know I’m not the only one standing on this soap box – a friend recently triggered me by tweeting about the same problem. Blame my minor in creative writing.
This is not merely a minor nuance. Ellipsis abuse causes ambiguity, doubt, and stress. It can cause uncertainty in office relationships. Terse textual communication is already crude, and every jot and tittle implies meaning, whether intended or accidental.
In professional environments, always strive for clear, concise, and direct communication. Good communication skills are more than just a resume tagline. We should all pay close attention to how we write. Be on point, not on three points.
Life never gives us what we want at the moment that we consider appropriate. Adventures do occur, but not punctually.
From “A Passage to India” by E. M. Forster
Back in July of 2013, NetApp sent me on an awesome business trip to Bangalore, India. I had already planned to take a personal trip to China during a company shutdown, and I convinced my senior manager to send me to Bangalore on my way back to the States. The main reason for the trip was to help our offshore contractors build up their test automation skills for an upcoming release. While they benefited from my assistance, I likewise benefited from a much deeper appreciation for international workers. This article documents my experiences and the lessons I learned from my trip.
Transportation
My connecting flight from Kuala Lumpur (on Malaysia Airlines – gasp!) landed in Bangalore at around midnight, local time, on a Monday. NetApp provided a private cab for my whole stay. I felt a little bad because he spoke minimal English with a thick accent, but he was very friendly. I couldn’t see much on the drive to the hotel except a bunch of road blocks and a half-constructed highway. When he dropped me off at the Hyatt, I slipped him a few crumpled rupees my aunt had given me before my trip – she had visited India the previous year and implored me to always leave small tips.
Every morning that week, my cabbie picked me up from the hotel at 8am and returned me at 8pm. (The days were long.) He drove a crossover-like vehicle that felt like a minivan but drove like a small SUV, with flowers and Hindu statues over the dashboard. Even though the office was only a few miles from the hotel, a one-way trip took about 25 minutes. And I saw everything: “two-wheelers” (bikes with or without motors), “three-wheelers” (auto-rickshaws), “four-wheelers” (what we could call “cars” in the USA), pedestrians young and old, buses with people hanging on the side, and even cows just moseying through the streets. It was freaky to see not only everyone driving on the left side of the road, but to realize that the roads did not have any lane markings painted on them. In traffic, you just go with the flow, rather than obey specific conventions. Going to lunch one day, my “substitute” cabbie (not my typical driver) actually hit a two-wheeler, tearing off part of the cab’s bumper. Thankfully, the other guy just spat some pithy words in Hindi and sped away.
The view from the backseat of my cab: driver on the right, driving on the left (I think).
The quintessential auto-rickshaw, driving rain or shine. And apparently, Bangalore has Taco Bell!
Moo.
My Team
NetApp had a huge company site in Bangalore, but I spent all but one day at Mindteck, a nearby contracting firm hired by my organization. My team in Raleigh worked extensively with our group of Mindteck contractors. I felt delighted to meet them in person – they became more than broken voices and blurry profile pictures. And the team graciously welcomed me as one of their own. Every afternoon at about three or four o’clock, they tapped me to join them on the roof for masala chai (tea). There was never any shortage of Kinley water bottles, either. Embarrassingly, the team was so large that I struggled to remember who was who, but they never forgot who I was.
Mukesh, one of my team mates from Mindteck, on the right. Me, in my kurta, on the left.
Kinley, the bottled water choice of champions! We call it “Dasani” in the USA.
During my visit, my team and I worked a lot. Every day, we had meetings, meetings, and more meetings, all about the “big A” – automation. Hearing my Raleigh team mates on the other end of conference calls felt like a strange reversal. I led automation workshops to teach our contractors a new framework we had developed in Raleigh. They also shared a number of problems with me, in the hopes that I could somehow help. Some were simple programming problems that took nothing but a simple proofread to correct. Others were out of my league. One evening, I sat locked in a conference room with an IT guy trying to figure out some obscure network failure, while two managers stared at us silently for almost two hours. I did my best to not feel awkward, assuming this style of management-by-pressure was cultural.
One problem I couldn’t solve for Mindteck was red tape. NetApp put a lot of restrictions on what the contractors could and could not do. They were restricted from accessing certain systems. NetApp’s Bangalore site also wouldn’t give them a direct network connection, which slowed down their network speeds to the point where test scripts would regularly crash from timeouts. Mindteck showed me their lab in disarray and admitted that they didn’t always get the hardware they needed for proper testing. Most frustratingly, I learned that the contractors were not even permitted to ask engineers on the parent team in Sunnyvale, California for help! In Raleigh, getting help from Sunnyvale was always a struggle, but at least we never had our hands slapped for asking. We all vented loudly about that ridiculous rule.
I spent only one day with the employees at the NetApp site. When I arrived, nobody was ready for me, so I poked around the cubicles until I saw plaques with names I recognized. Thankfully, everyone was friendly there, too. I don’t remember much of the NetApp site except meeting a few friends, seeing the Engineering Support center, and getting evening snacks at 6pm.
Lunch with NetApp employees in my organization. I wish this picture turned out better.
NetApp gave out snacks every day at 6pm. These were spicy!
The Hotel
NetApp approved only two or three hotels in Bangalore for travel. Arbitrarily, I chose the Hyatt, and they treated me like a king. Every manger, director, and VIP with a business card greeted me throughout the week. Bellhops always assisted me with luggage. Room service was always quick. And it was definitely a luxury hotel. Later, I learned that I was the first NetApper to stay there, and they sought to impress me in the hopes of future business from NetApp.
Exploring on my Own
The evenings were the only chance I had to explore Bangalore. As much as I wanted to hop an auto-rickshaw, I feared getting lost or scammed, so I stayed near my hotel on foot. Around the corner was a fancy shopping mall. The first store I entered was Big Bazaar, India’s version of Walmart. As a dumb American, my first mistake was attempting to enter Big Bazaar through the exit doors – a pair of armed guards quickly corrected my mistake by pointing me to the real entrance. Inside, I meandered through the store amazed by the essentials of Indian life, most of which were not much different from my own in America. When I tried to buy a few snacks from the grocery section, I made my second mistake by presuming the cashier would give me change – nope, I lost a few rupees. Before exiting through the proper exit doors, I detoured through the clothing department and bought myself a souvenir: a black kurta with red embroidery on the collar. I’ve since worn my kurta many times at Indian festivals in Raleigh.
Big Bazaar – it was pretty big!
Across from Big Bazaar was a movie theater. Since I had nothing else to do, I moseyed over to see what films were playing, hoping to see a Bollywood movie with English subtitles. Instead, they had Despicable Me 2 playing, which I could not resist. The ticket plus samosa and Slice mango drink cost only a few dollars – a fraction of the typical movie cost in the USA. However, when I entered the theater, an armed guard who didn’t speak English forcibly patted me down. In public places, Indians took security very seriously. My coworkers told me the security was necessary to protect against Islamic terrorists.
Bangalore had such stark dichotomies. Near my hotel on MG Road were modern buildings with posh stores and fancy restaurants and security guards, while right around the corner were dilapidated houses with refuse burning on the street. Next to billboards for mobile phone plans were temples with innumerable statues. Two constants, though, were the crowds of people everywhere and, sadly, the pollution they left behind.
A mango peddler near Mindteck.
I passed many Hindu temples while riding around in my cab.
The Food
It’s a good thing that I loved Indian food. At work, my Indian counterparts showed much hospitality through their food. Every day, they provided lunch for me. One day, Mindteck catered a full lunch buffet as part of a meeting marathon. On the day I was on-site at NetApp, a friend bought me lunch in the cafe – 100 rupees, or about $1.50. For the remaining two days, both NetApp and Mindteck planned off-site lunches at delicious Indian restaurants. I ate it all: rice, naan, roti, curry of every color, chicken, lamb, paneer, aloo, palak, and gulab jamum for dessert. Nobody was surprised that I was “non-veg”, but they did appreciate my culinary adventurousness. For me, I was surprised to discover that, in India, eating with your bare hands is normal.
Gulab jamun, hot and fresh at an Indian buffet.
In the evenings, I had two fancy meals on my own. The best was my last night at the hotel. Since NetApp covered all travel expenses, I chose to eat dinner at the Hyatt’s fancy restaurant. It was totally empty, but that meant I received the best service. After serving my chaat and my curry, the head chef himself came out to greet me. The other fancy dinner was at a South Indian restaurant on the top floor of the nearby shopping mall – prawns, yellow-green curry, and round flatbread washed down with a Kingfisher. When the waiter served the food, he put the napkin on my lap for me. A third dinner I ate at the hotel’s standard restaurant while they played live music. On the night I went to the movies, I ate a Chicken Maharaja Mac at McDonald’s – let’s just say the Big Mac is better with beef. (Come on, I’m a red-blooded American.)
The South Indian dinner at the fancy shopping mall.
Some of the best “prawns” (not shrimp) I’ve ever eaten.
The Chicken Maharaja Mac Meal. #MURICA
Goodbyes
On my last day in Bangalore, I wore my kurta. As I left in the morning, the front desk lady at the Hyatt shouted out, “Very nice kurta, Mr. Knight!” My Mindteck team planned a proper sendoff in the afternoon. We took group photos, and they gifted to me a small desk clock that I keep to this day. And they offered one final treat – an ice cream bar. There were six small scoops of various colors, and I had to taste each to guess the flavor. To everyone’s surprise, I got them all right! I didn’t have the heart to tell them that I suffered from lactose intolerance. My belly ached during the whole flight home, but the experience was well worth it.
My flight out of Bangalore departed in the wee hours of the morning. My cab picked me up from the airport shortly after midnight. I flew to Qatar, then NYC, and finally to Raleigh for a nearly day-long transit. My biggest regret was not having enough time for sightseeing in India.
The Mindteck team and me: coworkers and friends.
The ice cream bar, from left to right by row: strawberry, banana, lychee (?), jackfruit (?), mango, and blueberry.
Lessons Learned
I gained a genuine appreciation for our offshore teams after my trip. Oftentimes, I hear American workers complain that offshore workers are “stealing jobs,” and “you get what you pay for” in quality of work. But I learned firsthand that these folks are good people just trying to make a living. They aren’t trying to steal our jobs – they’re taking the opportunities in front of them as part of a global economy. Frankly, big companies hire offshore resources so they can throw more bodies at their projects. And quality suffers greatly when any team is not co-located due to challenges with communication, time zone, technology, bureaucracy, etc. Moreover, our guys and girls wanted to be more than just hired help: they sought to learn more, improve their skills, and increase their contribution.
Overall, I was very grateful for the opportunity to visit Bangalore, and I hope to return some day!
This post is dedicated to all of my friends from India.
Why am I an automation engineer? The answer became starkly clear to me one Tuesday morning that should have been like any other. At that time, I was a “Software Quality Engineer” on the QA Framework team of a fairly small software company. I arrived at the office at my normal time around 9am. The following two hours I spent in my daily groove with my headphones on, blissfully unaware as our director started escorting engineers out the door with boxes in hand. After an interrupted 11am standup, I found myself, heart racing, in a conference room with my manager and the VP of engineering who had flown in from our other site. On the table, I saw a pile of key fobs and bejeweled company phones. By this point, anyone who knows the software industry could predict what would happen next: the dreaded layoff. However, that’s where the story becomes more interesting.
I wasn’t laid off. Surprise!
In a daring reorganization, the VP eliminated all QA positions in the company. The justification given was to make teams purely Agile with no silos of division between development and quality. Everybody would own quality. Manual testers would be removed in order to prioritize automation. I also suspected that company finances may have encouraged the re-org. As a result, people lost their jobs. However, a few QA engineers, myself included, were spared the layoff and rebranded as regular “software engineers.” In that conference room, as the adrenaline rush subsided, the VP outlined a high-level plan in which I would move to a product development team that desperately needed automation help. Apparently, this team didn’t even have unit tests, and their product was weeks behind schedule. Once they got it going, I would become a regular web developer with the others.
So, why me? The survivor’s guilt bothered me, but the answer, apart from God’s grace, was pretty obvious: automation skill. I was the company’s automation champion, and everybody knew it. I consulted with each team to help improve their testing efforts. I gave a lunch-and-learn on behavior-driven development. I wrote several wiki pages and even example projects. Now, that’s not to brag on myself or belittle the skills of others, since many of the engineers who were cut also had automation talent, but my skills had been made highly visible to the people in power. And my skills continued to afford me great opportunity.
However, the last part of the VP’s new plan disconcerted me – did I want to become a standard web UI developer? I pondered the question deeply, but my gut answer never changed: no. Test automation was my specialty. It was the product I made, and I made it well. I knew the ins and outs, the frameworks, the best practices, the fundamental problem of test automation and the lowercase problems that derive. And I loved doing automation because it gave me the opportunity to set things right: to find an eliminate bugs, to protect the code line, and to make it look damn good. I could indeed switch over to web dev, but why? I didn’t have interest in web dev. That would be like making a hardwood floor installer do painting instead. With automation, I had both a specialty and an opportunity.
To conclude the story, I didn’t stick around much longer at that company. I quickly found a better opportunity as a senior-level automation engineer on an exciting new project at a different company. That’s the software industry – so it goes! Ironically, that layoff may have impacted me just as much as if I had actually lost my job. It forced me to make a choice. I definitively chose to be a software quality engineer. Automation was no longer merely a skill set but a career identity.
Automation Panda 