Last year, I was a guest on the Catching Up with Web Performance podcast, and one of the topics we talked about was continuing education and the things I've done to make sure my skills stay sharp over the course of my career.
Background
My approach is probably more academic than you might expect. At one point, I was considering teaching at the college level and have a master's degree in education. I have taught anything from guitar lessons to graduate-level college courses, conducted countless training sessions, and written hundreds of documents and how-to articles for my employers throughout my career.
Most of the books I read are either about technical topics or stories of human performance and feats of athleticism. I've always been intrinsically motivated to work on more complicated things and have a knack for goal setting.
My undergraduate degree is in a related field (Bachelor's in Electronic Media), but nearly everything I learned in my undergrad studies is now functionally obsolete. Since I started my career as a developer almost 2 decades ago, there have been major changes (to say the least) that have required hours of self-study and continuing education. I like to make sure I'm focusing on the right things and making the most of my time.
I do this primarily by using a professional practice guideline to get a sense of where my skill gaps are, set my priorities based on the goal I'm working toward, and then develop a learning path for myself using the resources at my disposal.
Software Engineering Body of Knowledge (SWEBoK)
SWEBoK is a practice guideline is authored by two professional organizations, the Association for Computing Machinery (ACM) and Institute of Electrical and Electronics Engineers (IEEE). A new edition is released every 10 years. The current version (v3.0) was released in 2014.
SWEBoK is a 300+ page document that summarizes 15 different areas of software engineering covering topics like requirements engineering, testing, maintenance, construction, processes, and more. It is technology-agnostic, and instead focuses on macro-level, generalized information.
Categories of knowledge
If we divide knowledge into categories, we have:
- Things you know
- Things you don't know
- Things you don't know you don't know
SWEBoK has been responsible for exposing me to new areas of the discipline of software engineering that I might not have found out about otherwise (category #3). Once I learn of new areas that exist, I assess whether it might be valuable based on my job or ambitions. If it is something I think is valuable, I move it to category #2 with the eventual hopes of getting it to category #1.
If it isn't something I think is valuable, it stays in category #2 until the situation changes. If there is something I think might be useful in the future, I make a note of it so I can come back to it later.
Software wisdom
There are pearls of wisdom within SWEBoK that helped frame my thinking about certain topics. The most valuable lesson I've learned in my career is a result of one of these.
Chapter 11, Software Engineering Professional Practice highlighted that there were skills that I needed beyond my technical abilities. Software isn't written in a vacuum. There's teamwork required to work with others, communication with clients and stakeholders, organizational politics that might require negotiation, as well as a psychological side needed to overcome the fear of failure.
Learning these skills have been transformational and has allowed me to progress both inside and outside of work. As much as the software landscape changes, soft skills are good indefinitely. This has been an area of continued focus, and it was the subject of my capstone project when I got my M.Ed.
Knowledge prioritization
I always have multiple items in category #2 that I want to promote to category #1, so prioritization is required. I have a lot of hobbies and interests outside of work, and I need to balance my work with other things I enjoy. There are situational factors that go into what I want to learn. It might be that I have a project at work that needs attention, an area that I want to make a focus, or the pursuit of a new job or promotion.
In another post, I gave a reflection on my time as a software engineering manager, and this was a perfect example of needing to prioritize a specific skill based on a situational change. My first time as a development manager was for a new role at the company I was working at, and I was promoted to the position from another business unit.
There was no blueprint for many of the things the business wanted to accomplish, so I needed to learn a lot about the business domain, back office systems, the skills of my team, and the overall dynamic of the personalities involved. The position was created because of difficulties the business unit was having with the company's shared services, and the SVP of the business unit wanted more control over project priorities. The situation guided my learning and skill acquisition.
Deciding what to focus on
Sometimes deciding what to prioritize isn't so easy and there might be multiple interests competing for my time. Years ago, I read a book called Unleash the Warrior Within by Richard "Mack" Machowicz. Mack was a US Navy SEAL, and the book is laden with lessons from his military career.
There are some lessons that I applied from the book to my own life. The first is that a relentless, singular focus is typically much more effective than trying to cover multiple things at once. Take out your primary target before moving on to the secondary one.
Another lesson that's in the book is how he uses the CARVER Matrix to give a ranking of importance and the impact that something has in relation to the goal. It was originally intended for military purposes, but it has been adapted to other areas.
Each letter of CARVER is a criterion. To use the matrix, you give each a score from 1-5, with 5 being the easiest or most beneficial. Whatever has the highest total score is what you should be working on.
If I adapt CARVER for continuing education, here is what that might look like:
- Criticality: how essential is learning this skill to my goal?
- Accessibility: how easy is it to learn this skill?
- Recognizabililty: Is the learning path clear or is it unfamiliar territory?
- Vulnerability: is the skill achievable in the time frame I have available to work on it? Are there obstacles or necessary resources that I don't have?
- Effect: how much closer will this skill get me to achieving my goal?
- Return on Effort: quantify the good that will come from the skill and when will its value be realized?
Being able to prioritize in rank-order has been essential in determining the best use of my time, especially during a period of intense-focus with a specific goal in mind.
Knowledge acquisition
As useful as SWEBoK can be, it's intended to be universal in its approach. Sometimes there isn't enough of a description to make an action plan, so that's when getting more specific is required.
For example, SWEBoK offers this in Chapter 2:
Architectural design is a creative process. During the design process, software designers have to make a number of fundamental decisions that profoundly affect the software and the development process.
If you are interested in learning software architecture, this is not much to go on. In terms of setting a learning path, I'll usually start with a book or a video course. As a member of the ACM, I get access to Pluralsight and Percipio, and my public library has access to LinkedIn Learning and O'Reilly.
The beauty of using either books or video courses is that they are comprehensive and organized in a logical sequence. When I was on the Catching Up with Web Performance podcast, I referred to this sequence as "crawl, walk, run" because learning escalates in complexity the further you get into a subject.
If I was following along with a bunch of disparate blog articles and YouTube videos as my sole means of learning, my experience as a learner might be less organized, and there might be essential information that gets left out.
Even if I don't end up using the book or course as part of my study, the table of contents of any book covering the subject you want to learn can be a great resource.
Since most books are meant to be read chapter-by-chapter, the information is grouped into a logical progression. When developing a learning plan for myself, I might examine the table of contents for multiple books and try to get a consensus of what the order should be.
Example scenario
Let's say that I am planning on looking for a new job as a staff front-end engineer 3 months from now. In order to identify the skills I need, I'll look at job postings and see if there are any patterns in the responsibilities and qualifications.
At the time of this article, the top 5 posts on Indeed for staff front-end engineer had the following mentions:
| Skill | Number of mentions |
|---|---|
| Architecture | 4 |
| Debugging and Testing | 4 |
| CI/CD | 3 |
| Code Review | 3 |
| Design systems / Code Reuse | 3 |
| Mentoring | 3 |
| React | 3 |
| Soft skills (teamwork, communication, problem solving) | 3 |
| Maintenance | 2 |
| Performance optimization | 2 |
| TypeScript | 2 |
From this analysis, I put anything that correlates to my goal into the CARVER matrix. I would consider myself extremely competent in a few of these categories, so I omit these from my list. I have experience with everything on the list, but I either need to review or want to advance my skills in the following areas:
| Skill | C | A | R | V | E | R | (total) |
|---|---|---|---|---|---|---|---|
| Architecture | 5 | 2 | 4 | 2 | 4 | 5 | 22 |
| Design Systems / Code Reuse | 4 | 4 | 4 | 4 | 3 | 5 | 24 |
| React | 3 | 4 | 5 | 5 | 2 | 3 | 22 |
This exercise requires honesty and reflection. I gave Architecture a score of 2 for accessibility and vulnerability because those operate at a scale that isn't practical to implement on a personal project. I could definitely architect a micro front-end or microservices architecture, but the traffic isn't there on any of my personal projects. If I was going to do this for my employer whose sites get millions of page views each month, I could bump up the score.
React gets a 3 for criticality and return on effort because I have a few production React apps under my belt. I don't spend all day working on React, so it is more a matter of brushing up on things. Also, I gave it a 2 for effect because it is a more specific skill, and I perceive it to have the least longevity among the other skills.
According to the matrix, I should spend my time learning design systems and code reuse. Chapter 3 of SWEBoK is all about software construction, and reuse is mentioned specifically in Section 1.4.
Reuse has two closely related facets: "construction for reuse" and "construction with reuse." The former means to create reusable software assets, while the latter means to reuse software assets in the construction of a new solution. Reuse often transcends the boundary of projects, which means reused assets can be constructed in other projects or organizations.
On the front-end, a great way to author code with reuse in mind is to think of them as components. Since design systems were listed in most of the job postings, it's easy to identify that as an essential piece to author components for others to consume.
I now can work on a short list of resources use in my self-directed learning. After searching through some resources, here is what I have on my list:
- Building Design Systems: Unify User Experiences through a Shared Design Language
- Modern Front-end Architecture: Optimize Your Front-end Development with Components, Storybook, and Mise en Place Philosophy
- _Practical UI Patterns for Design Systems: Fast-Track Interaction Design for a Seamless User Experience_
- Expressive Design Systems
- Frontend Architecture for Design Systems
Finally, in my social network, someone told me about a workshop instructed by Nathan Curtis.
Looking at the table of contents for these resources, common themes begin to emerge. Some of these themes include:
- Problems solved by design systems
- Organization
- Pattern identification and inventory
- Getting buy in
- Library or framework selection
- Documentation
- Workflow
- Maintenance
- Testing
Using this information, I select a resource that I feel covers the subject thoroughly but efficiently. As I learn, I might delve into other topics and supplement with blog articles or YouTube videos. For example, there are a number of different tools that people use for development. I might spend some time playing around with those and learning the differences between them.
In case you're wondering, this is actually a real scenario that I'm working on currently, and I've been at it for a few months. I did attend the workshop by Nathan Curtis, and it was definitely worthwhile. I was able to use some tips immediately at my current employer, and I keep on experimenting with things that were covered in the course. I also have read the Modern Front-end Architecture book linked above. My next one will be Building Design Systems. Personally, I like to learn a little and then put it into action to help digest the information.
As a result of reading the book and attending the workshop, I compiled a list of design systems and analyzed them for structure, what they provide, their flexibility, and documentation. One of the tangents that I went on as part of active learning and discovery was to start working with web components and Lit in particular, even though I already had previous experience with React.
Conclusion
Although my approach is very regimented, I'm not a machine. Sometimes my learning is very intense, and other times it's more relaxed. If I have a clearly-defined goal with some urgency behind it, that dictates whether I'm going to do an unrelenting, intense period of learning.
If my goal is a little less urgent, I'll back off a bit. I might still be learning and working on professional skills but with more balance. This is where I'm at currently; I'm working on the code reuse and design system stuff, but the staff front-end goal is not urgent. If the right opportunity comes along, I'll be ready, but I am currently employed and don't have an immediate need for a staff position or hard deadline to hit.
Sometimes, I just take a break from professional development altogether to prevent burnout. During this time, I might casually check newsletters and RSS feeds during my work day, but the rest of my time is dedicated to other interests.
This cycle is how I've managed to adapt to situations and keep learning over the course of my career.