Last updated on 2021/07/13
I can’t stand cats.
This is because I am allergic and the second reason is that cats are a-holes.
Yes, I will freely admit that I am a dog person. Having a pet that will love you unconditionally and will get just as excited upon your return no matter if you are out of the room for 5 minutes or 5 days.
Cats, on the other hand, are pretty much 1/2 second away from clawing your face off at any given moment.
It is a good thing that cats are lazy. Their sun-sleep-recharge cycles mean that they have less time for creating claw-shredding mayhem as they appear to sleep 20+ hours per day.
However, cats can provide one huge benefit to developers:
That is right. This person’s cat found a UI-breaking bug simply by sitting down on the keyboard.
So is this telling us that in order to be a better developer we all need to run out and get a cat?
Absolutely not.
Hairballs and litter boxes. No thank you.
However, there are a bunch of ways that you can get better at delivering productions and solutions that you have developed. Spoiler alert – none of them require obtaining a clawed, furry, murdercat.
The Cinder Block Method
This method is pretty straightforward.
Step 1 – Obtain a cinder block. It could be an individual block or one that is part of an existing wall. Your choice.
Step 2 – Bang head against the wall 4-5 times.
Wait, better up the game a little bit.
Step 2b – Bang head against wall to bring total up to 6-7 total smacks.
Step 3 – Go try and use the software that you just created.
If it isn’t clear and obvious that the above is sarcasm, then maybe repeat steps 1-3.
Seriously, this method is all about the stupidity of users.
No – I do not believe that users are stupid.
However, I am a firm believer that even really, really smart people do dumb things.
And users fall everyone on the spectrum of intelligence. Therefore, as they are other human beings, they will do stupid things.
What this method is all about is to put yourself into someone else’s shoes and try and see things through their eyes.
The reality is, about half of the time that users do stupid stuff is because they don’t have an understanding of what they are supposed to do.
This is not their fault! One of the worst assumptions that developers can make is to assume the intelligence level of their target user.
There could be big design flaws in the product. Documentation may be non-existent. The intended workflow may not be clear and obvious to some users. In these cases, human nature takes over and they experiment. They mash buttons. They often resort to doing what we could call “dumb stuff”.
However, our code and our solutions can always be better by trying to think like a user and see it through their eyes.
Any assumptions that you might have made when reading about bashing your head into a cinder block wall were NOT meant to lower your intelligence. The intent was to scramble your brain so that you look at things through a fresh set of eyes.
The Opposite 360 No Scope Method
If you have spent time around any teenagers recently while they are watching the youtubes and playing video games you might have heard one of them exclaim something like this:
“They just totally owned that noob with a 360 no scope! That was awesome!“
In video game parlance, a 360 No Scope is where someone while playing a first person shooter, spins around while wielding a sniper rifle then shoots someone at the end of the spin without using the rifle scope to zoom in and get a better shot.
In other words, it looks cool and is dependent upon a lot of luck.
So if you aren’t using this method, then the 360 No Scope is what you are trying to achieve by rolling out software that hasn’t gone through an Opposite 360 No Scope review.
Something that looks cool, passes all the testing, doesn’t have any bugs, and requires a lot of luck to achieve that end.
No, the Opposite 360 No Scope doesn’t mean that you spin to the left instead of to the right. It doesn’t mean that you make yourself dizzy by spinning while looking through a rifle scope.
What it does mean is that you don’t spin as fast as possible, you instead take your time. You go slow. You can choose to spin in an opposite direction, but if you start at any one point of a circle and go around it 360 degrees you will end up back at your starting point no matter what direction of travel you take.
A slow, methodical 360 degree review of your solution is the key here.
So what does this mean?
It means that you are looking at your solution from all angles. You are checking all inputs and outputs from functions. You are looking for edge cases. You are zooming in and out, looking at each tree then checking the forest.
Does your solution work for all range of inputs? Does it work for bad data input? Does it work for no data input?
Do your outputs make sense? If the config file is deleted will it crash and burn?
Remember, your users aren’t stupid, but they have been known to do some dumb things sometimes.
The Cat Method
No, this is still not a license to go out and get a cat.
However, it is permission to act like one.
As much as sitting on your keyboard for warmth and because you are just an a-hole who wants to be the center of attention sounds like fun, don’t do that.
Instead, mash a bunch of keys on your keyboard. Take a nap on your spacebar. Pretend that mouse is a laser pointer and click everywhere on the screen.
This is where you get to try and destroy what you have made. So light it up. Fire away. Break some stuff.
Anything you find and fix now is something that an end user won’t find. And that is a very good thing.
Breaking an app also breaks confidence in the developer. Especially if that bug is part of key functionality.
At this point it becomes a perception game.
Nobody really cares if there is a misspelling on the About screen. How many users actually see that screen anyways? But for those that do, it starts to break the illusion that this is perfect software and it is safe and trusted.
One misspelling isn’t a big deal. It is a small surface blemish.
But a bug in a critical feature is a crack that runs deep.
If your software is like a path in the woods, then the main path that you want them to follow should be easily marked, smooth, and free of debris. It should be easy to walk on and it should work.
Remember – once released into the wild, you have no control over the path, the perception, and the purchasing that your users will (or won’t) do.
So do your work up front and it will help you in the long run.
At the end of the day, be responsible for your own code. Hopefully this tips help to make it just a little bit better before release. If nothing else, your QA team will thank you for the extra effort!
Thanks for reading!
Comments are closed, but trackbacks and pingbacks are open.