I've reached the age where the triathlon that Ben describes is quite beyond me, in fact I doubt if I could do any one of its three parts although I would have been able to do it 50 years ago (the swim would have been easy, the run would have been work, and the bike would have been a pain because I hated cycling, but I could do it). Eleven years ago, when Ann and I first bought our house over here in Puerto del Carmen, I heard there was an annual triathlon here and had a look to see if I might be interested; I discovered that it was way beyond me, and I couldn't have done it even when I was young and fit. The swim is 3.8km (I could probably have done that in 1962, if I'd possessed a wet-suit), the bike is 182.2 km and is pretty hilly (with total height gain and total height loss each just over 2.55 km - the route and altitude charts are at http://eu.ironman.com/~/media/bdb433c2361d4d34877e067675264db6/map%20bike%202017.pdf) and would have been totally beyond me anytime in my life, and the run is 42.2km (a standard marathon) over fairly flat terrain (total height gain and loss 259 metres) which I might have been able to jog when I was young and fit but certainly couldn't ever have run. I guess it's a triathlon for real athletes.
I don't object to a bit of hard work (or even to a lot of hard work, in fact) but I do object to pointless hard work. There's a lot of pointless hard work in the computing game, sadly. Someone decides to do a new product the hard way and ends up spending 20 man years when the product could have been done the easy way for 4; of course than means that 5 times as many people have to be working on it at the same time so as not to make the availability date too late. That's somethong over an extra 2 million pounds in development cost (including overhead) perhaps quite a lot over depending on the company. The resulting product is a bit of a mess - it's hopelessly complex, bug-ridden, slow, and has a foul UI. So it costs a lot more in customer support (first line, second line, and third line) than it would if done the easy way - there goes an extra million pounds a year in support costs. The customers don't like it, they are fed up with bug after bug, they are fed up with the poor response from support, and the company's reputation takes a dive; some customers drop this supplier and turn elsewhere; some non-customers who were thinking of becoming customers see the reputation damage, maybe see existing customers departing, and decide to go elsewhere; so growth stops and revenue takes a dive. That's the cost of doing it the hard way, and it can be the beginning of the end for a company.
This can happen when some know-it-all "solution architect" (or pick your own choice of buzz-title) decides to impose a "clever" architecture on something and claims it will reduce the work, not increase it; it can happen when a development insists that a product intended to run eventually on several platforms must run on all platforms at first release instead of getting it working for the main market first and adding the other platforms later; it can happen when some know-it-all manager insists that all code be done in assembler "because that will give better performance" when in fact the appropriate language is Common Lisp, or C, or Fortran (I haven't seen the "everything must be assembler" idiocy in the last 45 years, but maybe I'm just lucky, because I saw it a few times before them; but I've seen the "nothing can be assembler" version - which is equally stupid when it creates extra hrd work - a couple of times since then) - these are all cases where someone is deliberately choosing to do something the hard way instead of the easy way. Perhaps my favorite example is when someone decides not to normalise to 2NF (or higher) because all those extra constraints and joins will make it run slower, forgetting that being in 3NF (or EKNF in the rare cases where 3NF doesn't imply EKNF) will remove a lot of code that will otherwise be needed to check those restrictions and ensure that anomalousa large class of invalid data can't be inserted into the database (and if he thinks about it at all decides that, like normalisation, such code in the database is pointless as it can all be checked in the C++ application, after all that's the language real code is written in and which ought to control what is and isn't allowed). Last time I saw that (or actually the aftermath of that) was in 2002. There's a lot of hard work as a result and the end result can be that the company goes broke, the product has to be scrapped, or a lot more unwnted hard work has to be done to escape from the mess - any of which means a vast financial loss.
So let's not encourage hard work just because it's hard work, let's encourage instead what I call constructive laziness and Gary's professor called efficient laziness.