Jason Silberman provides a humorous and unique take on the things that drive programmers crazy on a day-to-day basis.
As I said, how would you feel if someone was testing your code?
If you're a programmer like me, when washing up in front of the mirror normally every Monday, here are 5 things that will drive us absolutely crazy for the rest of the week at work.
NO.1 Emergencies always come suddenly like a flood
When you commit your code to the main repository, you suddenly feel like you are the greatest developer since Dennis Ritchie. You go over your code thoroughly (run it at least twice during the time you eat your breakfast cereal), and you're extremely confident that your program won't have any problems. You'll fire up your game with excitement, sip your coffee, and play as if you're on top of the world...until your email beeps.
In the product tester's reply, he said that he was not as simple as finding a bug, it seemed that every feature was faulty. You can only reluctantly say goodbye to the game at hand, and you will say goodbye to it for a long time.
NO.2 The refresh button does not play its role
You've only added a feature that you think will take a little longer to load. No problem, just add a refresh button. This will undoubtedly load faster when you hit refresh, but it's not. In fact, it takes longer. Your finger frantically hits the refresh button over and over again, and instead of getting better, more question boxes pop up.
However, your product testers are just waiting quietly for you to admit your mistakes.
Friendly reminder: Admitting is not a good choice. So, whenever this happens to you, use one of the following explanations:
1. This is weird, it has never happened before
2. Someone must have changed my code
3. You must be using the wrong version
4. It must be a hardware problem
5. It works fine on my computer
NO.3 Product testers raise the testing requirements to the extreme
Don't know if you've noticed that when a product tester starts checking your work, he or she suddenly becomes Flash for website navigation, and Flash is probably the fastest runner in the superhero world. But here, no one can click faster than a product tester. They'll click frantically on your site, cluttering it up in front of your eyes. No one uses your site like this, so is this really a test?!
Then again, if product testers don't hit your site quickly, testing through all sorts of incredible request actions, showing a bug in the console will be a long way off.
NO.4 Use antique-grade equipment for testing
OK, we all know the importance of making your site responsive. It should respond smoothly on desktops, smartphones and tablets. But do we really need to make sure our site looks good on a Nokia 3310 circa 2000? The kind that even my grandmother would blush in front of her buddies when she held it in her hand. I think only 0.0001% of the population using these devices would be a site bug (oh oh, did I say bug? I mean functional...)
NO.5 Making eye contact at the wrong time
You've completed a new requirement and have moved on to the next, and you're programming intently in your "territory" with a headset. But you suddenly think that there is a big bug in the previous code, and you look up, just in time to find that the product tester is watching you. You only need about 3 seconds before you hear that deadly phrase "Can you come here?"
At this point, no eye contact is required. Because you know you don't really have a need for completion.
Development and testing at the same time
To your surprise, I am now a developer of a performance testing platform. This platform allows you to test websites and applications under extreme load, and it can be used in every stage of software delivery. After a long period of testing, it has become an indispensable automated helper for product quality inspectors. As more and more development projects adopt continuous development and DevOps strategies, this is the tool you should have. As forward-thinking developers in 2016, we need to know that testing is an important part of the software development process, and we should count product testers as our friends.
To a developer who has always hated being tested, all I can say is "Sorry!"
Also to all the developers using our product, I apologize if my product drives you crazy, but remember you can find a solution to all your problems.
Obviously this article won't catch on most developers - I'm just emphasizing the value of testing and expressing my love for my work and concern for my friends. But I really want to hear what drives you craziest as a developer.
This article is transferred from: Programmer