What is great code?
That question drove me to find functional programming, later Clojure. One aspect I was missing in my persuit, was the importance of learning programming practice from great programmers.
Read on to find more questions, and why my pursuit of great code makes me excited about the Babashka in Practice workshop during Heart of Clojure in 5 days.
# Which software practitioners are you learning from?
In your journey towards writing great code, are you finding your own path?
Or do you have someone to learn from?
## On the misconception that theory is all there is.
I had the chance to learn a nice pile of theory during my university education.
A mix of math, physics and programming gave me tools I now appreciate having.
My emphasis on theory had a funny effect on how I approached programming: I kept searching for theoretical integrity.
In part, I'm super happy for that.
It lead me to find functional programming, and the Clojure community in particular.
What a gem.
It also lead me to emphasize theory over practice.
To want questions to have hard true/false answers.
For there to be one right way.
If a theory isn't legible, it's bad.
Practice is a different matter; it's not all legible, and it's not all intuitive.
## Practice is harder to learn than theory when you don't have access to good practitioners
Theory fits in a book, in a paper or in a blog post.
Practice may not.
## Pair programming for learning practice
## Michiel Borkent and Christian Johansen: two software practitioners worth learning from
I’ve searched for the skills to write great code for years. And for years, I searched the wrong way. I looked for a single, correct answer, when I should have been looking for who to learn from.
My journey towards learning programming started with a theory-centric programming education. I learned a lot about what things are. Programming languages. Functions. Types. Databases. Memory. What things are is great to know. But how you do solve your actual problems in practice? Effective practice is harder to teach than a selection of relevant theory.
Learning practice requires a goal-oriented context. Where answering a series of “what is”-questions can teach theory, it falls short for practice. To learn to ride a bike, you’ll want a bike, somewhere to try riding that bike, and someone who has ridden a bike before. To learn programming practice, you’ll want a system you can change, a goal for changing that system, and someone who has programmed before. Pair programming provides a goal oriented context, and if you’re pairing with an expert, you’re in luck. Kent Beck advocates for writing all production code in Extreme Programming Explained, second edition:
Write all production programs with two people sitting at one machine. Set up the machine so that the partners can sit comfortably side-by-side. Move the keyboard and mouse back and forth so you are comfortable while you are typing. Pair programming is a dialog between two people simultaneously programming (and analyzing and designing and testing) and trying to program better.
You can get by without writing 100 % of production code in a pair. But if you spend 0 % of your time pair programming with with, you’re missing out!
Lessons learned from Michiel Borkent and Christian Johansen. TODO.
References:
How does it feel when you’re learning effectively?
How does it feel to program with an expert?
Learning programming from Michiel Borkent
learning programming from Christian Johansen