On Learning at Work
As a passionate software crafter I tend to find myself on the innovators side of the curve. That is, whenever a new shiny thing comes out, then I feel the urge of reading about it, trying it and eventually using it.
I’ve been working with the same technology stack for some time. Plus, most of the projects I tackle entail a boring business domain. Writing software should be fun. Also, I love the feeling of learning stuff. This is why I strive to introduce new technologies in commercial projects whenever I can.
The above thought is something I’ve been guilty of in the past. It turns out, not only that hurts the value provided to the customers, it also does not translate to an optimal amount of fun and learning.
I decided to do better.
We are using NEW_BACKEND_FRAMEWORK and NEW_FRONTEND_FRAMEWORK with NEW_ARCHITECTURE, our customers are going to love our product!!
I have to be honest, I have never heard of a product manager say anything like that. In fact, in the shoes of a customer, I would never buy something just because it uses a cool new technology. What I look for is functionality, reliability, usability and delight.
The product team needs to nail the right product better than the competition and before burning the funds. Thus, the need for tools that allow to iterate fast and validate even faster. I’m pretty sure that using NEW_BACKEND_FRAMEWORK and NEW_FRONTEND_FRAMEWORK with NEW_ARCHITECTURE would not support such a process.
Does that mean that learning in a commercial project is bad? Absolutely not. Some is paramount, some is waste.
In projects nobody knows for sure what’s the right thing to do next. That is why a short cycle of hypotheses and validation is so powerful. In other words, learning what customers need is essential to succeed.
However, re-learning how to achieve something in a new tool is a loss of time. But there’s something worse than that. A new technology is intrinsically immature, lacks documentation, has a poor ecosystem and is novel to the majority of developers. It does not seem a good enabler of fast iterations.
Of course, there are situations where something new could provide an edge. But that should be added to the pile of the hypotheses to be validated. Unfortunately, new ideas almost always seem to be better than what they really are. Maybe they are great ideas but it’s not possible to know until they are made concrete.
When it comes to commercial projects I believe in cultivating one’s sense of intrinsic reward. In the book Flow, Mihaly Csikszentmihalyi, writes
An autotelic person needs few material possessions and little entertainment, comfort, power, or fame because so much of what he or she does is already rewarding.
I’d say project work is fun and provides learning through another lens. I choose to embrace that. But I still want to learn shiny new things!
Learning works much better when one is in control of what is the problem to solve. In other words, crafting the perfect problems to learn the proper things. Plus, it has a different lifecycle than a commercial project. Sometimes I pick up a tool just to realize I want to move to something else a few hours later. If I committed to a given choice too early, I could become stuck and miserable.
Also, being in charge of one’s challenges is a prerequisite to get in a state of flow:
In positive psychology, a flow state, also known colloquially as being in the zone, is the mental state in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by the complete absorption in what one does, and a resulting transformation in one’s sense of time.
Here’s what I do: on the project I focus solely on its success and leave the superfluous out. The time saved by keeping things simple I use to have fun and learning. The best part is that, the two activities contaminate each other: project work inspires learning and learning makes me a better professional for the next product.
Should you decide to try a similar approach, be mindful of the Parkinson’s law:
Work expands so as to fill the time available for its completion
In other words, be clear on how many hours to dedicate to each activity and then enforce the timebox ruthlessly.
This is the first post I write here that does not cover any functional programming. Please share feedback! 🙏
Support my work by tweeting this article! 🙏