How My Violin Teacher Made Me a Better Software Engineer

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.

Closing Thoughts

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.