Hum, fascinating, wow there’s so many episodes of this. Does seem interesting though.
With regards to that, one thing that’s always bothered me in software is that we keep undermining the importance of the developer on the final result.
I think this happens because people see a lot of overlap with math, and assume then that the act of programming a computer is just the application of some known mathematical formula.
That said, it isn’t. It is much more like the act of coming up with a mathematical proof or formula. For which in mathematics, you would assume that it is up to the talent and knowledge of the mathematician. We need smarter and more knowledgeable mathematicians to tackle the challenge.
Or if you took a less mathematical lens, and treated programming like a discipline, an art, you’d similarly think to write better programs you must be a better programmer. This goes, to make a better painting you need to become a better painter. So same for programming no?
I feel in almost all other discipline this is just assumed as a fact. Your cooking isn’t good? You need to become a better chef. How? Practice makes perfect!
In software development, what do we do? Software sucks? Try re-writing in a different framework or language. Maybe we need to change methodology? Let’s split up the task in 1 week sprints instead of 2, surely that’ll fix it 
Software still sucks? Let’s change the requirements, probably what we were trying to do was just a bad idea. Let’s build something else instead 
Now, I’m not saying that to make people feel like they’re not good programmers or like we’re all competing against each other. I’m saying it because I think trying to deny this truth, actually makes us all worse programmers.
If we accepted that reality, we’d focus our energy into much different places. Like Rich Hickey said, why do you need guard rails? Its cause you can’t drive!!
In programming we seem to have accepted that we just can’t drive and so we’re spending all our time building bigger and thicker guard rails.
Guard rails are good, if there’s a cliff on the highway, even though most people will never fall, you put up a guard rail just in case, but you don’t expect it to be the primary mean for people to succeed in taking the turn 
You still focus on making people learn and know how to drive so you don’t have to rely on the guard rail.
So what if we accepted this as a truth? Bad programs happen because of people not being good enough at programming. And good program are the cause of good programmers?
Now you’d want to focus on the human element. The human is the most important variable when it comes to the success and quality of a piece of software.
So we should focus on setting up humans for success. Build programming languages and tools around them. Make sure they get a good amount of sleep, don’t let them burnout, keep them engaged and entertained on the problem, let them be creative, culture mentorship and continuous education, and above all: have them practice writing more code and more programs!
Even the empirical data backs this up. I’m not gonna bother pulling up the data right now, but I’ve done some searching around it. Lack of sleep has like a ten fold bigger factor over code defect then lack of static types do. The only practice with clear benefits are code reviews! That’s the most human centric practice.
Clojure does as well as Haskell and better then Scala in defect count when looking at GitHub projects. How can that be?
In my opinion, Clojure tries to recognize the programmer as being central to the discipline of programming than some other languages out there. The REPL is probably a big part of it. I’d guess the great set of simple constructs must contribute as well. And possibly the culture of never breaking existing code.
I’d love to hear more ideas around this perspective. How can we make programmers even better at programming? Are our tools designed to make us better? Do they leverage our innate abilities to reason and think and identify bugs and solve problems?
