For the last couple of weeks I’ve been thinking about what should I learn in 2016. What conferences or workshops to attend, what books to read, what paradigms to explore. Then I came across this:
“Most of the major academic studies of programming miss much that is essential to the way that professional programmer thinks and feels,” Jonathan Rowson wrote in his book The Seven Deadly Programming Sins. “They are guilty of thinking of programming as an almost exclusively cognitive pursuit, where code is written and understood only on the basis of mental patterns and inferences.” In reality, he wrote, if you want to become a great programmer, or even a good one, “your ability to recognize and utilize your emotions is every bit as important as the way you think.”
“Teaching programming is really about teaching the habits that go along with thinking,” Spiegel explained to me one morning when I visited her classroom. “Like how to understand your mistakes and how to be more aware of your thought processes.“
“Two of the most important executive functions are cognitive flexibility and cognitive self-control. Cognitive flexibility is the ability to see alternative solutions to problems, to think outside the box, to negotiate unfamiliar situations. Cognitive self-control is the ability to inhibit an instinctive or habitual response and substitute a more effective, less obvious one. Both skills are central to the training Spiegel gives to her students.”
“It’s uncomfortable to focus so intensely on what you’re bad at,” Spiegel told me. “So the way people usually study programming is they read a book about programming, which can be fun and often intellectually amusing, but it doesn’t actually translate into skill. If you really want to get better at programming, you have to look at your programs and figure out what you’re doing wrong.“
Shocking? Familiar? Obvious?
Whatever you think, I made that up. The article I’m “quoting” is not about programming, but training chess champions. I replaced all words related to “chess” with “programming” (including the book title).
I know nothing about chess, but I feel we could learn a few things from Mrs Spiegel.
“Show me the code or it didn’t happen” told me my colleague after the my last post. “Good idea” I thought at first. But after giving it some more thought I’m not so sure about its value.
I think it was Leslie Lamport that said that code is the easy part of programming. Once you know what to do and how, writing it down is relatively trivial (note, I said RELATIVELY).
I sometimes wonder if it’s not even worse. If in some cases code isn’t just a distraction. Because once you see code, it’s hard to focus on anything else. Like whether that code should be even written in the first place. Often implementation doesn’t matter as much as we’d like to believe.
Alberto Brandolini said that “Software development is a learning (thinking?) process. Working code is a side effect.”
Seems weird to me that we focus so much on side effects.
Sure, there’s a place for learning implementation techniques, and details are valuable. It’s the foundation of our work. But I think our focus (i.e. how much time and effort we spend on that, compared to all the other things) is not quite right.
So what Mrs Spiegel would do if she was our teacher?
“Most of us probably think that Spiegel was teaching the kids programming. Of course she often passed along specific knowledge: design patterns, programming paradigms, etc. “But most of the time,” Tough writes, “it struck me whenever I watched (Elizabeth Spiegel) at work, what she was really doing was far simpler, and also far more complicated: she was teaching her students a new way to think.” More than that, she was teaching students how to think.“
Sounds like a good goal.
Now I only need to figure out how to do it.
Thoughts inspired by (in random order):
- The article mentioned above that my CEO shared a couple of days ago.
- Avdi‘s post on 10x developers.
- Dijkstra’s letter in which he argued why it’s better to teach students Haskell rather than Java.
- Rinat Abdullin‘s Lokad.CQRS retrospective, in particular Limitation #1: “Lokad.CQRS made developers focus on low-level implementation details, instead of high-level domain design”.
- A few “X common DDD mistakes” posts/presentations I’ve seen. Incidentally, all of them mentioned too much focus on technical aspects and not enough attention devoted to the so-called “strategic design patterns”.
- Recent presentation on DDD and CQRS I watched. It lasted over 1hr and the domain was mentioned very briefly only once, and no earlier than in the Q&A session. I still don’t know what problems prompted the team to use this approach, and whether in retrospect they think it was a good decision. But at least they showed lots of (infrastructure) code. There was “lots of meat” (as we say in Polish).
- A couple of posts written by passionate programmers whom passion led to severe burn out.
- Countless other loosely-related things, including but not limited to the recent comment from my ex-collage related to the system I used to work on, agenda for some DDD workshop I saw, and comment on another of my articles on a completely different subject published on another website. FYI, in my brain everything’s connected to everything else.