Exploring the skills needed for successful solution development
Defining the DevSkillDojo purpose
Author: Greg Fullard, Published: 2020-02-26
After sharing my initial (half-baked) plans for DevSkillDojo with some trusted friends and colleagues, I was made very aware that I need to be clearer about what I am REALLY trying to achieve here. Of course, I knew this, but it took some time for the thoughts to coalesce into a cohesive purpose. Here's my first attempt at defining it:
When we look at the world of software development, we are faced with two undeniable truths:
1. The Skills Shortage is universal
2. There are more learning resources than ever
Many people, including me, have been living at the sharp end of the current state of affairs. We feel like gladiators fighting in an arena against vicious beasts like low quality software, project delays, late nights, early mornings, changing requirements, ill-defined requirements and the worst beast of them all: Eventual Burnout.
And in the stands we have the crowds of executives, sales people and project managers who have come to watch the excitement, without putting any real skin in the game.
Sometimes it's a painful show to be part of, but at the same time it is also exhilarating! And I would not want to do anything else with my life. I would, however, want to do it slightly differently. The first thing I would want to change is to ensure that project teams actually have the skills they need to deliver on the promises that they make (or sometimes the promises that have been made on their behalf)
Like many other people, my natural instinct, when faced with colleagues who are struggling to deliver on their responsibilities, is to think that I could solve the problem by creating and presenting training. Whether in-person or through some electronic medium of a document, or video, etc.
And based on the amount of training that we see online, I am clearly not the only one.
But the voices in my head told me: Let's stop arrogantly thinking we know what the solution is, and spend some time investigating the matter properly, i.e. let's invest some time in proper analysis. Specifically, I'm thinking we should approach the subject from multiple angles (including, but not limited to):
- Understand who are the stakeholders involved in this game, because there are actually quite a few (e.g. new developers, established tech leads, business analysts, execs, product owners, etc.)
- Understand how the different stakeholders perceive the problem. How does it really affect their lives.
- Understand how the different stakeholders are attempting to solve the problem in their own isolated ways.
- Understand why these different, and independent, approaches are not 100% successful.
So the purpose of DevSkillDojo is really twofold:
1. Be a location to analyse to problem properly
2. Identify and implement practical solutions
So let me expand a little bit on what I mean with practical solutions (Keeping in mind, that these solutions are likely to evolve as we learn more about the problem itself)
Solve for: Listing and organising learning content
Instead of creating ever more learning content, we need to establish reliable ways of finding, organising, categorising and rating existing learning material. Effectively we want to do for learning material, what Google originally did for websites.
Solve for: Using complementary types of learning material
In addition to simply categorising learning content according to topic, we should also understand the different types of learning material available and how to leverage each type effectively. This is important because people learn in different ways: Some people read books, others watch videos, others follow practical tutorials, etc.
Additionally, different types of learning material serve different purposes. By using them together we can achieve better results with a shorter turnaround time. For example: One of the biggest struggles most learning developers face today is called Tutorial Hell. This describes a situation where you follow along with a tutorial and can complete the steps (which makes you think you've mastered the material), but as soon as you need to build your own solution, you have no clue how to proceed.
Tutorial Hell is a symptom of not understanding the fundamentals of the tools/frameworks/approaches you are using. Solving this critical issue requires the use of different types of learning material, including practical assessments, open ended projects and contributions to relevant, real-world projects.
Solve for: Understand the skills required to succeed
In the ever-evolving technology landscape that we inhabit today we are faced with new tools and techniques on a daily basis. At the same time, the skills requirements for specific jobs are becoming more difficult to describe.
For example: when employing a developer for a permanent position, you may be interested in the fact that they know Angular 2, but it is much more important that they are familiar with the fundamentals of Web Development and have a proven ability to learn new technologies. Why? Because in 2 years' time their Angular skills might be obsolete due to rising popularity of FlavourOfTheMonth.JS.
In contrast, when selecting a developer for a 6-month project, their actual granular skills are critically important. No matter how amazing someone's fundamental knowledge of algorithms and data structures are, a 6-month project requires people to hit the ground running. You don't have 4 weeks to learn a new tech stack.
Solve for: Soft skills and product agnostic skills
There are quite a number of tools available in the market for assessing specific technology skills. These are typically used during the recruitment process and certainly help to weed out developers who don't really have the skills they are claiming on their resumes. But these tools suffer from a critical shortcoming: They equate "Skill" with "Technology"
In the real world, a capability is a combination of multiple skills that work together. For example: the ability to build a RESTful service in SpringBoot, is actually a combination of many skills, including abstraction, decomposition, unit testing, component testing, debugging, HTTP, REST, JSON, Java, Spring, SpringBoot and Maven. Not all of these skills can be easily assessed and neither is it possible for a single learning resource to teach them all.
Building this capability by assembling multiple discrete skills is the magic of the human brain.
And then I'm not even mentioning the various soft skills and process skills like active listening, effective teamwork, principles of iterative development etc. A holistic solution for skills management should not ignore this subtle reality of skills.
Solve for: Map learning materials to skills
Because of the amorphous nature of skills, it is not always easy to define which skills can be learned from any given learning resource. Additionally, different resources teach skills at different levels of mastery. For example: A Docker tutorial for Java developers would be very different from a Docker tutorial targeted for Kubernetes administrators. And furthermore, both tutorials are likely to be dependent on Linux OS skills.
We need an effective way to map which skills, at which levels, are taught by which learning resources. Also, we need to know which skills are really prerequisites for each learning resource.
Solve for: Establish reliable measurements of skill levels
Instead of chasing a holy grail of a single platform that will allow us to assess and report all skills, we need to understand that different skills are measured in different ways. We need to establish a standardised rating system, but one that receives inputs from many review/rating sources. This may include online technical assessments, but should also include 360 reviews and self-assessments.
Solve for: Community-driven, flexible learning paths
One of the most frequent questions young developers ask me at the office is: What should I learn if I want to become X?
Essentially they are asking me for a learning path which will encompass multiple steps along the way, including courses, practical experience, certifications, etc. Although I always try to give a well considered answer, the reality is that my answers are incomplete. A better way is to establish a community-driven process for assembling learning paths. This will ensure that the best learning resources are selected based on recommendations across different content providers.
Additionally, learning paths need to be customisable based on the needs of the individual (or their tech lead)
Solve for: Identify over-served and under-served skills
I haven't done real research, but if you're searching the web for resources to become a software developer, Google's first few pages are filled with resources to teach front-end-driven development. This implies HTML5, CSS and FlavourOfTheMonth.js
Sprinkled in between you will also find what is called full-stack development, which focus on Node, Python or PHP.
Not that there is anything wrong with those technologies: They are amazing! But the reality is that those skills are over-served in the learning content market, while many other skills are almost ignored. It would be very useful to identify which skills are under-served, so that we can spend more time to find appropriate resources for them as well. This will help to build a balanced learning journey that teaches technical tools and frameworks, but also fundamentals.
Solve for: Cross-provider solution for tracking and rating
Most learning content providers offer very useful solutions for tracking your learning progress on their platform, but this ignores the fact that a typical person will learn from many different resources. We need a solution in which the learning developer (and probably their tech lead) can track progress across multiple resources from multiple providers.
Furthermore, we should have a trusted way to compare learning content from different providers. For example: Should I invest my time learning technology X using the beginner course on Udemy or Pluralsight?
Solve for: Skills exploration
To ensure your technology skills remain relevant, it is essential to be aware of the things you don't know. This really comes down to: You must know what you don't know.
I dream of a solution that uses fancy machine learning algorithms to establish a recommendation engine for skills. Some attempts already exist, but we have some way to go yet.
Solve for: Maximise microlearning opportunities
Given the vastness and the continuous evolution of the skills landscape, it is inevitable that big-bang learning is nearing end-of-life. This has been replaced with on-demand, self-paced learning. But doing isolated online courses every few weeks is not enough: There is more value to be gained from regular, DAILY, learning that moves towards a clearly defined goal.
If we can combine carefully curated content with rapid assessments, such a micro learning approach will result in better long-term returns. As they say: How do you eat an elephant?
How now, brown cow?
So now that I've brain-dumped some of the practical things that I'd like to tackle, I'm faced with the difficult question: Over the last 10 years of starting, running and eventually selling a successful software development company, I've been involved in skills-development the whole time. Why isn't this problem solved yet?
Why do I still sound like Mrs Bennet when I complain about things not getting done successfully (or at all) on many projects. Am I just a tiresome fool? Probably (ask my wife), but there is another side to the story:
Until now I've been trying to solve the problem in a one-dimensional way, i.e. I was not investing the time in analysing the full problem. Instead, I quickly:
- Identified the skills I felt the team needed
- Assembled a rigid list of learning resources (often without personally working through the material myself)
- Gave the learning path to the team, and
- Left it at that (hoping osmosis would fill in the gaps)
I might be a bit harsh on myself, but that is really what I did. And the reason (or so I keep telling myself) is that I never had enough time to tackle the skills problem properly.
Why wasn't there enough time? Because the first priority was always to deliver projects. Because in my world, successful projects pay the bills.
Which brings us to the crux of the matter: This problem is absolutely solvable, but it is not going to get solved automagically. Someone (actually a group of someones) needs to roll up their sleeves and do it. And if I plan to be part of that group, I have to figure out a way to pay the bills while doing it, so that I can do it properly.
That's the journey.
Subscribe to our newsletter to make sure you don't miss anything