5 ms·

The first, and non trivial, step, is noticing that you aren't doing it easy. I've been working in very tight spaces where I twist myself into pretzels trying t

The first, and non trivial, step, is noticing that you aren't doing it easy. I've been working in very tight spaces where I twist myself into pretzels trying to get at a particular spot, all while wrapped up in a homemade hazmat suit, to the point where I can hardly breath or see. It has gotten better after I established one rule: No Stress Positions. Meaning, do whatever it takes to get comfortable before proceeding. Before, if my back would start to hurt from a difficult stance, I wouldn't really notice, I'd just speed up to try to get it done before my back gave out, frequently botching the job and cutting or scraping myself in the process. Now, I notice that I'm breaking The Rule, think about the topology, reposition myself, maybe add cushions, maybe spend some time to move things out of the way. Fixup my mask and goggles, and then take my time. Before I'd only take notice of my discomfort on failure, when I just couldn't do it anymore. And that resulted in a strong desire to quit. Now I spend the effort to get myself in an "I could do this all day position", and I can do it all day. I think the same thing applies to washing dishes or making breakfast. First step, just notice that you aren't doing it in easy mode. It's summed up by the old Two Bulls on a Hill joke.

dsego 6y ago
Festina lente = make haste slowly. There's another similar saying, not sure about the translation, but something along the lines of "the longer way may be quicker than the shortcut".
- Jtsummers 6y ago
  Another saying: Slow is smooth, smooth is fast. Apparently from the US Navy SEALs though I didn't learn it from that context (best effort to recall my first hearing of it was my dad, who probably learned it in a military context as he was a USAF pilot). He also taught me the phrase "lazy man's load", in reference to trying to haul everything from the car to the house at once. Taking less each time reduced the risk of an accident (like dropping a bag of groceries or having the bottom tear out because it's not properly supported), even though it means more trips it (usually) produces the better result. Which also seems appropriate here, the lazy man's load is born of haste and is decidedly not the easy way in many, if not most, situations.
  - potta_coffee 6y ago
    Was going to say this too ("slow is smooth..."), this is a common mantra in the USMC and there's real truth in it. If you perform a task 10k times, slowly and smoothly, it will become muscle memory and speed will come on its own.
  - huge87 6y ago
    The same is true for a lot of performance stuff, like racing, or basketball. Basketball coach Phil Jackson writes that when you move quickly, do not hurry or rush. Don’t go so fast that you start making mistakes. In racing, “do easy” is even more applicable. Overdriving the car doesn’t find you much more lap time. The fastest, most consistent drivers are smooth. So yeah, “do easy” or “slow is smooth, and smooth is fast” aren’t as esoteric as they may seem at first.
- cassepipe 6y ago
  Related : "Sometimes you cut corners, sometimes the corner cuts you" From the movie : "How fast can you take your time?"
- zengargoyle 6y ago
  Practice slow, learn fast. Practice fast, learn slow.
  - dbtc 6y ago
    slow is smooth and smooth is fast
s3tz 6y ago
It goes for almost anything. I think a good way sum it up would be: Don't pretend it's something it's not. For whatever reason.
rubicon33 6y ago
How does one apply this "easy mode" to software development?
- zokier 6y ago
  Especially how do you avoid trying to boil the ocean while trying to "do easy"? I feel you could spend a lifetime to get truly comfortable, to not get constantly hit by small snags and papercuts.
- Jtsummers 6y ago
  TDD or other approaches which shorten the feedback loop, a bit of planning, selecting a task-appropriate language and task-appropriate libraries (either standard to the language or external), frequent refactoring. Don't spend a manic day writing 10k lines of code and only compiling it at the end of the day. Don't go in without a plan and develop the structure in an ad hoc fashion. Don't delay refactoring until after the first 100k lines are written. Ideally never even write 100k lines because you've selected an appropriate language and libraries to let you write something that closely matches the problem domain. Use templates/frameworks where possible for common activities. These don't even need to be heavy weight, but relates back to using libraries. If you're making your 100th CRUD site in some language and you don't already have a default structure, you're doing it the hard way.
- dkarl 6y ago
  Improve developer ergonomics. Standardize the boring parts of your projects. Simplify code. Fix flaky tests and flaky automation. Keep a calm, steady frame of mind, so you have a more uniform appreciation of time passing. Don't fall into a busy frenzy or a puzzle-solving trance that allows a haphazard or complicated way of doing things to feel quicker than it really is. Don't let boredom blind you to the virtues of smooth, simple things. A common mistake people make is identifying boring, predictable tasks as the most urgent focus for improvement. This is misguided. A task that is boring and predictable is already well-engineered. It can and should be further improved by automation, but much bigger gains come from standardizing the tasks that seem to go differently every time, the tasks that are typically handled by the most experienced developers. Making an "interesting" task boring saves much more effort than the subsequent step of automating it.
gypsyharlot 6y ago
Excellent advice! Thank you for sharing

dsego 6y ago

Festina lente = make haste slowly. There's another similar saying, not sure about the translation, but something along the lines of "the longer way may be quicker than the shortcut".

Jtsummers 6y ago
Another saying: Slow is smooth, smooth is fast. Apparently from the US Navy SEALs though I didn't learn it from that context (best effort to recall my first hearing of it was my dad, who probably learned it in a military context as he was a USAF pilot). He also taught me the phrase "lazy man's load", in reference to trying to haul everything from the car to the house at once. Taking less each time reduced the risk of an accident (like dropping a bag of groceries or having the bottom tear out because it's not properly supported), even though it means more trips it (usually) produces the better result. Which also seems appropriate here, the lazy man's load is born of haste and is decidedly not the easy way in many, if not most, situations.
- potta_coffee 6y ago
  Was going to say this too ("slow is smooth..."), this is a common mantra in the USMC and there's real truth in it. If you perform a task 10k times, slowly and smoothly, it will become muscle memory and speed will come on its own.
- huge87 6y ago
  The same is true for a lot of performance stuff, like racing, or basketball. Basketball coach Phil Jackson writes that when you move quickly, do not hurry or rush. Don’t go so fast that you start making mistakes. In racing, “do easy” is even more applicable. Overdriving the car doesn’t find you much more lap time. The fastest, most consistent drivers are smooth. So yeah, “do easy” or “slow is smooth, and smooth is fast” aren’t as esoteric as they may seem at first.
cassepipe 6y ago
Related : "Sometimes you cut corners, sometimes the corner cuts you" From the movie : "How fast can you take your time?"
zengargoyle 6y ago
Practice slow, learn fast. Practice fast, learn slow.
- dbtc 6y ago
  slow is smooth and smooth is fast

s3tz 6y ago

It goes for almost anything. I think a good way sum it up would be: Don't pretend it's something it's not. For whatever reason.

rubicon33 6y ago

How does one apply this "easy mode" to software development?

zokier 6y ago
Especially how do you avoid trying to boil the ocean while trying to "do easy"? I feel you could spend a lifetime to get truly comfortable, to not get constantly hit by small snags and papercuts.
Jtsummers 6y ago
TDD or other approaches which shorten the feedback loop, a bit of planning, selecting a task-appropriate language and task-appropriate libraries (either standard to the language or external), frequent refactoring. Don't spend a manic day writing 10k lines of code and only compiling it at the end of the day. Don't go in without a plan and develop the structure in an ad hoc fashion. Don't delay refactoring until after the first 100k lines are written. Ideally never even write 100k lines because you've selected an appropriate language and libraries to let you write something that closely matches the problem domain. Use templates/frameworks where possible for common activities. These don't even need to be heavy weight, but relates back to using libraries. If you're making your 100th CRUD site in some language and you don't already have a default structure, you're doing it the hard way.
dkarl 6y ago
Improve developer ergonomics. Standardize the boring parts of your projects. Simplify code. Fix flaky tests and flaky automation. Keep a calm, steady frame of mind, so you have a more uniform appreciation of time passing. Don't fall into a busy frenzy or a puzzle-solving trance that allows a haphazard or complicated way of doing things to feel quicker than it really is. Don't let boredom blind you to the virtues of smooth, simple things. A common mistake people make is identifying boring, predictable tasks as the most urgent focus for improvement. This is misguided. A task that is boring and predictable is already well-engineered. It can and should be further improved by automation, but much bigger gains come from standardizing the tasks that seem to go differently every time, the tasks that are typically handled by the most experienced developers. Making an "interesting" task boring saves much more effort than the subsequent step of automating it.

gypsyharlot 6y ago

Excellent advice! Thank you for sharing