Why Should I Check Your Code? (5 Minute Breath Test)

[ad_1]
If you can’t spend 5 minutes checking your work, don’t.
I’ve spent 18 years in the software engineering industry, and I’ve been called a programmer, then an engineer, and now a software engineer – the next “delivery demon,” mark my words. Meanwhile, I’ve checked my fair share of code. I worked as a part-time tester, tested code I wrote, ran Quality Assurance (QA) teams, and poked my nose into systems I shouldn’t have.
There are many topics for professional software testers. You can be called a Tester, QA Analyst, or Engineer in Test. You may be creating incredibly advanced automation scripts that produce great reports with SonarQube, or you may be doing full manual testing. Regardless of your topic or approach, you’re trying to find problems before they reach production, and users find them.
The inspector is the engineer’s partner in crime. As a book editor, you take what others (ie, Developers) do and make it big. As Steinbeck said of his editor Pat Covici, “He was more than my friend. He was my editor. Only a writer can understand that a great editor is a father, a mother, a teacher, a personal devil, and a personal god. For 30 years Pat was my assistant and my conscience. He wanted more than I had, and with that he made me more than I could have without him.”
Testers help Software Engineers get off the ground Good for Grandfather.
Over the years I have come to believe two things about testing:
First of allwhat the inspector does is difficult. Their work requires the application of precision to specific project needs, unconventional thinking (a box, which box?), moving the end user, and a holistic/system-level perspective. Testers do an amazing job and have always been essential to my success in releasing amazing software.
Second timethe tester’s job is made even harder by the Software Engineers, because the Engineers give the shit code that fails what I call the “5 Minute Sniff Test.”
As a Software Engineer, you have chosen the best software for building a career. You love solving fun and interesting problems using the latest frameworks, cool algorithms, rainbows and unicorns. Every day, “You crush it!” However, all of that comes to a screeching halt when you have to wade through the mud of ill-defined (and sometimes incomprehensible) requirements just to get to the heart of the problem.
Your progress is delayed, your time is wasted, and you are angry! All of this could have been avoided if the Product Manager had just put more care into what they provided. Isn’t PM proud of their work? Do they even know what they are doing? Garbage in is garbage out.
When it is a Software Engineer’s turn to deliver their work, the quality of the code determines the effectiveness, success, and character of the tester. A tester expects the same level of quality as a Software Engineer expects from a PM. This doesn’t mean that your code is bug-free — we don’t want to put anyone out of business — but it does mean that your code meets a certain level of quality and professionalism.
How do we measure the quality and professionalism expected? Take the 5-Minute Breath Test. Basically, if someone (Tester, QA, Spouse, or Instructor) can find big and obvious bugs in the first five minutes of testing your code, then you haven’t spent enough time testing. You wasted your time, despised the Inspector’s time, and began to build a reputation for delivering sloppy work (question: do you even know what you’re doing?). You laid a bad smelling rotten egg, everyone knows you are, and you should be ashamed. Garbage in is garbage out.
That “I want to crawl under a rock”.
My team and I once built a great new feature for our iPad app that was technically challenging and had a very cool design, and I was proud of the work we did. It moved and we had crushed it!
With a cheshire cat grin, I presented the app to our Asian CTO (the old guy with about 10,000 people reporting to him). He started clicking everywhere except where I wanted him to click.
No. Don’t do it! STOP!
But he just kept clicking. The app crashed, data couldn’t be loaded, and chaos ensued. Finally he handed me the iPad back and muttered, “This doesn’t look right.”
He never saw the new features we built. I was frustrated, embarrassed, and wanted to crawl under a rock, but I had learned an important lesson.
Don’t make someone else pick you up after you.
Often I will hear software engineers argue that it is very difficult to change their mindset from coding to testing.
That’s why we have a test team, right?
Bullshit!
I’m not asking you to walk, rub your stomach, and chew gum at the same time (it’s harder than you think). I am asking you to take five minutes to assess what you have built and what you should be standing behind with pride.
Just because the city has street cleaners, doesn’t mean you have to throw your candy wrappers on the ground.
Don’t make someone else pick you up after you.
We need to do better.
And we can.
The 5-Minute Sniff Test is the first line of defense against the “I’ll just give up anything” mentality.
It means that before you give your feature, stop, take a deep breath, clear your mind, and then for the next 300 seconds, check what you just created.
- Out of the Box – 90 Seconds: Have you stepped outside your engineering shoes and explored from a user perspective? Does the feature look good and sound good, regardless of requirements? I painted myself into a corner arguing that the feature is valid because “that’s what the requirements demand.”
- Test Your Unit — 30 Seconds: Do all unit tests pass, and is there complete code? You can’t test everything manually, so automated unit testing is important for code quality. The 30 seconds provided is not for creating unit tests, but to ensure that they pass. You should also consider building failures if unit tests fail, which would allow more time for transparency.
- Obvious – 190 seconds: Have you checked all the obvious cases? For example, if a pressed button is supposed to cause unicorns to dance across the screen, be sure to check that pressing the button actually causes unicorns to dance across the screen. Do I get any errors in the logs, does the rainbow show even though that’s not part of the requirements (although it should be, because that would be nice), and what happens when I double-click the button? Review the requirements and make sure everything fits together. For example, did you notice that the total number of seconds listed here equals 310 seconds instead of 300 seconds? Let’s fix “Obvious” to 180 seconds.
It only takes five minutes to make sure you don’t give a shit. If all else fails, grab your colleagues and ask them to sniff.
In his book “Blink,” Malcolm Gladwell tells the story of interviewers making snap judgments about a candidate’s quality in the first five minutes of a meeting. The interviewer continues to unconsciously reinforce his initial impression by weighing the candidate’s answers against his own biases.
In other words, your first impression is your last impression. I don’t believe I ever fully recovered my dignity with an Asian CTO after that first bad idea.
Taking the 5-Minute Smell Test to check your pollution takes very little time, but it can be very beneficial for you, your colleagues, and your company:
- It helps you build a Reputation for beauty and quality,
- It Courtesy your partner in crime, Tester, and
- It’s more It works well on everyone’s time.
If everything looks and feels right after the 5-minute sniff test, move on to the feature you’re most proud of and can’t stand behind. You’ll have an appreciative Inspector, and build a reputation as an amazing developer.
About Ayrshare
Ayrshare is a social media API that allows you to publish posts, get analytics, manage comments, and send direct messages to social media directly from your platform. Read more in our social media API documentation.