I think laziness and impatience have always been listed in a sort of tongue in cheek way. Patience is probably the single most important attribute a programmer can have, many '10x' engineers are just the people who have an unshakeable ability to step through boring code for 4 hours until the problem reveals itself.
Laziness pays off for me when I argue for simpler requirements and paring down of features on things. It results in a better end product but most of my motivation was that I just didn't want to build all the stuff!
Early career my boss spent all day running reports. Like 7 hours a day. All hand edited excel files. Dozens of them.
She went on vacation and I had to learn how to make them.
She cane back to find everything automated.
Like heck was I going to spend all day every day building reports. Soo boring.
10x engineers are a thing. But you have to be pushy to keep it up.
Way to many people setup pipelines that require “effort”. Efficiency suffers. They always get more done in a short period. But so much less in the long run.
Did you ever stop and think you ruined your bosses job for her?
She came back ready to grind out another year and you've free'd her of her job so she can have new an exciting uncertainty with nothing to do.
I assume this is written tongue in cheek, but I have worked with people who legitimately feel this way. I have had quiet parking lot conversations about how "all this automation business" was going to replace work they knew how to do and could do with half a brain while listening to books with work that required them to learn new things. The horror.
Long-term, statistically, sure - but there are real consequences to people losing their jobs over automation, in that the skillset they built up over the years has suddenly become useless. They usually do not grow into a higher position, instead they have to find something else, take a pay cut, or end up unemployed and part of the statistics.
So yeah, on a macro scale there is no evidence that automation causes job loss, but on an individual level it definitely does. It's personal tragedies. What would you do if you lost your job because a system took over? What if you're in your fifties and you find your ability to learn new things is severely diminished? What if you're that age and employers won't hire you because there's people younger, smarter, more energetic than you, or a machine can do the job you're applying to?
Took some positions I wasn’t comfortable with so I would be forced to learn again.
It was many months of pain. But I’m now super in demand now despite my age.
Certainly meet lots of people that learn a skill that’s not in demand.
Heck, I have daily talks with daughter about having a backup option aside from “trick riding”
Laziness to me is thinking "Eh this doesn't need tests" or "It might be possible to break it this way but I doubt anyone will try that"
What people seem to mean by it is the ability to stop and think "This task is repetitive and tedious, we are passing the threshold where writing an automatic solution is faster than manually completing the task" I'm not sure what word would really describe this though "Efficient" probably.
I think it is laziness, but the appropriate kind. I am willing to work harder now, in order to be lazy later. I am so lazy, I do not ever want to manually test a function. Therefore, I write automated tests to enable my laziness. I am so lazy, I do not want to remember caveats on how a function works. Therefore, I do my best to make an interface be hard to use incorrectly.
Well this kind of laziness seldom comes at an advantage in the modern workplace? I mean there's always more work so working hard now doesn't equate to working less later. Unless you're an entrepreneur building your own product.
Sure it does.
If you work with people who don't automate then every time you finish a piece of automation you can slow down your pace a little and still be faster than the people doing stuff manually.
The thing with tests is that the effect is indirect, and you won't really realize how much time is not wasted down the line.
That time could apply to your whole department / the people you work with. In worst cases, that time is saved by there not being a rewrite of the application down the line.
(disclaimer: I'm currently rebuilding an application because the existing codebase is a mess, a web-based UI built in mid-2000's technology in the 2010's by a C developer who never seems to have learned basic code quality / craftsmanship or web development practices. It can probably be salvaged but it'd a lot of work (160KLOC) with little gains compared to rebuilding it in a modern stack)
Change that to "This task is repetitive and tedious, we are passing the threshold where writing an automatic solution is more work than manually completing the task"
I write tests when I'm fed up with manually testing. I continue writing tests into the next program, because I'm still fed up with manually testing.
A caveat though is that I despise working on anything UI related, because it's hard to test and I despise manual testing. But that's when I delegate :-)
But thats also why its not just laziness, but lazy and intelligent -- the lazy and dumb man finds no solution, and simply drops the ball, because he's too lazy to do it.
The lazy and smart man is too lazy to do it, and gets away with it
For the later part, I think "tires of tedium" is maybe what we mean? I mean, I might actually prefer writing more code even if it takes a little longer than doing the dumb task.
An early CS professor I had used to always say "a good programmer is a lazy programmer", because there are already so many well written and tested tools available. This was long before the current days of JS dependency bloat, but his position came from a strong UNIX background and he wanted us to be thinking about tools at our fingertips like grep, sed, awk, etc. instead of reinventing those fantastic tools from scratch.
Master Foo once said to a visiting programmer: “There is more Unix-nature in one line of shell script than there is in ten thousand lines of C.”
The programmer, who was very proud of his mastery of C, said: “How can this be? C is the language in which the very kernel of Unix is implemented!”
Master Foo replied: “That is so. Nevertheless, there is more Unix-nature in one line of shell script than there is in ten thousand lines of C.”
The programmer grew distressed. “But through the C language we experience the enlightenment of the Patriarch Ritchie! We become as one with the operating system and the machine, reaping matchless performance!”
Master Foo replied: “All that you say is true. But there is still more Unix-nature in one line of shell script than there is in ten thousand lines of C.”
The programmer scoffed at Master Foo and rose to depart. But Master Foo nodded to his student Nubi, who wrote a line of shell script on a nearby whiteboard, and said: “Master programmer, consider this pipeline. Implemented in pure C, would it not span ten thousand lines?”
The programmer muttered through his beard, contemplating what Nubi had written. Finally he agreed that it was so.
“And how many hours would you require to implement and debug that C program?” asked Nubi.
“Many,” admitted the visiting programmer. “But only a fool would spend the time to do that when so many more worthy tasks await him.”
“And who better understands the Unix-nature?” Master Foo asked. “Is it he who writes the ten thousand lines, or he who, perceiving the emptiness of the task, gains merit by not coding?”
Upon hearing this, the programmer was enlightened.
Yup, sounds like the "not invented here" adage; it's good that there's multiple ways that the same concept is explained.
Of course, as a developer you need to know tools exist and how you can use them to solve a specific problem, and to have the patience to not go coding right away but do a bit of research first.
I wonder the distribution of patience among age. I used to be impatient, but so fast I could get progress even without careful plans or observations (basically I was a chaos monkey iterating 10x faster than average until I covered a lot of space and found a trick).
I love patient now, being old deprives you of sprinting wild.. you know it's the fastest way to paint your self into a corner.. that said full patience leads to boredom often. You need a pacing agent.. or a balance between observations, hypothesis and tests.
> many '10x' engineers are just the people who have an unshakeable ability to step through boring code for 4 hours until the problem reveals itself.
I dunno, to me the '10x' developers are the ones that tackle the big problems, whilst letting the common folk take care of the actual implementation and nitty-gritty. Maybe I'm confusing it with architects/CTO's/lead developers though.
Eh, stepping through code for hours is a pretty inefficient debugging technique, so a properly lazy programmer should probably be thinking about why their system's diagnostics suck and if there might be a way to improve them. (I mean, I've done it, but then again I'm not a 10x engineer.)
At the end of the day if you can be very diligent, even when its so boring and tedious, you are a valuable programmer. Maybe not the best, but it will take you very far.
Laziness pays off for me when I argue for simpler requirements and paring down of features on things. It results in a better end product but most of my motivation was that I just didn't want to build all the stuff!