It’s been a while since I read “The Intelligence Trap” — a nice book on intelligence and wisdom with many facts about knowledge, four stages of competence, how to teach children, how to learn, &c. More importantly it encourages humility and explains how big ego / expertise might be harmful. It certainly bootstraped some thought processes in my mind, getting me curious in different topics — especially wisdom.
Afterwhile, I discovered John Vervaeke and his lecture course on wisdom, which raised an idea to reflect on software engineering, since it’s something I know better than other domains. Quoting John Vervaeke:
Wisdom is an ecology of psychotechnologies. An ecology of styles that dynamically—and that means reciprocally, in a reciprocal fashion—constrain and optimize each other, such that there is an overall optimization, enhancement of relevance realization. Relevance realization within inference, within insight and intuition, the connection to implicit processing, internalization, understanding, gnosis, transformation and aspiration. Wisdom is an ecology of psychotechnologies and cognitive styles that dynamically enhance relevance realization in inference, insight and intuition, internalization, understanding, and gnosis, transformation, and aspiration.
I want to note and write down what kind of meta skills (psychotechnologies) might be helpful in the following activities, representing the software engineer’s work:
- Coding;
- Code review;
- Release management;
- Communication & team performance;
- Problem solving;
- Self-management.
Most of them are well-covered in all sorts of educational materials (a few links: link1, link2), so I won’t write anything specific, just some general notes.
Writing code #
Let’s start with the basics — coding. I bet all programmers had a so called the flow state during the programming session, when a person gets focused that doesn’t notice how the time passes. There is a list of qualities for a task to create the flow state. More details are available in Flow, by Mihaly Csikszentmihalyi.
I will mention the ones we are interested in:
-
The task should be competetive. Its complexity should be on par with the person’s skill level. If the task is too easy, it won’t be competetive and interesting. If it’s too hard, it won’t be possible to evolve;
-
There should be a feedback loop.
The programming is great since it provides us a lot of interesting problems and, what’s more amazing, it has an extremely short feedback loop, not many activies has are like that. And the loop could be shortened via more effective tools improving the compiler speed, using better editor, IDE, more suitable programming language, &c. Personally, I prefer Sublime Text & the compiler in Terminal.app without LSP plugins because I feel myself more effective this way, no matter how much time I invested in Vim/Emacs/&c. or other terminals.
I think it’s important to be aware of this state. Because of it (again, I think) we become programmers — we like to program. We like to work and build things, to iterate, to see the results, edit, compile, edit, &c. I mentioned it in “On short-lived software”, that this is what makes programming interesting, not the result, which is almost always temporary. What’s even more important than to be aware of the flow state — the ability to control it.
Meta skills #
Of course, hard skills are important — that’s why a person gets hired in first place. Soft skills are important as well, without them they will get fired soon. Meta skills, I suppose, come with experience over time — but unfortunately not for everyone. They are usually taught by experienced engineers either in person or via educational materials, and still might not be picked up by a person.
Ego #
It’s important to be humble not only for good communication and team work, but also because it helps at avoiding the expertise traps. When being an expert becomes a problem and a quick way to self-deception. That’s why it’s important to always be careful with personal experience — it might be irrelevant when a fresh look is required.
Empathy #
Same thing as with Ego - being empathic is an important skill in human relationships. But also, it might be a good hard skill. I learned about it in the aforementioned Flow. It described an ability to identify with something non-working (a toaster for example) — “if I’m a toaster, where would I break” — this internalization approach might help to understand how something works and figure out the problem.
Zooming out #
It’s valuable to be conscious enough of spending too much time on some activity. There is no point in traversing the problem in depth if it’s unclear if the assumption/way is valid. Unfortunately, even experienced engineers get into this trap quite regularly.
It’s valuable to be able to zoom out, reflect on the process and time-spending for overcoming the self-deception. I guess that’s why the pomodoro technique is popular. Same thing as a simple walking (also improving the mental health & thinking) and controled interruptions (uncontroled ones just break the flow state).
Socratic method #
Pair programming is a popular and wide-known technique to work together on a problem. Not only two expertises connect but, more importantly, two different perspectives allow to exchange understandings.
Rubber duck debugging provides similar benefits, where one person uses an object to talk to, getting a better understanding of the problem by formulating thoughts aloud. And also it’s much cheaper than pairing, without distracting a coworker.
The next step would be the internalization of the sage. Quoting Vervaeke again:
So we see across the traditions, the idea of internalizing the sage to create an inner dialogue that helps to coordinate the various centers, gets them to talk to each other. And I think this is something where cognitive science can actually give us tremendous help. We’ve had a lot of increase in our knowledge of the various/different areas of cognition, even different kinds of centers processing in the brain and how they work and how they’re operating and what we need is an internalized representation. A model. A role model and a role as a way of taking on a new identity, right? We need a role model for how we can engage in dialogue. and the proposal here – which is, of course, the platonic proposal we already saw – that if I can internalize my capacity and, developed by the Stoics, my capacity to interact with the sage, eventually I get that ability that I have only with the sage. I can have it with myself, within myself. And it means therefore that it becomes part of my metacognitive machinery, the way I dialogue with myself and get the various aspects of myself, the very centers to dialogue with each other.
That’s why wisdom is going to matter to all of this, right? So I practice indwelling the sage, right? And yet, people like, what would Socrates do? What would Aristotle do? What would Jesus do, right? And you have to regularly practice. So you practice indwelling and then you practice internalizing and you practice indwelling and then you practice internalizing. And that is how you basically start to afford the internalization of the sage and the creation of your ability, as Antisthenes said, what he learned from Socrates so long ago: to converse with yourself, to get, to enter into something like platonic dialogue with yourself.
The idea is to develop a mental model, develop a psychotechnology, to be able to have an internal dialogue with it. And it shouldn’t be limited only to the professional domain, it’s also a very powerful thing for everyday life. A good demonstration of this approach is Internal Double Crux from therapy.
Relevance Realization #
One more extremely important skill that intersects with the others — it’s an ability to know what’s relevant at the moment (maybe it’s more an attribute or a mental tool that’s not under direct control). This helps to understand when to zoom out, to notice that something is wrong, this way or premise is incorrect and it’s time to get back. This skill helps to maintain a proper discussion with coworkers, when people tend to speak about so many different things, diving into technical details that might be simply irrelevant to the actual problem. It helps to write proper comments on reviews. Not to mention a hundred typos, but to pay attention at the correctness, performance, potential architecture problems. It helps to open proper PRs, without noisy refactoring, &c.
Same happens with the ability to focus at will. Sometimes it’s important to be passionate (recently extremely hackneyed word), it’s important to care about the code, to find it valuable and get into the flow state, but also it’s important to be able to turn it off and throw the code away. It’s all about context, trade-offs, and relevance. It’s important to figure out the relevance and realize it. It also helps to understand what’s a good problem. Good problem finding is an important skill and it’s a matter of wisdom.
Conclusion #
The listening to this lecture course was a long but life changing experience. It’s impossible to tell how many things I’ve learned and that’s for sure that I will go over it again at some point in the future with a fresh look.
Here, I’ve tried to briefly note the metaskills available for a software engineer, how valuable they might be, and that they are not specific to the software development. They are quite general and might be relevant in other domains as well, including everyday life situations. Improving and working on them helps to gather more insights and grow not only as a professional, but also as a person.