How My Violin Teacher Made Me a Better Software Engineer
April 6, 2022
It isn’t every day that the lessons 11-year old us learned would greatly impact our present-day selves. That is unless you’re Paul and that lesson came from your violin teacher. That’s because the lessons she taught served him well, professionally and personally, and today, he’s going to share them with you.
When I was around 11 years old, my parents asked if I wanted to learn a musical instrument. I chose the violin. Little did I know how difficult of an instrument it would be to learn.
My tutor was very particular about everything I did, or, more accurately, didn’t do. I can still hear her voice…
“Keep your left wrist straight!”
“Don’t move your right shoulder!”
“Soften your right wrist!”
I found her approach uncomfortable, awkward, and difficult (or was that just 11-year old me?) at least initially. But over time, I started to relax my posture, and the position of my shoulders, arms, wrists, and hands just started to fall into place. What felt uncomfortable and awkward to start was now neutral, almost reflexive. And while it was still difficult, it was now manageable; it felt possible like I had a firm grasp and was capable of learning more.
So how and why did that happen?
While I didn’t realize it at the time, the reason for my transition was all of the strict lessons on the fundamentals; constantly being reinforced and demonstrated by a teacher. And this arrangement forced me to focus on form over outcome, giving me a broader and firmer foundation on which to build everything else on.
Spoiler alert, I didn’t become a violinist. But the lesson I learned from that teacher has served me well in life, both professionally and personally. And in my current career as a software engineer, a field of work that is constantly evolving and changing, the ability to learn new skills quickly and efficiently is critical to longevity.
However, before I dive into that and in honour of my violin teacher, I think it’s important to take it back one step and start with some fundamentals.
Descriptive vs. Procedural Knowledge
Knowledge can be categorized into two groups: descriptive and procedural. Descriptive knowledge is “knowing that.” Knowing that databases can be non-relational or relational, knowing that secure communication over HTTP is possible due to SSL and asymmetric key encryption, or knowing that Model-View-Controller is the predominant design pattern used by web application frameworks (to mention a few examples).
On the other hand, procedural knowledge is “knowing how.” Knowing how to design a relational database or a set of HTTP endpoints from a set of requirements is one example. Knowing how to develop modular and easily-extensible code tested by an automated, maintainable, and performing test suite is another.
Why You Need to Keep Learning as a Software Engineer
Early in my coding career, I developed a habit of what I now call, “coding blind.” This refers to having poor visibility or feedback (knowledge, essentially) on whether the code I wrote actually did what it’s supposed to do.
What I would do is simply write some code and test it manually to make sure it works. This was effective to a point. However, as things got more complex, the coding began to slow down. I mistakenly thought that “if only I could do it better the first time, this approach would be fine,” which quickly resulted in triple and quadruple checking my work before each manual test.
And often, it still wouldn’t work.
So I’d have to go back and trace through the code again, this time more carefully and methodically. Eventually, I’d get it working, just in time to move on to the seven other use cases that I had to test manually.
Fortunately, I was introduced to Test-Driven Development (TDD) around this time I was hitting a clear progression plateau.
Now, my first attempt with TDD was not easy. It felt awkward. I didn’t really get it. However, I was given an opportunity to pair the program with a technical agile coach who was not only able to help guide me through some of the basics while reinforcing the fundamentals (sound familiar?). The result was not only learning how academically but more importantly, practically.
How to Keep Learning as a Software Engineer
When one is learning a skill for the first time, there are a number of conscious decisions to make. For playing the violin, it could be, “how do I hold the bow?” For TDD, it could be, “where do I start when writing a failing test?” To help with these, we turn to a learning framework.
A learning framework can be defined as a supporting structure of concepts around which skills can be learned and developed. These include sets of rules or instructions.
The video on learning staccato for the violin below demonstrates this. In this case, the student is given three approaches. They’re told to pick one of them and then repeat (i.e. practice) until they learn the skill.
Another example of a learning framework could be an easy-to-remember acronym that one can reference. In TDD, for example, we use “Arrange-Act-Assert” (AAA) to help us plan and decide how to write unit tests.
As skill proficiency increases, it’s common to no longer have to make conscious decisions on specific sequences of behaviours. Instead, these behaviours become second nature, reflexive, and without deliberate thought. This is reflected in the Dreyfus Model of Skill Acquisition: a Novice requires a detailed set of instructions that they can repeat over and over again.
The Dreyfus Model goes further, however. It points out that learning frameworks can themselves become limitations. The Dreyfus Model asserts that learning frameworks should be tested by Advanced Beginners and Competent practitioners. Further, proficient and expert practitioners shift to a reliance on intuition, moving from adherence to frameworks to defining them, evolving them to meet the day’s challenges and readying them to be adopted by others.
That means the end result of this framework is simply no framework at all. Something that, in my opinion, aligns with the mark of being an expert – when instruction becomes intuition.
The need for software engineers to up-skill rapidly, effectively, and sustainably is only going to increase.
So what can we do about it?
Much like my violin teacher taught me, although unaware at the time, it’s critical to identify bad habits and address and correct them early on. This seemingly simple, although powerful practice, will help ensure avoidance of a progression plateau later, allowing you to capitalize on new opportunities while creating unique value as you progress through your career.
And if I had one piece of advice, it’s this: if you haven’t mastered the basics, go back and do so. Because as technology progresses, it’s only those with a firm foundation to build upon who will be in a position for long-term success.
Subscribe to Our Newsletter
Join the Thoughtworks newsletter list to receive curated content that exemplifies our Product thinking approach.
Fri Jun 2
Thoughtworker Spotlight: Priscila Araújo
Priscila Araújo has worn many hats across multiple countries, and we’re lucky to have her at Thoughtworks Canada. With over 10 years of experience from Brazil to Canada, she has engineering, delivery and product experience, just to name a few. Currently, as a Lead Product Manager, she works collaboratively with Thoughtworkers to build great software, driving impact by helping clients scale and grow. Priscila also shares her thought leadership by speaking at conferences and providing mentorship at Thoughtworks. As a strong believer in taking risks and trusting the process, find out in her Thoughtworker Spotlight how visiting Toronto on a scholarship and doing a Thoughtworks internship ten years ago influenced her trajectory from software engineering into the realm of product. When she’s not helping clients scale and grow or sharing tasty Brazilian treats with the office (the bolo de rolo she brought back from her recent Brazil trip was devoured in minutes), you can find her playing basketball, taking her dog out to play in the sun, biking by the lake and doing stand up paddleboarding in Toronto. If the weather calls for the indoors, she is a passionate plant parent and a coffee aficionado. With all of these interests, can you guess what her favourite product is? Hint: It definitely works as a great pair with any of these hobbies! Find out more in this week’s Thoughtworker Spotlight.
Fri May 26
Thoughtworker Spotlight: Jagbir Lehl Singh
Some may know him as Canada’s Head of Delivery, but Jagbir Lehl Singh is also a writer (check out some of his articles!), a foodie and a runner. His team would add aspiring rapper to the many hats he wears – you’ll have to join the team to see why! As a builder of high performance teams, he is laser-focused on driving his teams to deliver impact to clients by achieving their business goals. When it comes to scaling agility in organizations and creating structures where teams thrive, Jagbir uses his 18+ years of experience to support the growth of Thoughtworkers, developing them into leaders through his mentorship. If he’s not exploring Toronto’s latest gems for unique cuisine and beverages, you can find him outdoors, taking long weekend walks with his family. As a continuous learner who enjoys staying on his toes, can you guess what his favourite product is? Hint: It has been a constant companion of his for the last five years.