Does a tester break the product?
Recently, I came across this tweet:
We may argue whether a tester breaks the products or proves that the product is already broken. I firmly believe that testers discover defects not cause them, so maybe we should no longer describe their job as “breaking the software.”
In IT, naming things was always hard, but it seems that recently we started to care more about the nomenclature. How many of you call yourself programmers? I agree with Kelly Vaughn, a programmer is someone who writes code. Period. That is the only requirement.
At work, we call ourselves engineers or developers. How does it change our perspective?
Are we here to write code? Not necessarily. We had been employed to solve a problem. Sure, quite often you need to write code to do it, but that is not the only part of the job.
In fact, it seems that the more experienced software engineer you are, the more problems you solve without writing code. The job changes from “writing code” to “talk with people and figure out what code you must write.”
It may seem ridiculous that we spend so much time defining the vocabulary we use to describe our job. Is it ridiculous?
A few days ago, I listened to Jocko Willink podcast. In one store, he mentioned that some music clubs in the U.S. no longer call the person who is guarding the door a “bouncer.” They began to call them “hosts.” What changed? The bouncers… ekhm… hosts no longer think they should be aggressive and kick people out. Now, they are here to make the guests feel safe and comfortable.
Naming things is hard, but that should not be an excuse.
Did you enjoy reading this article?
Would you like to learn more about leveraging AI to drive growth and innovation, software craft in data engineering, and MLOps?
Subscribe to the newsletter or add this blog to your RSS reader (does anyone still use them?) to get a notification when I publish a new essay!
You may also like
- MLOps engineer by day
- AI and data engineering consultant by night
- Python and data engineering trainer
- Conference speaker
- Contributed a chapter to the book "97 Things Every Data Engineer Should Know"
- Twitter: @mikulskibartosz
- Mastodon: @email@example.com