QA Anarchist - How starting off in QA improved my code

About ten years ago I started working for a gaming company. Being a gamer myself, I was pretty excited and played the game constantly.

As any gamer would find out after playing for many hours, there are many bugs even in the most popular games, so did our small game.

So I started sharing those bugs I saw with my employers, even though I came to work there as a Frontend developer (Webmaster).

After some time they had to let the QA guy go, being a small company they didn't want to hire another guy for that and offered me to split my time between web development and QA. I accepted immediately.

Upon starting as a QA, we had many support tickets a day, mostly about bugs.
I scraped the old methods of QA, and made some new testing plans, combining traditional manual QA of common actions, as well as going wild on it.

I quickly realized those edge cases I found by going crazy with our application, were actually legitimate scenarios, we just didn't realize how common they were. The amount of daily support requests we have received has been reduced significantly after some months, even though we were getting more and more new customers.

It did come with a price, the backend developers didn't like it, as they had to rewrite much of their code. I saw the frustration they experienced, and didn't want to be that kind of frustrated developer.

That experience changed everything for me. I realized, that in order to be a happy developer, I need to find the methods of avoiding this kind of situation, having many bugs in my code, having to go around fixing a long depressing list of bugs.

So the idea was this: why won't I continue to act as the QA I was before, even though I am a full time developer now with another employer? And so, before writing a single line of code, I had to go in my head through the process of bombarding it with craziness. For example: many clicks, extreme actions repeatedly, moving quickly, doing uncommon actions on the page, as well as the normal flow of user behavior.

The big revelation here was that those extreme stuff, were usually related to normal stuff people do, they just exposed flaws easily.

Every single line of code, is always being carefully designed by the architect developer in my head and paper, and then the QA Anarchist side starts his rumble. How can I tear it all apart? Break every piece of this code? How can one hack this code and use it against me? Then I go on improving my code design to prevent those issues.

After a few iterations, you find a code that is much more durable and requires far less maintenance in the future. The QA people I worked with were very happy with this, getting a code that was actually properly tested before coming to the QA, they had to work much harder to find issues in my code.

You see, many developers don't even spend time testing their code. This is a very bad practice: some things slip from the QA's eye, and next stop is your customer. Sometimes a small mistake can cost the company millions, only because you didn't test your code.

Having the QA Anarchist in my brain is the best gift I have got in my career, and it served me well everywhere. I advise you to adopt this method, for a better code and less frustration in development, as well as happier bosses.