What Is Hammock Driven Development? | Hacker News Reader

What Is Hammock Driven Development?

stokoe.me

49 pointsyogthos30 comments

> Be discerning, be critical. Not everything is awesome, and it doesn't have to be

Having worked as an outsider with Americans and of course the heavy American influence on the tech scene in general, this one piques my interest because it can lead to some product blindness even in small teams.

I'm obviously generalizing in order to discuss the stereotype, but I find there is a habit of Americans to overstate how awesome everything is and how great it is that you did it, and then one day you find out it's not great and it never was. This affects your ability to make good decisions and deliver good results, because feedback is your touchstone with reality and client needs. If someone tells me it's awesome, job done, I stop working on it. If someone tells me it's no good, I fix it. If it's not perfect and you tell me it's awesome, I still stop working on it, because I figure it meets your needs and the job is done.

I had this in Japan too, everything was great and nothing was bad, food was always considered the best thing ever. I do enjoy the endless optimism and positivity for general living, but it can cause issues when you're trying to deliver a great product.

When working with Americans the rest of the world has to recalibrate their sensors :)

When an American says something is "awesome" or "revolutionary", it's usually just another day in the office.

Exactly. At first I thought it was just a thing in the U.S. movies, but when I had to work with american people (I'm european) that was a shock: they're like in the TV series, grandiloquent and enthusiast and ready to applaud at each boss's speech. Personally I enjoy it, it adds fun in the workplace, but you have to not take it seriously otherwise it messes your expectations, just as you said. It's been the same when working with other cultures, like indian or asian people; you have to adjust and not take everything at face value.

Some years ago I was checking into a hotel somewhere in the US. The clerk's standard reply seemed to be "awesome", no matter whether I had just given my address or stated the number of nights we'd be saying. It took some work to keep a straight face.

Some words have definitely lost their weight. Or maybe your address was truly awe inspiring.

I think this is a product of the dominant echelon-based corporate culture. People get promoted from above, which typically means they get promoted by making their boss look good. Regardless of how good a job a manager is actually doing, if you can pretend like everything under their purview is an act of brilliance, they'll make sure you stick around.

This is why you end up in meetings with half the comments being about how "awesome" it is that somebody added a search box to a results page...

So basically, "more idle time" equals better problem-solving

...which I agree with wholeheartedly. Never underestimate the value of sleeping on, gaming to, or hammock-ing a problem in order to solve it.

More idle time when in a primed state.

This, I think, is very key. You take the problem, mull over it for quite some time, think of different approaches to solving it, realize that none of them might work. And then you walk away. Take a nap, cook, work out, whatever.

The brain then does this background processing and connects the threads.

Time spent on trying different solutions (and especially, experience) is critical.

Quoting Mark Twain -

Good decisions come from experience. Experience comes from making bad decisions.

I wanted to chime in and say that this is exactly how I approach difficult problems. It has worked for me over and over again, and I have trained myself to go against my natural instincts and just drop something after a while, knowing that when I come back to it, I will likely have a fresh perspective. Also, love the Mark Twain quote.

Reminds me of how I solved some of the hardest problems I've ever worked on (all in side projects) while being on parental leave, pushing around strollers. During that time I had something of 1-2 hours at the keyboard each day, but endless hours to think. It was quite the enlightening experience, I was literally shocked how much I got done as opposed to exploring problems while writing code.

But I've never managed to find that kind of focus at work, neither as developer nor CTO, neither remote nor on site. I feel I've always spent a large chunk of my time trying to get people to explain the problem they're trying to solve, to stop rushing, or to reduce scope. Tragic, really.

IMO this talk is about n intersection of two things:

  1. Waterfall (The Good Parts)
  2. Focused vs Diffuse thinking as described in Barbara Oakley's Learning How To Learn course [1]

What I missed from the Waterfall[2] days, is taking the time to think on a problem and proper software architecture/design. Depending on the complexity it was one to several weeks of thinking, while writing the SDD[3] document. And then having a proper design review meeting.

Under Agile/Scrum everything was rushed, and you had to plan a sprint of work in a day or two, and each feature under a hour in a synchronous meeting. Obviously it's impossible to arrive to a good design decisions that way, and you just grab the first available seemingly working solution.

1. https://www.coursera.org/learn/learning-how-to-learn

2. What I though was Waterfall, was actually RUP (Rational Unified Process)

https://en.wikipedia.org/wiki/Rational_Unified_Process

3. Software Design Document

Personally when I'm thinking about a hard problem I have to pace around, not lie down.

I'm a shower driven problem solver myself.

That works too but there's only so long one can spend in the shower.

Especially in a drought. (Northern CA here)

Yeah. More like hike driven development.

“All truly great thoughts are conceived while walking.”

-Nietzsche

There was an interesting article about this recently. https://lithub.com/on-the-link-between-great-thinking-and-ob...

Working for someone else makes it hard to do this often: there are processes in place to avoid developers doing anything other than finishing the ticket (for example timing the ticket and checking they did exactly what it said within the last estimate)

Which is fine with me because I can save deep thinking for side projects :-)

you should try to talk to existing experts too. Sometimes they can utter a few words that gives you a helpful mind model that saves days of original thought.

I found that just explaining the problem to someone else, also works in great ways. I knew a guy, who thought that I was much smarter than himself, and often he would come up to me to ask me for advice and started to state the problem, which usually I didn't get, but halfway, he would suddenly see the solution, and thank me for helping him.

Take a look at rubber duck debugging: https://en.wikipedia.org/wiki/Rubber_duck_debugging

As i see, this is about:

- Using a while true loop instead of deploying a worker to Kubernetes

- Using a setInterval instead of deploying a cron job to Kubernetes

Reading this I am reminded of Obolomov.

I have to wonder if Rich Hickey every read Polya's How to Solve It ?

Yes, he directly credits the book in the talk.

Ah, yes. I'd probably call it insomnia-driven development though.

A summary of a talk from 8 years ago?

Sorry ~11 years ago

Some previous discussion:

https://news.ycombinator.com/item?id=1962051

Reply on news.ycombinator.com