What do Software Engineers need to up-skill rapidly, effectively, and sustainably?
I’ve been thinking about this question since teaching a cohort at a coding bootcamp almost four years ago. While my students gained a tonne of knowledge from the experience, I was left wondering how we could continue to support the professional growth of these software engineers after graduation.
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. Knowing how to apply software design patterns appropriately based on context. Knowing how to develop modular and easily-extensible code tested by an automated test suite that is maintainable and performant.
The coding bootcamp I taught focused on descriptive knowledge. This category of knowledge is tremendously important. Because — despite the near-universal accessibility of search engines — one is still faced with needing to know what to Google in the first place.
Nonetheless, in my experience procedural knowledge is just as important. It forms the basis of skills acquisition. Truly “knowing how” to do something means having an ability to practice it effortlessly.
The bootcamp program expected students to do most of the practicing outside of the classroom, supplemented with office hours as needed. During office hours, students had the opportunity to work one-on-one with the instructor and assistant instructors. While deliberate practice occasionally happened during these sessions, many of them involved nothing more than troubleshooting and debugging homework assignments.
Nevertheless, I can confidently say that the coding bootcamp was effective at preparing students with the foundational knowledge and skills they needed to succeed as entry-level software engineers. The question still remained, however: what can we do to support software engineers new to the industry?
The importance of a coach
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 for me to learn!
In the beginning, I did not find it enjoyable. My tutor would be very particular about the smallest detail of everything I did, and how I did it.
“Keep your left wrist straight”
“Don’t move your right shoulder”
“Soften your right wrist”
Following these instructions was uncomfortable and difficult — at least in the beginning. I eventually relaxed into the posture and the positioning of my shoulders, arms, wrists, and hands. What initially felt awkward, eventually felt natural. It turned out that these strict instructions helped me avoid many bad habits that would have limited my progress later.
I believe that this is an important characteristic of skills-based learning. Focusing on outcome instead of behaviour can lead to bad habits. These habits can lead to a progression plateau. Furthermore, if a practitioner reaches a plateau, the habits that are preventing them from progressing can be particularly hard to shake.
To state it simply: “I don’t care how you do it, just get it done!” can be terrible advice for someone attempting to acquire a skill.
On the other hand, an experienced coach can help identify behaviour that can lead to these bad habits. A coach knows what to look for, and is skilled in providing the necessary feedback early and often.
Acquiring skills in software engineering
Early in my coding career, I developed a habit of what I now call, “coding blind”. This means having poor visibility (i.e. weak feedback), on whether the code I wrote actually does what it’s supposed to do.
I would write some code, then test it manually to make sure it works. This was effective, to a point. Once the problems got complex, however, the coding slowed down. In a mistaken belief that I just needed to get better at coding it right the first time, I’d triple and quadruple check before doing the manual test.
Oftentimes however, it still wouldn’t work. So I’d trace through the code, carefully and methodically. Finally, I’d get it working. Then, I’d move onto the seven other use cases that I had to test manually.
Fortunately, I was introduced to Test-Driven Development right around the time I was hitting this progression plateau. The first time I tried TDD was not easy. It felt awkward. I didn’t really get it. It was only once I had the opportunity to pair program with a technical Agile coach on a daily basis that I finally got over my discomfort and hesitation.
Despite being entirely different disciplines, I found that the same principle applied when I learned to play the violin. At first, it was an uncomfortable and awkward instrument to hold. Instead of making it easier, my tutor gave me specific instructions that made it even more uncomfortable!
In the long term, however, she helped me develop the fundamentals that prevented injury and opened to the door to new techniques. To name a few examples:
Holding my left wrist straight prevented me from developing carpal tunnel syndrome.
Learning to move the bow from my right elbow with a “soft wrist” allowed for me adopt and refine techniques such as staccato.
Learning frameworks in skills acquisition
The Cambridge dictionary has two definitions for “framework”:
A system of rules, ideas, or beliefs that is used to plan or decide something
A supporting structure around which something can be built
The notion of a “learning framework” can be therefore defined as the following:
A supporting structure of concepts around which skills can be learned and developed. These include sets of rules or instructions that are used to guide a student’s learning.
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?”
A learning framework could be as simple as a set of instructions. The video on learning staccato 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.
A learning framework could also 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 one progresses in a skill, one no longer makes conscious decisions on specific sequences of behaviours. Instead, these behaviours become second-nature. That is the essential purpose of practice. This is reflected in the Dreyfus Model of Skill Acquisition:1 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 and shed their reliance on learning frameworks completely.
Wrap up
Skills-based learning is counter-intuitive because the less comfortable approach is oftentimes the prudent one to take. Learning frameworks give us direction, but in the short-term make the learning journey harder. Nonetheless, this is vastly outweighed by the long-term benefits:
Bad habits are addressed and eliminated
Progression plateaus are avoided
Opportunities for acquiring advanced skills are unlocked
Lastly, learning frameworks get us only so far. A teacher — be it a tutor or coach — is critical when learning skills, regardless of discipline.
The model is covered comprehensively by its authors in the first chapter of Mind over Machine, available to borrow electronically at the Internet Archive.