Comment by hirundo | Hacker News Reader

Comment by hirundo | Hacker News Reader

Parent Full thread

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.

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".

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.

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.

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.

Practice slow, learn fast. Practice fast, learn slow.

slow is smooth and smooth is fast

Related : "Sometimes you cut corners, sometimes the corner cuts you"

From the movie : "How fast can you take your time?"

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

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.

First, I agree. Second, I don't know if I would call it a mistake as much as non-optimal.

I would say that getting the boring & predictable ones out of the way frees you from keeping them in mind. This allows you to address the ones that "go different every time" without keeping track of the details.

Removing the boring/predictable stuff also means you can enter flow much more quickly (and regularly). I find that for me programming is more of a psychological game than a technical one. The ability to quickly get into flow is of very high value to me. However, in other domains and with other people "standardizing" the "offbeat" task may yield greater productivity gains.

XKCD made a comic about automating task -> https://xkcd.com/1205/

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.

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.

Use the same tools year after year.

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.

Excellent advice! Thank you for sharing

Reply on news.ycombinator.com