Looking back and trying to understand how I have learned some of the most essential skills I have today, I realised how much I have learned by doing rather than by studying. I have learned to code by programming games. Web development by building a school website. Computer Science fundamentals by solving programming challenges. Software Architecture by designing solutions for complex problems.
And on the contrary, while I have a degree in Artificial Intelligence - the only topics I feel comfortable about are the ones backed by large course projects or the final thesis. To get most of the AI theory out of me, you'd need to practice hypnosis.
The same is true when it comes to the team work. Other than personal development of its individual members, teams themselves grow by doing. Each successfully completed project bounds people stronger, streamlines communication, improves operations and gives the sense of accomplishment.
Of course there's a learning from failure as well. Each failed project brings us a better understanding of reality which increases our chances for success in future. It is a common practice to run retrospectives after failures to discuss takeaways for future.
In fact, even if there was no effort to reflect, teams still grow by doing, thanks to the group memory. We will still recognise situations similar to the ones when we failed and avoid repeating our mistakes. Recognising similarities and patterns in general is what we are all naturally great at.
Sometimes team leads are keen to extract the wisdom from each bit of experience. They rush to act on each signal by introducing new rules and processes, frameworks and services. They want to prevent what seemingly caused the failure or reinforce what in their opinion produced the success.
Despite the good intention behind this attitude, it leads to dangerous consequences. I am guilty of this myself. Once an erroneous code ended up in production. After applying a fix, I have decided to personally approve each pull request to that part of the codebase. The delayed deployment process wasn't the worst outcome of this. The fact that I'd be doing an extra review for the code made the other reviewers unnecessarily relaxed about it. As for me, this additional bit of responsibility has quickly turned into a ritual of counting number of changed files and pressing the green button. All of these resulted in a few other serious issues in the same part of the system just within couple of months.
This mistake and some other similar lessons, taught me about importance of a holistic approach to the code review process, considering not only the code itself but the reviewers as well. This was an important learning through doing. Other than the code reviews I have recognised similar situations in many other engineering processes and ultimately got curious about systems thinking.
Thanks to our natural pattern recognition ability, when we learn by doing we also get better at things that do not seem related to what we are currently working on. That's the reason why I have entitled this article "Growth by doing" and not just "Learning by doing". Most of the knowledge that we acquire in practice cannot even be expressed or articulated. Somehow spending time designing UX of your app brings you good ideas about reorganising furniture at your place.
While indirect learning expands our growth beyond one specific domain, the way how we are doing things has an important implication as well. If a team is aiming to complete more projects within a short amount of time, it will learn how to make quick trade-off decisions and how to reuse existing solutions efficiently. On the other hand, it will not get better at designing scalable architecture or at keeping codebase simple and easy for maintenance.
Understanding this is the key for nurturing a healthy engineering culture. Engineering values need to be balanced. Choosing certain values means doing work in a certain way and this will always make some other desired values unachievable. Having clear principles about how things are done sets the direction in which teams grow in your company.
It works the same way on the individual level. Our attitude towards the work we do defines the direction and scale of our growth. Attitude itself is caused by our motivation and intention for the work. And if we link our motivation back to growth, we get a powerful reinforcing loop: Motivation causes attitude. Attitude defines growth. Growth boosts motivation. And so on.
P. S. On a related topic there's an interesting paper called The Two Cultures of Mathematics that describes how certain fields of mathematics were shaped by groups of scientists with two opposing views:
- The point of solving problems is to understand mathematics better
- The point of understanding mathematics is to become better able to solve problems
Top comments (0)