As a tester I got a reputation for breaking things. I was always impatient, and would multi task ( use two windows) when one of the tools was slow.

We had to use a new tool for entering what you had achieved over the year. Because there was no save button, I assumed, like Gmail, it had autosave. I submitted it to my boss who said it was empty.

I did it again...and again it was empty.

I contacted the help desk, who asked "did you press the save button?" me:"I don't have a save button"... "Did you press the help button ?" "I dont have a help button"

If you run the application full screen, all of the buttons appeared, if you run it in a narrow window, all of the buttons disappear.

With all of their testing they naturally used full screen, so naturally didn't find any problems.

I had a call with the development team, and mentioned the 50 "defects" I found. Such as

me:"there is an icon with 3 small circles - what does it mean? There is no hover text, and it is not mentioned in the help"

them: "It is meant to be obvious...",

me "well it has failed - so what does it mean".

them: "err we don't know"

me:"The fonts you use are not dyslexia friendly, and the fonts are too small and not changeable"

them "Err"

me: "Grey text on a grey background is not easy to read in a well lit area " ....

A laptop with a small screen was always in my arsenal. I used to run on a large screen and the small screen concurrently and see that they had the same functionality. Surprisingly not in many cases, as demonstrated by the OP above!

This is a pattern that Micros**t could do with adopting!

They tried making things always full-screen with Windows 8

I can foresee a new hardware requirement: minimum 42" 4k screen.

me: "Grey text on a grey background is not easy to read in a well lit area " ....

All testing should include it being used by someone ancient, like me, who no longer has 20 year old eyes.

I look forward to those arseholes finding that they have to live in the world they have created.

I know a guy who works as a tester, and is quite proud that he can break things, and find flaws where others cannot. Isn't that, erm, part of your job?

Speaking of breaking things, much of my working life has gone as follows:

Me: "Hey boss, come and look at this cool thing I've wrote, which I've tested and works perfectly"

Boss: (looks at software)

Software: (boom)

The Curse of the Demo. Strikes every time!

Or the break-everying force field some people seem to carry.

I remember a student whose usual greeting was "wanna hear a tale of woe?"

It's known as Cohen's Law, a subset of Murphy's Law

"If it can go wrong, it will at the demonstration", as was so publicly illustrated at the Windows95 launch.

He didn't need an X-Ray to diagnose this one

Although he immediately saw through it.

Make a system fool-proof, and life will produce a better fool

I happen to like to write documentation. Beware: this is a very frustrating or very rewarding activity. You've been warned :)

So many times, even today, I have the following situations:

- be in a meeting with someone I've sent the doc to (that never fed back on it) that asks a question, showing blatantly he's read 0 page of the doc, to which I reply "yes, it is in the documentation", to which he embarrassingly replies "ah yes, yes ..." in a tone that leaves 0 doubt to anyone in the audience

- be in a meeting with someone I've sent the doc to (that never fed back on it) that asks a question, showing blatantly he's read 0 page of the doc, to which someone else, who was not in the dist. list and didn't have an immediate need/role in reading this, in the meeting, interjects "it is in the documentation !). This is priceless, rare but priceless.

And you've clearly learned 0 about reality. What was that popular definition of insanity again?

Premonition of our new AI golden age?

Having read many "fine" manuals, I can understand why many users give up on principle before starting. The idea that introductory documentation should concentrate on leading the new user through the basic and common operations, seems to rarely occur to the documentor.

K&R The C Programming Language 1/e this point was brought home to me in the late 1970s where the now legendary program containing printf( "hello, world\n") appeared on the first page of chapter 1, without a long digression on the intricacies of the printf family or variadic functions in general.

The UNIX seventh edition documentation was very similar, so I imagined was part of the cultural DNA of Bell Labs.

Sadly my copy of K&R was decluttered recently, it was invaluable many years ago when I wrote a simple quotation system from scratch for the Unix box we then had - I knew programming but not C.