Hammock Driven Development - Rich Hickey on HackerTube: recommended by 12 Hacker News commenters across 11 separate months, 2014–2024.
talk · evergreen
Rich Hickey's philosophical talk from the first Clojure Conj in 2010. He argues that good design comes from deliberate, away-from-keyboard thinking, and describes how to feed the background mind so it solves problems.
HN returns to it constantly as permission and method for thinking deeply before coding, and as an antidote to always-working anxiety.
“Both of these talks are in my top 5.”
20 Hacker News comments link this video. Each one links back to its thread.
That and Hammock Driven Development: ▶ this video Both of these talks are in my top 5. Edit (okay, here are the other 3): * All the Little Things by Sandi Metz [link] * Programming is terrible—Lessons learned from a life wasted. [link] * Some talk I saw by Dan McKinley on making Data-Driven decisions. I can't find the original video, but here's a really similar one: [link]
in “Rich Hickey Fanclub” · View on HN
Rich Hickey, of Clojure fame, has a talk you might find interesting. It goes by multiple titles: * Step Away from the Computer * Hammock-Driven Development ▶ this video The idea / hypothesis is that sometimes we need to sit down and think about something for an hour, a day... This seemingly "wasted time" can pay huge dividends in long-term health of a project. Like compound interest. As others have noted, this may seen "lazy" to managers, especially if LOC or sprint velocity is the metric they use.
in “Ask HN: Are most of us developers lying about how much work we do?” · View on HN
In terms of mind-expanding or intellectually stimulating, I find it's easier to get that from Youtube. I recommend: 3blue1brown for math ( [link] ) Everyday Astronaut if you are casually interested in rockets ( [link] ) Bret Victor ( [link] ) or Rich Hickey ( ▶ this video ) for programming and design. Doing a full college course is such a time investment and it usually takes a few weeks to start proving the interesting stuff. I find it more fun to look to shorter content for inspiration. I might realize I don't understand the fundamentals of the topic and then seek out a way to study it.
in “Ask HN: Did you take any fresh MOOCs as of 2020?” · View on HN
I think a good starting point is to integrate the principles described in the Simple Made Easy[1] & Hammock Driven Development[2]. These are overarching first principles that help in designing and writing code, but also in communication & team work. [1]: [link] [2]: ▶ this video
in “Ask HN: How does one becomes a pro at Software Engineering” · View on HN
The feeling you're describing is called anxiety. Some anxiety is normal, but constant anxiety that interferes with your life is a problem. I think it'd be worth trying that label on: call it anxiety, and ask "how do I reduce my anxiety?". About 1 in 4 people experience an anxiety disorder at some point in their lives, so there's a lot of research and good approaches out there. One thing that stands out to me is that you've made some pretty big and scary claims without a lot of evidence to back them up. Are you actually not a good developer? Are smart people really "capturing" the opportunity (ie there is less opportunity over time)? Do people who aren't working all the time fall behind and never make anything of significance? If so, prove it! Figure out what evidence you would need to definitively answer these questions, and research or experiment until you have that evidence. Anxious thoughts are like dreams: they seem perfectly reasonable in your head, but when you try to bring them into the real world they fall apart. As far as evidence goes, I'd point you in the direction of two of my favourite Richards. The one who did Clojure: ▶ this video and the one who got a Nobel for Quantum Electrodynamics: [link]
in “Ask HN: I feel like I should be working all the time and its killing me” · View on HN
This makes me think of Rich Hickey's Hammock Driven Development: ▶ this video - "Stay away from the computer" - Start by asking: "what is the problem?"
in “Readme-Driven Development (2010)” · View on HN
I like this kind of development also. But I don't think it is for everyone (the person has to keep thinking on the problem for long time). A good talk about It, from the creator of clojure: ▶ this video
in “Streams: a new general purpose data structure in Redis” · View on HN
I have loved this talk for some time and have forced everyone at my company to watch the video. I found a lot of parallels with this "Hammock Driven Development" talk by Rich Hickey: ▶ this video They both seem to suggest that you have to put in the effort, do the hard work and dig into the problem deeply. But then when you hit a wall, you should take a break. Relax. Play. Sleep. It is often during this "open" minded stage when the solution comes.
in “Lecture on Creativity (1991)” · View on HN
I was searching for exactly the same stuff yesterday, and I found this: [link] I usually keep notebooks, but I am ever more convinced of using one because of Rich hickey's talk: ▶ this video and we have a better chance of remembering something if we write than type. [link] . I have previously read that people like Martin Gardner had an awesome system of keeping notes. I would love to know more about your tips. How do keep your notes? How do you organize stuff, while retaining the freedom to doodle. How do you find stuff again(which is the killer feature for typed notes). Would love to learn from the masters - do you have any books to recommend?
in “Ask HN: How many programmers out there keep a paper notebook for their projects?” · View on HN
This is very similar to what Rich Hickey (creator of Clojure) talks about when he talks about Hammock Driven Development, I recommend watching him talking about it here: ▶ this video
in “Building a Startup in 45 Minutes per Day While Deployed in Iraq” · View on HN
"don't get stuck" reminds me of the feynman method of problem solving: 1. Write down the problem. 2. Think very hard. 3. Write down the answer. Rich Hickey's Hammock Driven Development, ▶ this video , is IMO very good for actually not getting stuck in a bad place problem solving.
in “Stanford study shows success of different programming styles in CS class” · View on HN
This is a classic and hilarious series of posts on the foolhardiness of the TDD approach to software design: [link] Personally I prefer Rich Hickey's "Hammock Driven Development": ▶ this video
in “The End of Agile: Death by Over-Simplification” · View on HN
Hammock-driven development is a thing: ▶ this video I think anyone can experience this even if you're unaware of the science behind it. The brain during sleep can also connect seemingly disconnected things in ways that your daily logical process would have a lot of trouble with. That's why things seem to "click" when you wake up from sleep. If your daily thinking is a gradient descent, your sleep thinking is a flood from all points and in all directions. But I don't have any science refs on this; just my experience.
in “The brain simulates actions and their consequences during REM sleep” · View on HN
Hammock driven development ▶ this video When I worked in an office I'd get up and go on walks, or move to a sofa and let the problem simmer a bit, several times a day. I've been fortunate to work in companies which seem to, I think, recognize these are productive activities
in “Third Time: a better way to work (2022)” · View on HN
He gave a well-known talk with that name - Hammock Driven Development , Rich Hickey, Closure Conj 2010 ▶ this video
in “Creation happens in silence” · View on HN
Rich Hickey talks about this, calling it "hammock-driven development." ▶ this video Aaron Sorkin has also touched on this: > Most of the time, me writing looks—to the untrained eye—like someone watching ESPN. The truth is if you did a pie chart of the writing process, most of the time is spent thinking. When you’re loaded up and ready to go—when you’ve got that intention and obstacle for the first scene that’s all you need. For me at least, getting started is 90% of the battle. The difference between page zero and page two is all the difference in the world.
in “What “work” looks like” · View on HN
What a tale. This is such a key insight, such a core lesson on how the world tends to work. > At his next salary review Charles was given a raise which was about half the inflation over the period. He was not given a promotion. After about a year he became discouraged and left Consolidated. To be fair to Alan, spinning up an organization & knowledge system is real hard work. Legitimizing your projects is real hard work. But there's such tension over who steers, over how the work happens, and there's so many really good solid workers who slip through the cracks & never get appreciated. The corporate body is so often so very far away from the workers on the edge, sees the faults and problems, incompetent at appreciating and respecting many of the best acts done for it. Thanks for the share. This is a great article. I see a lot of relationships to other submissions. Jonathan Blow talking about work-life balance has some relationship here, on how we exert ourselves ( [link] [link] ). The "midlife crisis of a programmer" seems ultra-pertinent ( [link] [link] , 2 comments). "Hammock-driven development" made the rounds against ( ▶ this video [link] ). All of these deal with questions of time-base & commitment & application, all of these feel like they could be informed by The Parable. Worth pointing out that the parable is reportedly from (1985)! It's somewhat confirming to hear the struggles of the lowly engineer to get work done & fit in are not new.
in “The Parable of Two Programmers (2012)” · View on HN
Nobody's stupid because they're not sure about something. It's totally cool to ask for help or opinions when you're thinking through a hard problem. To answer your question you should understand what creativity and practicality mean in your context. I would generally think that being practical and creative aren't at odds with each other. When working through a problem for work I tend to err on the side of practicality. We could be coming up with a new way to do data transformations, building out distributed tracing tools, or trying a new way of scaffolding our projects. Each of those solve a real problem and have practical implications. They also require creative thinking to imagine and design new tools and workflows. These projects are practical in the sense that they need to solve an actual problem (e.g. deliver a net benefit to customer UX or development velocity). Contrary to how they sound, they often aren't obvious projects to take on or straight-forward solutions. It usually required days or weeks of lateral thinking to cook up one of these. In this context, creative thinking complimented practical thinking and produced a better result than one of those modes taken in isolation. Sometimes it's helpful to circle around the problem you think you want to solve to better understand what your actual problem is. Be careful reading other's ideas since it will affect the way in which you see the problem. Your view of the problem may be skewed after reading other information. O
in “Ask HN: Does being practical act as a hinderance to one’s imagination?” · View on HN
sorry guys, i don't know clojure, so i'll write this script in my favorite programming language: #/usr/bin/english if clojure is mentioned, can rich hickey be far behind? and if rich is mentioned, can this video of his be far behind? methinks not. lo, and behold, said video: ▶ this video
in “Why Is Jepsen Written in Clojure?” · View on HN
This was a joke, the only out of stock item on the list is the Hammock at the bottom. This is a reference to Rich's talk "Hammock Driven Development": ▶ this video
in “Rich Hickey's Clojure Bookshelf” · View on HN