Perhaps the story is apocryphal, but I think there is a grain of truth in the story. Managed properly, laziness can benefit the company. The problem you run in to is that lazy individuals are difficult to manage properly. A company isn't going to realize the benefits from a lazy individual if they aren't permitted to find their own solution to problems, and the shortcuts lazy individuals take can be dangerous depending on what shortcuts they are taking.
I wouldn't want to work for a company that is willing to fire someone for not doing anything for six years because you wrote a script that did basically everything. It implies they value the effort pertaining to my work rather than the actual output, which is insane. That just reeks of terrible management.
That being said, I don't want to imply that all lazy people make great employees. I've definitely worked with people who were just completely unwilling to do anything but the bare minimum, if they did any work at all. I don't think individuals who actively avoid all work without coming up with an alternative are of much use to any organization.
1) The smart and lazy---they'll find the easiest way to do the job (or automate it).
2) The dumb and hardworking---you an tell them what to do and they'll do it exactly how you tell them to.
3) The dumb and lazy---they won't help, but they won't necessarily hurt either (just the bottom line).
4) The smart and the hardworking---terrible combination.
I actually have experience with the fourth type of person. Twenty years ago I was doing some consulting work for a bank and had to convert a printed training manual into HTML (mid 90s). The person helping me was very smart and hardworking. I'm smart, but a bit lazy. I had to argue with the person not to dive into one process (linking each word in the text to an entry on the glossary page) because it would take hours to do by hand (around 100 files, perhaps 100 vocabulary words). We actually argued longer than I took for me to code up the solution (using lex---we were working on a Unix system).
There's a running joke at work that under no circumstances should someone complain to me about a problem, because I will drop everything to discover the cause of the problem, and then 2 days later the entire process will be rewritten. Everyone else thinks I'm working myself to the bone, but I'm rewriting processes that used to take several days to complete so they only take a couple of hours, and the computer does most of the work without input. In my mind its perfectly lazy, because it means I don't have to walk anyone through the procedure or fix any problems caused by humans gumming up the works.
Plus, it feels so good to say "What does the text next to the button say?" When someone calls to ask what they should do next.
I have a theory that most programmers are lazy, because a certain kind of lazy person goes "I'm sure there is a better way of doing this." and then that person goes on to figure out how. The only problem is that sometimes that type of person can get sucked into learning a new framework when they could have used the less efficient framework in the first place and already have been done.
I'm disappointed it took them 6 years to act on it.
Honestly I've had times on one of my jobs where I just had to kill time all day and I hated it. It's one of the reason I later decided to leave.
What's scary is the people who actually have been coding for several years and still don't know how to do it. No version control, no idea what common patterns are, ridiculously complex spaghetti code. We all know them.
Also, I wonder how IT eventually found out.
"I got a job at a company in the Bay Area, CA that was completely unknown 7 years ago but is now incredibly well known. It is actually quite hard to get a job here now, from what I hear."
I'm not from the Bay Area, so I can't think of a company (other than Facebook) that fits that profile.
Least amount of non-automated work for the most amount of pay off, I respect it.
So I am guessing if he was actually a developer to begin with his job would have been a bit harder to automate.
The continual disrespect for QA engineers is somewhat frustrating.
> I got a job as a software developer working mostly on testing software, so mostly QA work. However I actually had to write some code as well. After around 8 months I had basically automated my own job by writing some programs to do it all for me.
It certainly doesn't look like a manual QA job.
The part that surprises me is that the tests didn't change for six years. Surely after 6 years something about a codebase changes (the build infrastructure changes, a new platform shows up, the API changes, etc.) that even black-box testing would have to adapt. Did the company not care that much about the accuracy of the tests?
Seems like he 'fell through the cracks' of startup culture. The company grew so fast that he was just there and no one questioned it after a while and no one was in charge of him.
Or someone was and they need retraining/firing.