A programmer walks into a bar, checks his bank balance, checks his blood-alcohol level, checks his stomach capacity, checks the menu price, checks for bartender availability, checks for open seating, and orders a beer.

A tester walks into a bar and orders a beer. Then orders 0 beers. Then orders -1 beers. Then orders pi beers. Then orders 2.2 billion beers. Then orders 1 cerveza. Then orders an aircraft carrier. Then changes the programmer's beer order to 2 beers. Then cancels an order for a beer. Then flips the calendar back to 1980 and orders a beer. Then flips the calendar to 1925 and orders a beer. Then sets the clock to 23:59:45 and orders a beer....

Those bar jokes represent not only different skills, but different stereotypical personalities. The builder-programmer has to be cautious, methodical, and well structured, whereas the tester has to channel the spirit of the chaos monkey to find something that no one else ever expected.

I tend to agree, I'm a developer/programmer for the most part but I have also been involved in writing automation testing infrastructure, mostly within the games industry and being responsible for leading automated testing. I think the author is correct to point out that there is frustration with testing, I think this is a real problem and just getting team members to write tests can be a herculean task (from exhaustive experience), but it's not just because testing is necessarily a different skill, it's because most people don't enjoy it and don't feel it will be appreciated. When you make a product code change you (and everyone you work with) can immediately SEE the impact. It's highly gratifying. Often with testing, and talking specifically about automated testing here no one even knows you wrote a test, the lack of visibility makes people less want to do it. Especially within an organization where highly visible changes are incentive for career development. This is a problem because having automated testing and doing it right has a huge impact on quality and development time. Being without this brings down everyone in a silent/invisible type of way where there is a lot more firefighting and protracted development time.

I helped found Tesults (https://www.tesults.com) and one of the main reasons it exists is due to some of mine and others' experience working in automated testing. It makes automated testing highly visible across a team. When someone writes a test, everyone sees it, you also see how often the tests run, across various branches, platforms and build flavors. You then get all of the benefits of aggregated test results reporting. Once you have this running you cannot imagine going back to automated testing without having it because it feels like you are flying blind. It is undergoing rapid feature development as it is only a few months old but we have companies of various sizes using it and if it looks interesting to you feel free to contact me if you have any questions. We are adding screenshot and log file uploading soon. Some dev teams invest so much into their automation infrastructure including writing test hooks, writing test case strategies, adding and maintaining test scripts, setting up and configuring continuous integration systems, only to treat results reporting as an afterthought without realizing that the data being generated is valuable and they fail to make the most of their time and investment into the automation.

> Most people (at least myself) got into coding because they enjoy creating something from nothing. Maintaining and testing code is boring because it doesn't really do anything new, it's mostly fixing edge cases.

A good testing setup can be an alternative to redundant manual testing. This can really help speed up the creation process (for me, at least).