HN Theater @HNTheaterMonth

For some related ideas:

  - Bike-shedding [0]
  - the Law of Triviality [1]
  - "Hammock-Driven Design" - a 2010 talk by Rich Hickey [2]

[0] https://thedecisionlab.com/biases/bikeshedding

[1] https://en.wikipedia.org/wiki/Law_of_triviality

[2] https://www.youtube.com/watch?v=f84n5oFoZBc

Hammock Driven Development by Rich Hickey [1] is a presentation that dives into why taking a step back from the immediacy of a problem often leads to clarity.

[1] https://www.youtube.com/watch?v=f84n5oFoZBc

⬐ slifin

The urge to invoice a Hammock for my home office to my employer

⬐ jereees

Just buy it. Look at it as an investment for your future mental health.

Rich Hickey talks about this, calling it "hammock-driven development."

https://www.youtube.com/watch?v=f84n5oFoZBc

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.

This is also well known in the Clojure community as Hammock-Driven Development [1].

[1] https://youtu.be/f84n5oFoZBc

The last two places I've worked paired fairly heavily, perhaps 50% of the time, and on some squads mobbing has been popular as well.

As an introvert, I prefer to go solo unless I'm working on something I know would benefit from additional knowledge or brainpower, but I've found pairing to be the single most powerful tool I know for training junior devs and for bringing people up to speed on code bases, languages, techniques, or business domains -- which is often quite important.

There is undoubtedly a velocity cost in the short term, since ideally the junior person ("junior" here might be a senior person who is new to the code or the business) will "drive" (type) more, and some time is spent in the teaching. But the investment in higher overall knowledge of the team, and in catching bugs/avoiding dead ends early, tends to pay off.

One subtle thing that takes time and practice is deciding when to stop pairing, because one or both of you needs a break, or time to think about the problem at one's own speed.

I also think one can become over-reliant on pairing for learning. Personally I love reading (even printed books!) for learning languages, and writing for shaping thinking and capturing knowledge for future people. Not everyone loves these activities equally, but they are important skills for engineers to develop, and pairing is not a replacement for them.

Finally, sometimes it's good to just go off and think for awhile.[1]

[1] https://www.youtube.com/watch?v=f84n5oFoZBc

Rich Hickey - Hammock-driven development: https://m.youtube.com/watch?v=f84n5oFoZBc

Brett Victor - Inventing on principle: https://m.youtube.com/watch?v=8QiPFmIMxFc

Programming is terrible: https://m.youtube.com/watch?v=csyL9EC0S0c

Dave Beazely - Python concurrency from the ground up (applicable to languages in general, with generator and corourine functionality) https://m.youtube.com/watch?v=MCs5OvhV9S4

Functional programming, with birds: https://m.youtube.com/watch?v=6BnVo7EHO_8&t=1009s

Short and classic: Wat https://www.destroyallsoftware.com/talks/wat

⬐ mikewarot

>Brett Victor - Inventing on principle: https://m.youtube.com/watch?v=8QiPFmIMxFc

This gave me a sharp moment of clarity, thank you so much for this!

I'll work on the wording over time, but here's a rough sketch of my principle:

My principle is that no person should ever be forced to blindly trust a computer to do the right thing. Computing shouldn't be either blindly trust the black box, or get nothing done.

Nobody should have to hand over their wallet to buy an ice cream cone, you can just take the exact change out and pay. Why should you have to give a program access to everything when you just want to edit one text file?

⬐ eimrine

need some text, can not watch no video

⬐ tosh

https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

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 (https://www.youtube.com/watch?v=alfCi8QoZQ8 https://news.ycombinator.com/item?id=29999004). The "midlife crisis of a programmer" seems ultra-pertinent (https://farath.com/is-4-5-years-the-midlife-crisis-for-a-pro... https://news.ycombinator.com/item?id=29979515, 2 comments). "Hammock-driven development" made the rounds against (https://www.youtube.com/watch?v=f84n5oFoZBc https://news.ycombinator.com/item?id=29886197). 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.

⬐ rektide

This resonated so much to me & meant so much. It felt like such a breath of fresh air. I still ascribe to the ideas here. But almost a decade later I feel like there's still little more than faith, I've seen so little evidence that software is capable of being conceived in processes that have appreciable consideration & soak time, by well regarded crafts-people. We feel damned by too-much-scale/too-many-concerns on one side, and too many pressures on the other.

I believe very much in the deep soulsearching activities of software development- it feels intensively valuable- but this slow seeking feel still more mystical in nature & happening than what we have, and I yearn to see more reinforcement, more exploration of what Rich was talking about, want so much a way to channel this talk into the real, into something understood, believed, and practiced. I don't think we've seen a lot of progress, but I feel like this article kindled a lot of belief, that still sparks strong in a lot of people, but which has not found a way to be shared or revealed yet.

Contratulations, you have discovered [Hammock-Driven Development](https://www.youtube.com/watch?v=f84n5oFoZBc)! (also https://github.com/matthiasn/talk-transcripts/blob/master/Hi...)

In Clojure we call it "Hammock-driven development" after a 2010 talk by Rich Hickey https://www.youtube.com/watch?v=f84n5oFoZBc

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

https://www.youtube.com/watch?v=f84n5oFoZBc

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.

Rich Hickey’s “Hammock Driven Development” talk largely agrees with this view: https://youtu.be/f84n5oFoZBc

⬐ sbayeta

Awesome!

Hammock driven development is real.

https://www.youtube.com/watch?v=f84n5oFoZBc

I would not conflate slow feedback loops with intentional breaks

For me slow feedback loops push me into dopamine seeking activities, intentional breaks push me into relaxation and deep thought

Recently I got a treadmill desk and the physical exertion reminds me to take breaks where I can get off and relax and potentially think about a problem

Slow tests running causes me to not write tests and look at YouTube

https://youtu.be/f84n5oFoZBc

You should not: if anything, that would be a showcase of your proficiency in design memes, or if put another way, general incompetence.

To redesign something, I feel like you need to dive deep into what the project wants to achieve, and why it doesn’t happen (if it ever really does not). For that, you will need owners’ input and a lot of research, which you doubtfully can get in three hours.

Ever heard about hammock-driven development? Stop the rush, have a listen: https://youtu.be/f84n5oFoZBc

Classic meme in the Clojure world is "hammock driven development" popularized by Rich Hickey himself: https://www.youtube.com/watch?v=f84n5oFoZBc

Love this!

⬐ sooheon

Although the intention there is to leave the computing behind ;)

Context

https://m.youtube.com/watch?v=f84n5oFoZBc

⬐ koolba

I was expecting this:

https://youtube.com/watch?v=IujLD7nSf8Q

IMO Voltairine de Cleyre[0] phrased this notion much better in this essay about Anarchism[1] in the first few paragraphs.

She starts with describing two essential spirits, one being conservative and steady, the other one being progressive and unpredictable. It becomes clear these spirits both inhabit everyone in some way or another and society reflects that as a whole as well.

On a personal level, it gets complicated really fast. People as I know them usually cannot be categorized as easily into one or the other. Some people appear as unconventional and free thinkers, but are set in their ways in many areas, and vice versa. And then it also depends very much on the situation, the atmosphere and so on. Someone who appears timid at first, sometimes just needs a nudge to open up and go bonkers.

So I feel like the notion that you can divide people into these categories is very reductionist.

What I find useful however is balancing the creative/progressive aspect (or spirit) with the conservative/steady one, and not just balancing but letting them guide oneself them deliberately, dependent on context.

John Cleese did a inspirational and funny talk[2] about this subject, that I found quite useful, because he suggests a practical framework to nurture the creative side deliberately.

Similarly, there is this talk[3] from Rich Hickey that describes the notion of giving oneself enough time to think deeply about problems. It relates to the above in the sense that he also acknowledges passive/subconscious mechanisms of our mind.

[0] https://en.wikipedia.org/wiki/Voltairine_de_Cleyre [1] https://theanarchistlibrary.org/library/voltairine-de-cleyre... [2] https://www.youtube.com/watch?v=Pb5oIIPO62g [3] https://www.youtube.com/watch?v=f84n5oFoZBc

⬐ citruscomputing

[1] is currently erroring for me, here's an archive link:

https://web.archive.org/web/20201127171502/https://theanarch...

⬐ personlurking

>She starts with describing two essential spirits, one being conservative and steady, the other one being progressive and unpredictable. It becomes clear these spirits both inhabit everyone in some way or another and society reflects that as a whole as well.

Reminds me a bit of the Catalonian characteristics of Seny (wisdom or sensibleness) and Rauxa (sudden determination or action):

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

In terms of mind-expanding or intellectually stimulating, I find it's easier to get that from Youtube. I recommend:

3blue1brown for math (https://www.youtube.com/channel/UCYO_jab_esuFRV4b17AJtAw)

Everyday Astronaut if you are casually interested in rockets (https://www.youtube.com/channel/UC6uKrU_WqJ1R2HMTY3LIx5Q)

Bret Victor (https://www.youtube.com/watch?v=PUv66718DII&list=PLS4RYH2Xfp...) or Rich Hickey (https://www.youtube.com/watch?v=f84n5oFoZBc&list=PLXsqD83He-...) 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.

> Dream, in a very literal sense. Do you ever remember those moments right before you fell asleep where your mind gets a bit too creative. Harness that.

This sounds similar to Rich Hickey’s “Hammock Driven Development”. He gives some tips on how to harness it in his talk: https://youtu.be/f84n5oFoZBc

It sounds like we are in more agreement than it seemed - for a full throated defense of thinking over execution, I like Rich Hickey’s talk “Hammock Driven Development” https://m.youtube.com/watch?v=f84n5oFoZBc

As a follow-up: if you want to improve your ability to synthesize knowledge, but don't know where to start, I recommend Rich Hickey's Hammock-Driven Development talk [0]

Spoiler alert: it's all stuff your parents and teachers have told you before.

[0] https://youtu.be/f84n5oFoZBc.

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]: https://www.infoq.com/presentations/Simple-Made-Easy/ [2]: https://www.youtube.com/watch?v=f84n5oFoZBc

See the talk "Hammock driven development" by Rich Hickey on the topic: https://youtu.be/f84n5oFoZBc

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: https://www.youtube.com/watch?v=f84n5oFoZBc and the one who got a Nobel for Quantum Electrodynamics: https://www.asc.ohio-state.edu/kilcup.1/262/feynman.html

⬐ ubertoop

Thanks for helping re-frame the problem. Anxiety is an interesting way of looking at it.

I just read the Feynman text you linked, and it was inspiring. When I started programming, I did it because I enjoyed it. I found it fun. I was just exploring it. Then it became my career... and over the years, it's become more about being good, making money, and being "proud" of my accomplishments.

Maybe I need to take a step back, address my anxiety, and get back to playing. Easier said than done, but worth doing.

⬐ malux85

Having been in this pattern for so long it's also possible you have become addicted to the adrenaline of urgency.

It took me a long time to break the "effort and accomplishment is not an unending linear graph", when I finally took the time to stop working so hard, I got a LOT further in life. Like a factor of 5. Income increase, responsibility decrease, and dramatic weight loss. You're going to have to say no to people. If youre agreeable this is hard, but if what you needed was easy, you'd have already dont it right? haha

As a hyper industrious (80 hours a week normal) it was very hard for me to make this adjustment, it took about 5 months, and I, like you, had been coding 10 years at the time

⬐ twox2

This is right on. FWIW, my anxiety went away almost completely a few weeks after I quit coffee.

⬐ sciencewolf

This. It is unbelievable how much cutting down on caffeine helps with monkey-brain! I switched from coffee to tea with honey and have a much smoother energy than before.

⬐ sergiotapia

Tea has more caffeine than coffee

⬐ hhmc

Tea leaves have more caffine than coffee beans, gram for gram. However a brewed coffee has more caffine than a steeped tea (i.e. the actual drinks).

⬐ zzleeper

????

⬐ PascLeRasc

Ounce for ounce coffee has more caffeine, but tea also has L-Theanine which calms caffeine's effects. I have anxiety like the OP describes and L-Theanine has been life-changing for me. I'd highly recommend trying it either as a high amount of green tea or a supplement.

⬐ ubertoop

That's interesting. I drink a lot of coffee, and I have for over a decade.

I did quit for 1 month a couple years ago, and didn't notice much of a difference. Maybe I need to give it more time.

I'm referring to the very entertaining, but a bit truism-heavy and patronizing presentations of Clojure's Rich Hickey, for example "Hammock driven development": https://www.youtube.com/watch?v=f84n5oFoZBc

I like Rich Hickey's philosophy and personal style, but Clojure just falls short in every aspect as an implementation thereof, in my opinion.

For example, it switched from heavily promoting STM as a concurrency primitive to "app state in atom" to new async/channels.

⬐ capableweb

I don't think you can call clojure.async as something that was made for switching anything, replacing it. Both ways exist and are being promoted for their use cases. I think Clojure is one of the few languages where things have been very stable for a good while. Maybe it's being developed slower than other languages, but using Clojure is nice because of the trust you have of it remaining the same. Everything else is basically libraries on top of the language itself.

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. OTOH, it's common that you can piggyback on existing ideas (see taco bell/duct tape programming).

There are lots of good resources on this subject: John Cleese talk linked elsewhere - https://www.youtube.com/watch?v=y70nbDJI5Uk

Rich Hickey Hammock Driven Development is a more direct application to software development.- https://www.youtube.com/watch?v=f84n5oFoZBc

Another good Alan Kay talk from YC - https://www.youtube.com/watch?v=id1WShzzMCQ

A Mind for Numbers

How to Solve It

Psychology of Intelligence Analysis is interesting too but less applicable (eschewing the Einstellung effect) - https://www.cia.gov/library/center-for-the-study-of-intellig...

This feels appropriate: Hammock-driven development by Rich Hickey https://youtu.be/f84n5oFoZBc

-> mandatory reference to Rich Hickeys Hammock Driven Development [0], watch it if you find the time!

[0] https://www.youtube.com/watch?v=f84n5oFoZBc

Good talk on this subject:

Hammock Driven Development https://youtu.be/f84n5oFoZBc

Hammock driven development https://www.youtube.com/watch?v=f84n5oFoZBc

⬐ etiam

Thank you! You're quite right that seems to match my description the best.

Unfortunately I seem to have amalgamated two different presentations in my memory then, so I'm still missing one. Similar ones that were good?

⬐ g___

This is the only one I remember that matches your description. I also liked "Simple made easy" by the same presenter but it's a completely different topic.

See also Rich Hickey's, 'Hammock Driven Development' - https://www.youtube.com/watch?v=f84n5oFoZBc

Amen https://www.youtube.com/watch?v=f84n5oFoZBc

Agreed! "Hammock driven development" definitely has stuck with me over the years: https://www.youtube.com/watch?v=f84n5oFoZBc

Hammock Driven Development by Rich Hickey: https://www.youtube.com/watch?v=f84n5oFoZBc

⬐ spdionis

Adding to that Simppe Made Easy, also by Rich Hickey

⬐ narwally

Nearly all of Rich Hickey's talks are worth giving a watch. He's an incredibly gifted speaker. The Value of Values and The Language of the System are also among his best.

⬐ rys

Agreed. Here’s a link: https://www.infoq.com/presentations/Simple-Made-Easy

This makes me think of Rich Hickey's Hammock Driven Development: https://www.youtube.com/watch?v=f84n5oFoZBc

- "Stay away from the computer" - Start by asking: "what is the problem?"

I liken it more to Evan investing "hammock time" (https://www.youtube.com/watch?v=f84n5oFoZBc) into Elm because he has loftier goals than just another SPA abstraction. Which is a bit different than perfection.

There are just too many cats that can be released from the bag that would be too hard to reverse once out in the ecosystem. Classic example would be allowing native modules into http://package.elm-lang.org/.

This puts you in a position of treading cautiously with the long-term in mind while your users may clamor for quick fixes that jeopardize the overall strategy.

So I agree with you. This results in the "something good vs nothing at all" release cycle that you point out, but I think its a more accurate explanation of why that is.

The rest of the issues seem to be related to his limited bandwidth. And I suspect Elm is tied so much to his bandwidth because such fundamental design is still being decided.

https://www.youtube.com/watch?v=f84n5oFoZBc

⬐ catpolice

I like the 100% Rich Hickey link rate in the comments so far

Have you seen "Hammock-Driven Development"? It's a great talk.

https://www.youtube.com/watch?v=f84n5oFoZBc

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:

https://youtu.be/f84n5oFoZBc

"Hammock driven development" is the modern application to the software engineering (https://www.youtube.com/watch?v=f84n5oFoZBc)

There's always limit on how much one can focus. Here's what I do to compensate:

1. Write everything down, in some sort of structured form.

2. Take breaks.

3. Return to writeup, think about it some more.

This scales from smaller two day things to multiple month projects; see Rich Hickey's talk, which focuses more on the latter: https://www.youtube.com/watch?v=f84n5oFoZBc

maybe better: https://www.youtube.com/watch?v=f84n5oFoZBc (Rich Hickey Hammock Driven Development)

hammock driven development https://www.youtube.com/watch?v=f84n5oFoZBc

The formal system for changing oneself is academia. It appeals to some people and not others. That difference in taste is ok.

Sort of made me think of this: https://www.youtube.com/watch?v=f84n5oFoZBc But everyone is not where Hickey is and nobody else is him.

Along these lines, I'd recommend Rich Hickey's presentation on "Hammock Driven Development."

https://www.youtube.com/watch?v=f84n5oFoZBc

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:

https://www.youtube.com/watch?v=f84n5oFoZBc

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.

⬐ nine_k

Also, it's the time when you're not visibly "productive".

⬐ jimnotgym

This is why I feel business struggles with people (who are not traditional artists) needing time to think. Great leaps need a lot of space

⬐ pdimitar

s/struggles with/under-appreciates/

s/struggles with/gives hard time to/

s/^.+struggles with.+$/Business has no idea how creativity works/

Context: https://www.youtube.com/watch?v=f84n5oFoZBc (Video, title: Hammock Driven Development, Content: 2010 Clojure Conj presentation)

This is my favorite. I also really like hammock-driven development (https://www.youtube.com/watch?v=f84n5oFoZBc)

Keep in mind that working 65-80 hours a week is actually really really bad for maximizing output. There's a large body of studies demonstrating this in a wide variety of fields. 40 hours is a lot closer to the sweet point for maximal output. See the references in http://www.igda.org/?page=crunchsixlessons

So, first, remind yourself a normal 40-hour work week is actually the best thing you could be doing for your employer long term. See similar point I made over at http://codewithoutrules.com/2016/02/24/go-home-already/

Second, the biggest benefit you can provide for your employer is coming up with the smart solution that reduces the amount of necessary work by an order of magnitude. And you don't do that by working real hard for a long time. You do that by thinking. And thinking is in part a thing you do in the back of your head while doing other stuff. See Rich Hickey's talk http://www.youtube.com/watch?v=f84n5oFoZBc

I was searching for exactly the same stuff yesterday, and I found this:

http://lifehacker.com/five-best-paper-notebooks-1157038442

I usually keep notebooks, but I am ever more convinced of using one because of Rich hickey's talk: https://youtu.be/f84n5oFoZBc

and we have a better chance of remembering something if we write than type. http://lifehacker.com/5738093/why-you-learn-more-effectively....

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?

⬐ yellowboxtenant

I've always had a difficult time keeping notes organized. I think because I'm a web developer I always have a gazillion projects going on. I can't justify having a notebook for each project. I've tried keeping up manilla folders with loose leaf papers, but that was a mess. I tried three-ring binders, but that's not very convenient. A few weeks ago I tried the bullet journal technique and it's been working out well for me. It combines your daily calendar / todo list with project notes. I think it's just the simple idea of having an index that helps me most.

Yes, when you combine this thinking with thinking about the real world in a holistic manner you basically unlock programming super powers :)

Some what tangentially related, hammock driven development: https://www.youtube.com/watch?v=f84n5oFoZBc

The part about pushing on the problem statement is always useful, even if you don't have time to think about problems like he describes.

Try coding on a hammock.

Hammock Driven Development https://www.youtube.com/watch?v=f84n5oFoZBc

"I've yet to meet an anti-TDD zealot who has actually spent a month developing the art of TDD. The detractors tend to be people who write really brittle tests that are a pain to maintain."

I'm not an anti-TDD zealot, but I don't personally do it, nor require any of my developers to do it (but they can, if it helps them).

As with everything in software, some things work well for some people, and not so much for others.

Instead of TDD, HDD works best for me. https://www.youtube.com/watch?v=f84n5oFoZBc

⬐ mikerichards

Rich also said, I think we're in this world I'd like to call Guard Rail Programming... 'I can make change because I have tests!' Who does that? Who drives their car around, banging against the guard rails? Do the guard rails help you get to where you want to go?"

http://patrick.lioi.net/2011/11/23/guard-rail-programming/

TDD has always seemed to me to be another sketchy, cult-like following in the Agile ecosystem. I've never seen anybody be productive at it, even if they did find some kind of solution to a problem long after they would have doing normal development.

But what do I know, I'm not even a fan of unit tests. I'd rather go to the real-deal and run some acceptance/integration test at 2 in the morning.

⬐ agarden

There are people who go around driving their car into guardrails. They are the people who build cars. Because if you don't test failure modes, you don't know that your product performs to spec under them.

⬐ mahyarm

I think what rich hikley was saying that changing something and if the tests still pass after your change you think it is still all good. It's like a programmer who thinks if it compiles, it's shippable!

Another thing I don't like about tests are categories of tests that should be automated by the compiler, tracer or similar.

Like in python you type check a lot in unit tests, but in a statically typed language, the compiler does your type tests for you already so you don't have to write that kind of test any more.

There are also tests I call 'breakpoint equivalent testing' where you put expectations of certain methods getting called in a method. I wish I could just set some breakpoints in an IDE and have some recorder automatically write the method call expectation code for me.

⬐ agarden

He seemed to me to be criticizing people who want to make changes to the code without reasoning about the system, assuming that if they mess something up the existing tests will catch it and tell them. I think he is criticizing a real problem, but the metaphor is all messed up and hence misleading.

Writing software is not like driving a car. It is like engineering a car. Making a change on the assumption that tests will tell you if there is a problem is like deciding to move the gas tank and saying, "If that turns out to be an issue, QA will tell us when they do their collision tests." (Sort of like that. Obviously less expensive.) When you are making a change, you need to think about whether that change will require any new tests and you need to be thinking about how it integrates into the system as a whole. Maybe moving the gas tank means a new kind of collision test needs to be added to the repertoire.

Because the metaphor was bad, the GP seemed to be taking it as a criticism of testing, which isn't reasonable. But I may have been mistaken about his intent.

On the other hand, if the change you are making is just altering the shape of the bumper for cosmetic reasons, it seems pretty reasonable to assume that QA will tell you if it adversely impacts safety in ways that were not obvious.

I agree about static types. Static types are basically a way of having the compiler automatically write and run whole classes of unit tests.

⬐ zimpenfish

> He seemed to me to be criticizing people who want to make changes to the code without reasoning about the system, assuming that if they mess something up the existing tests will catch it and tell them.

I think where tests really help is when it's not possible to sensibly reason about the system because [looks at current codebase] e.g. it's horrifying interwoven ball of mud that's never heard the word "no" or met a Perl module or methodology it didn't want to halfheartedly adopt in the last 10+ years.

That and Hammock Driven Development: https://www.youtube.com/watch?v=f84n5oFoZBc

Both of these talks are in my top 5.

Edit (okay, here are the other 3):

* All the Little Things by Sandi Metz https://www.youtube.com/watch?v=8bZh5LMaSmE

* Programming is terrible—Lessons learned from a life wasted. https://www.youtube.com/watch?v=csyL9EC0S0c

* 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: https://www.youtube.com/watch?v=SZOeV-S-2co

⬐ solipsism

Give us the rest, please!

⬐ hire_charts

Okay! (see above)

⬐ josteink

Completely unrelated: Alan Kay - the power of simplicity

https://youtu.be/NdSD07U5uBs

Easily over of the most thought provoking presentations I have seen recently.

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: https://www.youtube.com/watch?v=f84n5oFoZBc

Any discussion about TDD requires a link to Rich Hickey's Hammock-Driven Development talk: https://www.youtube.com/watch?v=f84n5oFoZBct

The important thing that TDD or any other software design methodology is trying to accomplish is getting you to think about the design of your programs. However you want to accomplish that is fine as long as you take some time before you open your editor and think before you start writing code. It doesn't necessarily have to be TDD.

⬐ marcosdumay

Funny thing.

I think that thinking about the design of my programs is easier once I have some amount of working code.

There's a minimum organization needed for starting to code, but every time I decide to think any further when solving a problem I'm not used to (optimally that would be always), I end up optimizing for the wrong problems and have to restructure it all later anyway.

⬐ rubiquity

That's a great point! I've certainly had times where spiking a bit of code and then thinking was valuable. There are no maxims in program design so I'm glad you took the time and thought about that :)

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": https://www.youtube.com/watch?v=f84n5oFoZBc

⬐ rubiquity

I missed the joke and the hammock. Had I seen the hammock I would have gotten the joke. I love that talk!

"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, https://www.youtube.com/watch?v=f84n5oFoZBc, is IMO very good for actually not getting stuck in a bad place problem solving.

⬐ partition

Wow, this was a big wake-up call. It's ironic because I am in research and I always did a lot of theory and problem definition up front for whatever I did, but I am now in this "reckless rapid prototyping" phase where if I get some idea I have to try it out RIGHT NOW, stepping back be damned. Ironically it results in getting stuck more than I would have wanted!

I guess this is the fourth tip?

- Step away from the computer

I would suggest to you that Clojure has a very clear "the Clojure Way" I would say, more so then almost any other language. It goes beyond syntax to a pretty deep design level. Its not even all that unique to clojure, you could do 'the clojure way' in other languages, but they usally dont.

Some of the importent keynotes from some of the early conjs are really importent, and they really went deep in the community, you can see it in almost every major library.

Another commenter has mentioned the notion of 'simple' but thats not really all that clear. I not enougth of a writer to tell you about it, but I can give you the resources:

- This classic got Clojure on the map for many people: Are We There Yet? - Rich Hickey www.infoq.com/presentations/Are-We-There-Yet-Rich-Hickey

- Simple Made Easy - Rich Hickey - http://www.infoq.com/presentations/Simple-Made-Easy-QCon-Lon...

- Simplicity Ain't Easy - Stuart Halloway - https://www.youtube.com/watch?v=cidchWg74Y4

- Ousterhout's Dichotomy Isn't (Part 2 of the Simplicity/Power/Focus Series) - Stuart Halloway - https://www.youtube.com/watch?v=cidchWg74Y4

- The Language of the System - Rich Hickey https://www.youtube.com/watch?v=ROor6_NGIWU

- Hammock Driven Development - Rich Hickey https://www.youtube.com/watch?v=f84n5oFoZBc

In addition to these, there are many talk that are about people trying to run with these ideas. Datomic is a example of taking these ideas to the max, it really standas as a nice example. You can find others in talks by David Nolan for example, but there are tons of applied talks.

- The Design of Datomic - Rich Hickey http://www.infoq.com/presentations/The-Design-of-Datomic

Brings to mind Rich Hickey's support of so-called "Hammock Driven Development": https://www.youtube.com/watch?v=f84n5oFoZBc

See also Rich Hickey's Hammock Driven Development: https://www.youtube.com/watch?v=f84n5oFoZBc

Rich Hickey's Hammock Driven-Development[0] talk is a good talk about how getting away from the computer, and sometimes even sleeping, can be the best way to solve technical problems.

0 - https://www.youtube.com/watch?v=f84n5oFoZBc

This is a classic and hilarious series of posts on the foolhardiness of the TDD approach to software design:

http://devgrind.com/2007/04/25/how-to-not-solve-a-sudoku/

Personally I prefer Rich Hickey's "Hammock Driven Development":

https://www.youtube.com/watch?v=f84n5oFoZBc

"It needs more hammock time", a la Rich Hickey's "Hammock Driven Development" (https://www.youtube.com/watch?v=f84n5oFoZBc).

The effect on internet disruption on my mind are pretty staggering. For the first hour I feel anxious from the void, then time dilates and then I feel a deep sense of focus into doing anything... 'back against the wall' time perception.

ps: Rich Hickey (of clojure) did a very nice (as usual) talk called "Hammock Driven Development" mentionning getting away from the machine : https://www.youtube.com/watch?v=f84n5oFoZBc

Rick Hickey says this well in his Hammock Driven Development talk. https://www.youtube.com/watch?v=f84n5oFoZBc

Rich Hickey (creator of Clojure) advocates 'Hammock Driven Development.' Let your background mind do the hard work for you.

Link: http://www.youtube.com/watch?v=f84n5oFoZBc

Reminds me of Hammock Driven Development by Rich Hickey: http://www.youtube.com/watch?v=f84n5oFoZBc

⬐ freshhawk

First thing I thought of as well. Rich Hickey talks should be considered required viewing for anyone building non-trivial software.

⬐ espeed

Yes, great talk -- I was just about to post that link. For those who haven't seen it, definitely check it out.

Rich describes his design process and talks about how deep contemplation is a mechanism that transfers an idea from your conscious mind to your unconscious mind (your big brain) where the real horsepower is.

John Cleese also talks about this idea in his lecture on creativity (http://www.youtube.com/watch?v=VShmtsLhkQg).

In another talk Rich mentions that he has been able to spend a year in deep contemplation three times in his life: one was for Clojure, one was Datomic, and one other yet-to-be-named project.

BTW: You can tap into even more horsepower by pairing deep contemplation with a good night's sleep, where you go to sleep still thinking about the problem (Rich touches on this briefly).

Research shows sleep is when the brain prunes itself by separating signal from noise...

"Sleep researchers at the University of Wisconsin-Madison School of Medicine and Public Health believe it is more evidence for their theory of 'synaptic homeostasis.' This is the idea that synapses grow stronger when we're awake as we learn and adapt to an ever-changing the environment, that sleep refreshes the brain by bringing synapses back to a lower level of strength. This is important because larger synapses consume a lot of energy, occupy more space and require more supplies, including the proteins examined in this study."

"Sleep — by allowing synaptic downscaling — saves energy, space and material, and clears away unnecessary 'noise' from the previous day, the researchers believe. The fresh brain is then ready to learn again in the morning" (http://www.sciencedaily.com/releases/2009/04/090402143455.ht...).

Yes, "Simple Made Easy" is a must watch imo. http://www.infoq.com/presentations/Simple-Made-Easy

"Are we there yet" is also great: http://www.infoq.com/presentations/Are-We-There-Yet-Rich-Hic...

I also love "Hammock Driven Development": http://www.youtube.com/watch?v=f84n5oFoZBc

Rich Hickey would like to disagree.

http://www.youtube.com/watch?v=f84n5oFoZBc

the whole notion of"let's step back a bit and ponder" - it has an official name: Hammock Driven Development. Presentation about: http://www.youtube.com/watch?v=f84n5oFoZBc

As to trickling from Clojure to the mainstream - I wonder how far this could go without the foundation work that went into creating Clojure as it is. You definitely need a clutter-free syntax for functions as data, otherwise "(alter ref inc)" becomes "alter(ref, lambda x: inc(x))". Bad. Macros help too but I don't want this to turn into a "turn all languages into Lisps" rant :)

⬐ pwr

Your example turns into "alter(ref, inc)" in any programming language with first class functions. I think there are some great concepts in Clojure (multimethods e.g.) which are not tied to lispy syntax and macros.