“I divide my officers into four classes as follows: The clever, the industrious, the lazy, and the stupid. Each officer always possesses two of these qualities. Those who are clever and industrious I appoint to the General Staff. Use can under certain circumstances be made of those who are stupid and lazy. The man who is clever and lazy qualifies for the highest leadership posts. He has the requisite nerves and the mental clarity for difficult decisions. But whoever is stupid and industrious must be got rid of, for he is too dangerous.”
"Gilbreth studied the methods of various bricklayers—the poor workmen and the best ones, and he stumbled upon an astonishing fact of great importance and significance. He found that he could learn most from the lazy man!"
"Most of the chance improvements in human motions that eliminate unnecessary movement and reduce fatigue have been hit upon, Gilbreth thinks, by men who were lazy—so lazy that every needless step counted.”
"Another important thing Gilbreth noted was that the so-called expert factory workers are often the most wasteful of their motions and strength. Because of their energy and ability to work at high speed, such men may be able to produce a large quantity of good work, and thus qualify as experts, but they tire themselves out of all proportion to the amount of work done."
I got an interesting personal education on this working on some volunteer construction projects down in Mexico. The locals all move with a very deliberate slow pace. Us gringos tried to be more gung ho, and by 11 am the heat plus our effort had destroyed us. Meanwhile the local folks just kept on truckin' until sunset.
Sustainable Pace is one of those good buzz-terms to throw around - sure you can be fast, but is it sustainable?
It's a good attitude to have in life and work as well - sure, you can do 16 hour binge working days, but for how long can you sustain that? Can you keep that up until retirement, whenever that may be? Is it worth it?
I believe life forms are optimizers .. survival means spending the least amount (according to our mental representations but bodies are a major source of data).
Then there's lazy and defeated. I'm so not the same as my colleagues who are lazy .. they know what is useless to a point and avoid the work. I have a fundamentally different approach (from computing, food shops and industry). I aim at minimizing work AND maximizing flow. It makes my processes very different because I remap the task and attack many paths to find the most enjoyable one. The other lazies don't dive in the task they just take the simplest path and do it slowly.
This is a cute quote, especially if one's difficult decisions involve letting other men do the actual work.
It does not really apply to software, where most good programmers are obsessive and hard working. Yes, that also applies to Lisp, where someone has to write the actual interpreters and compilers that others use to run their 100 macros on and pontificate how easy everything is.
It applies to technology organizations though. I think being a smart engineer is very important when making architectural decisions -- but this is not always the bulk of the actual work. Lazy people tend to want to minimize total effort of the organization too.
Come now, I think we all know code is not its line count.
1000 lines of clear code in a mission-critical place is worth far more than a 1-liner which accomplishes the same task and only one person in the company understands...
I've yet to see 1,000 (or even 100, and rarely 10) lines of code doing what could be done in a 1 liner that is both clear and correct, and generally the more verbose, the less clear and the less correct it is.
Moreover, the longer version almost invariably (and more likely the longer it is) either is or contains a DRY violation that was originally copy-and-pasted from elsewhere in the same codebase, often with some intentional changes, which has since diverged (or diverged further than the intended differences) because of inconsistent maintenance.
It's not line count, it's the dot product of line count and conceptual clarity.
There's a sweet spot where code is as terse as it can be while still being easy to read. The abstractions are clear and fit the domain, they're not decorated with poorly configured edge cases, and they're no more nested than they need to be.
It's debatable if this ideal has ever existed, but it's nice to believe it might be possible.
> It's not line count, it's the dot product of line count and conceptual clarity.
In my experience, in practice, beyond a very small multiple of the minimum required line count, line count and conceptual clarity for perfoming any given task are inversely related.
Also, neither of those are vector quantities, so I'm not sure what you are trying to get at with “dot product”.
Citation needed. This is a popular narrative but I don't believe it; line count is the only thing that has been shown to be consistently correlated with bug count.
Without consulting Stack Overflow, describe the “...” operator in Perl.
As for other one-liners, when the one line is actually five instructions squished together inside a ternary operator, you’re probably better off expanding it to an if statement and consuming ten lines of vertical space.
Clarity is far better than terse code that suffers from leaning toothpick syndrome.
> Without consulting Stack Overflow, describe the “...” operator in Perl.
I don't know Perl. But I'm prepared to do that exercise for APL if you want.
> As for other one-liners, when the one line is actually five instructions squished together inside a ternary operator, you’re probably better off expanding it to an if statement and consuming ten lines of vertical space.
That's exactly what I'm disputing. We know that bug count correlates with line count, and that the chance of bugs increases greatly once a function or class no longer fits on a single screen. So I suspect that squishing five instructions together inside a ternary operator actually makes for fewer bugs.
Whereas I have seen too-smart people creating bugs by cramming things into one line because the brevity required means you end up with hard-to-visually-parse clusters of brackets, braces, and whatever other punctuation your chosen language allows (is that a minus operator, is it negating a value, or is it a range in a regex?).
Bugs are correlated to line count because code complexity drives line count and bug count.
It’s not the number of lines of code causing the bugs, it’s the complexity of the problem causing the number of lines and number of bugs to grow independently of each other.
> We know that bug count correlates with line count
Statistically maybe, but when it comes down to it, clear code > compact code hands down.
Paraphrasing, but there's basically two ways to write code: either it's so complicated there are no obvious deficiencies, or it's so simple there are obviously no deficiencies.
I'm not smart enough to be able to read and understand a nested ternary or other examples of clever / compact code.
> Paraphrasing, but there's basically two ways to write code: either it's so complicated there are no obvious deficiencies, or it's so simple there are obviously no deficiencies.
Anyone who's seen an enterprise Java codebase knows there's a third way: so verbose that no-one can tell whether there are any deficiencies, even if each line in isolation is "simple".
I think we vastly underestimate the importance of sheer code length. Being able to comprehend the function, class, or program as a whole makes a lot more difference than whether nested ternaries or the like were used, IME.
And yet most Perl programmers I know do not work in mailing houses so they have never needed to use “...”.
I have worked with brilliant people who still have trouble figuring out the ternary operator, and people who should know better who construct ternary operators with five levels of parentheses, causing deciphering of the intent to be impossible.
So I choose Alexander the Great’s approach to solving the Gordian Knot: slice it open and remove the complexity to multiple layers that mere mortals can understand.
PS: I notice you failed to explain the operator yourself. Minus five points to Slytherin.
Indeed. That was because smart-matching in Perl was symmetric.
The smart-matching in Raku (formerly known as Perl 6) is asymmetric and customizable. If you write:
a ~~ b
you are effectively executing:
b.ACCEPTS(a)
In other words, the right hand side of the smart-match is responsible for accepting the left hand side. So as a developer of a class, you can add your own ACCEPTS (multi-)method to govern how your class will handle smart-matching.
Besides, in your very implausible example (unless there's some underlying library - or an esoteric language maybe?) 1 line of that code (apparently) replacing 1000 line of clear code can have a comment to explain itself.
General Kurt von Hammerstein-Equord, probably