Most commonly known for the creation of the Clojure programming language, Rich Hickey can easily be considered a brilliant and experienced engineer with 20-plus years of experience in the field.

But he’s also a great thinker and speaker who’s able to distill and give shape to ideas that are not easily put into words.

Let me put it this way: That's 20-plus years of deliberate practice in software development distilled into 20-30 minutes of talking.

Such talks are often related to broad problems and ways of thinking rather than one specific language or practice in our field. Here are the ones that I believe we can really benefit from listening to.

Simple Made Easy

In this talk, Rich explains how simple and easy are quite different things. He also discusses how we, as software developers, can make our own lives harder sometimes.

He also makes a point of how important — or better yet, absolutely necessary — simplicity is for building good, reliable software.

“[…] The first word is 'simple,' and what it means is one fold or twist. You can contrast that with 'complex,' which means to combine many things or to braid together things. And we distinguish that from easy, which in the derivation I like means 'to lie near.'”

Rich's point is that something being easy is always relative. It is subjective to each individual, depending on the experience or familiarity you have with a given problem or skill. Simple, on the other hand, is objective and analyzable.

"How does that connect to software?" you might be wondering. I'll let the man answer this one for you:

“But we can only think about a couple of things at a time and the main problem we have with things that aren't simple is that when it comes time for us to think about them, such as when I have to enhance a part of my system or fix a problem in it, I pull a string and I get this knot of other stuff that's connected to it.

And I have to blow all of that stuff up in order to think about it, in order to solve my problem. So this tying of things together is going to fundamentally undermine our ability to understand and change them.”

He also claims that we should be aware of good design, as design is, by definition, pulling things apart. This enables designs to be simpler and easier to use, substitute, and extend.

He then raises a number of things that software developers do to make our lives easier but our software worse — or at least not as simple as it should be. Ouch. He makes great suggestions on how to improve, though.

Totally worth watching one or more times.

Simple Made Easy

Hammock-Driven Development

The idea that Rich defends in this one is that we should solve problems — not create features. Spend more time stating problems, understanding them, and then designing and analyzing solutions rather than coding straight away.

“Problem-solving is definitely a skill. You shouldn’t take away from this talk that there is a certain kind of person who’s good at problem-solving and gets to do that part of the job. […] If you practice problem-solving, you will get good at it.”

According to Rich, being a good problem-solver provides way more leverage than being good at any other practice or methodology.

But how? How can you practice problem-solving and be more aware of your solutions? According to Rich, you should:

State the problem.
Understand the problem.
De discerning, be critical. Be aware of trade-offs.
Maintain your focus when doing design work

The title of the talk itself derives from this little “tactic” that can help you focus and be away from the computer and other sources of distraction:

“There are some cool aspects to the hammock. One of the cool aspects to a hammock is that you can go on the hammock, close your eyes, and no one knows that you are not sleeping.

But they won’t bother you because they think you might be sleeping. So it’s very cool!”

Rick then discusses some aspects of the way the human mind works, its different “modes” of operation, and how you can leverage that. This one is more of a lighthearted talk, but it brings great value nonetheless.

Hammock-Driven Development

Design, Composition, and Performance

This talk is about software design and how it contrasts with implementation. The concept is explained through analogies with music and musical instruments. Initially, Rich focuses on explaining what good design is about and how you can benefit from it, but the content really shines once he starts making analogies with music.

The core takeaways from this one are tips Rich gives on how to be a better engineer:

Take things apart — not by smashing them with a hammer, but with an eye for how you are going to put them back together. That is what design is about.
You want to design like a composer — not in the sense that you need to design every note for every player but how the things you are working on fit at every level. Bring design into the small things, the medium things, and the large things, and often apply different techniques and ways of thinking for each level.
You want to code like a jazz player. Jazz players improvise with apparent magical genius, but only after acquiring harmonic sensibility after studying a lot. Likewise, bring that design sensibility to the coding that you do. That is, write code backed by a solid design perspective.

Design is like composition, whereas implementation is like performance and improvisation.

“When you hear an improvisation, what you end up hearing is an application of a lot of knowledge and a tremendous amount of vocabulary. It’s almost a dynamic composition that’s happening. […] So it’s this delicate balance of being able to be dynamic, but having compositional sensibilities to apply on the fly. That’s what developers need.”

Then a new analogy is made: Programming languages are like instruments — especially because both of them are limited. Instruments can’t produce any arbitrary sound, but the performer overcomes that via various techniques when necessary.

Well, why aren’t there instruments that can produce any sound? That is, why aren’t there programming languages that can do anything? According to Rich, it would be extremely hard to build (or compose) using such complex targets. Those would become unpredictable.

Rich also offers an interesting take on pair programming:

“Instruments are for one person to play at the same time. And yet, we have these complicated tmux-whatever things. I don’t want to diss pairing because while I personally don’t understand it, I can see analogies. For instance, two musicians playing in the same room, and that obviously has good effects.

But you have to wonder: Is this just a way to keep somebody from typing all the time? If we had an otherwise built-in time for design, is pairing one way that we are trying to buy it? It’s a fair question.”

The point of developers “practicing” (i.e. studying somehow) is also important:

“I don’t know why, as software developers, we think we can just show up. Everybody else practices. Obviously, we went to school and studied whatever we studied, but musicians are not like ‘Well, I went to school, so now I don’t need to practice anymore.’”

This talk is great for more experienced developers or anyone more involved with architecture in design.

Design, Composition, and Performance

Wrapping Up

If I had to summarize the lessons Rich teaches in those talks in a few sentences, those would be:

Simplicity matters. Develop a grasp of simplicity. Be aware of what is simple, what is complex, what is easy, and what is hard.
Train yourself to see the trade-offs in every decision, as any technical decision will most likely be accompanied by them. Be discerning, be critical.
See and solve the problems that are beyond code. Develop and use design skills to actually solve problems — not just write code. Use those skills to see design in code and code in design.

Originally published on medium.