Bias and Bugs

SEPTEMBER 8th, 2017

Some time ago I simplified the way this blog looks. My mentor Rob asked me something along the lines of what purpose my header image served, what did it mean, why is it there. In response I just kinda blinked. So, I started to change things up. Since doing so I've learned a lot that’ll probably mean I'm going to have redo the whole blog when I get a chance. But that's outside of the scope of this post. What I want to talk to you about is how after I did my redesign I pushed up some bugs, and caused myself a week of headaches.

I redesigned the header to be much simpler. I opted to go with a light grey header background with black text. At mobile sizes I have the header text on two lines and left justified. This didn't take me too long to get sorted out and honestly that felt really good. I was happy with myself. Though just to be sure, I checked the mobile viewports using the emulator in chrome's dev tools. All was good. Then I pushed up the code to Github and it was live. Sweet. Things look much better now.

Then I pulled out my iPhone to marvel at what I'd done. Everything was messed up. The header text went way beyond the browser's right margin. The rest of the content was pushed far to the left. Everything was screwy. It looked fine on my desktop, but on a physical device it was atrocious. Even worse it was live on the web for anyone to see.

I make my living in Quality Assurance. On a daily basis I test web apps on multiple browsers and mobile devices. I am skeptical, logical and adept at finding all the relevant combinations and permutations that need to be exercised when testing complicated web applications. Yet, a switch was flipped when I traded my QA hat for a developer hat. I did a bare minimum amount of testing.

If the way my feelings after coding up the new design were translated into words it might be something like this. "Dude, look at how easily you made that happen. You typed the code without looking every little thing up. You’re so cool and smart. You can read the code and you know exactly what it does. You’ve seen it do exactly what you intended it to do. You’re so great and handsome. This obviously works. Ship it!

It's a given that developers are too close to their code to consistently think critically about how and under what conditions it is likely to fail. I don’t care what this guy says. That's why the profession of Quality Assurance exists. I am a pro at sniffing out the cases most like to break software but when I started coding this up I immediately had a developer’s bias. That bias and my excitement at doing something without a struggle caused me to push up bugs that made my blog look like poo on every cell phone. It stayed that way for about a week because I couldn't figure out why on earth it did this on my phone, but not in my browser.

The lesson I learned here is don't assume it works just because you feel confident. Test it. Test it even if you are 100% certain that what you've done is perfect. Test it even more if you are really proud of what you've done.