Tech work is n-dimensional
Tech work is n-dimensional
Forget the continuum: think n-dimensional space
Humans like to keep things simple. Binary if possible: good or bad, smart or stupid, tall or short, black or white, fast or slow.
When pressed, we will admit to a continuum. There are degrees of good and bad and few things—if any—are entirely good or bad.
We apply this same approach to tech work. Witness, for example, the ubiquitous categories of “junior”, “intermediate”, and “senior” developers or programmers, as if these skill sets live along a linear continuum.
They do not.
Never mind that they are so poorly defined as to create more confusion than they dispel, or that they are more related to prestige and/or pay than any particular skill set, they simply don’t belong on the same continuum.
Continua measure degree
The point of a continuum is to measure degree between two poles. If junior dev is one pole and senior dev the other, with intermediate devs finding a home somewhere in the middle, then this strongly implies that the difference between a “junior” dev and a “senior” dev is one of degree.
That is, they do the same things, but one simply does them better. Hence a junior dev becomes a senior dev by “junior-devving” better, not by learning entirely new skills.
But now look at job descriptions for so-called senior developers and you will see that they include skills that are not only not required for junior devs, but also absent if not outright discouraged.
For example, senior devs often act as mentors, coaches, trainers, leaders, etc.—none of which is seen as the purview of a “junior” dev.
These skills are orthogonal
There is really only one continuum that counts. It ranges from “get the fuck outta here” at the bottom up through “I guess that’s OK” all the way up to “please can I have your baby” at the top.
It is a continuum of the quality of the work done. There is one for every skill.
These continua form axes, each a particular talent or skill. Here are some of the various axes upon which “developers” often live:
Commodity coding: repeating established patterns with minor variations.
Bespoke coding: going from blank canvas to unique new product.
Mentoring: helping others to define and fulfill their career or life goals.
Coaching: realtime feedback intended to improve performance in the moment.
Teaching: facilitating and inspiring the acquisition of new skills and knowledge.
Leading: blazing a new path and inspiring others to come along.
Managing: organizing activities to improve performance and achieve goals.
Emotional maturity: acquiring wisdom, patience, and empathy.
Life experience: enhancing pattern recognition through long practice.
Granted, these are oversimplifications and there may be some minor overlap. And, often, people have more than one of these skills. One person might be a great teacher, but a lousy mentor, while another person might be excellent at both.
I’m sure there are more skills that are regularly required to do good development work. And similar axes can be drawn up for those who start off as testers, UX engineers, designers, architects, etc.
In general, as we become proficient on one axis, we tend to spend more time developing other axes.
And all of these skills are different. Some, such as bespoke coding, are heavily biased toward innate talent, while others, such as commodity coding, can be acquired simply by consistent practice.
Similarly, emotional maturity and life experience can greatly enhance mentoring, coaching, and leading. As “experience” implies, these generally require significant amounts of time to acquire, although time, though necessary, is not sufficient. Some folks never really grow up.
But really we are working in nine-dimensional space here.
If we set each axis to range from 0 to 100, then we can see that one experienced developer, Connie, might be a 70 on commodity coding, a 20 on bespoke coding, and a 90 on mentoring.
Meanwhile, another experienced dev, Bob, might be a 90 on bespoke coding, a 15 on commodity coding, and a 5 each on mentoring, coaching, teaching, and leading.
Of course, we could also weight the axes.
The question we should ask is this: Why do we think that the Bob is better than Connie or vice versa? The truth is that it depends on the context.
Everything is contingent
There is no such thing as a “great” developer or a “lousy” developer. There is only one thing that matters:
FITNESS
Is the developer fit for the task we’ve assigned?
Some developers are fit for many tasks, others for very few. But it doesn’t matter as long as they are fit for the task we are asking them to do.
If you take a bespoke dev such as Bob above and put him in a coaching or leadership role, then he is going to suck mightily at it. He just wants to be left alone to solve puzzles, but he solves those puzzles better than anyone else on the team.
Why the hell would you put him into a role that demands talents that he not only lacks, but also disparages, rather than putting him where he will do awesome work?
Similarly, our commodity coder, Connie, will be miserable if you put her in a role that requires her to invent new features. But if you put her as a mentor working with commodity devs, she will excel.
Not everything is a damn hierarchy
If there is one thing that humans love even more than binary thinking, it is hierarchies.
You can’t put three people in a room for fifteen minutes without them figuring out who is above or below whom in the pecking order. And woe unto the human who dares to step outside their assigned slot in that hierarchy.
But hierarchies lend themselves to nonsense such as gluing on new skills as one ascends the hierarchy, or replacing them entirely. It’s apples and oranges, as they say. Or more accurately, canyons and quarter notes.
This leads to the utterly asinine but pervasive career path that puts some technical skill such as coding or testing or business analysis at the bottom of the hierarchy and “upper” management at the top.
Seriously? If a plumber works long and hard at plumbing, then eventually they can work themselves up to lounge singer? Anyone actually know what orthogonal means?
Even the naming gives away our ape-like love of hierarchies and our assumption that up (higher, taller) is great and powerful and heroic while down (lower, shorter) is odious and weak and cowardly. Why else do we put our alphas on pedestals and force the rabble to genuflect or even prostrate themselves?
It’s not a hierarchy or a continuum. It’s an n-dimensional space, where n is the number of axes of interest.
OH MY GOD! Not the maths!
Yes, the maths. Once we’ve located both our devs and our desired skill set in this nine-dimensional space, then we can calculate the Euclidean distance between these two skill sets (points).
Ha, ha! I like to code, so naturally I wrote some code to do this. Sorry for the lack of syntax highlighting. Substack appears to be shit on that front (Cantankerous Coder will soon move to its own website). But you can probably make this out if TypeScript doesn’t terrify you. Should work if copied and pasted into a REPL.
type Skills = Record<string, number>
const bob: Skills = {
commodity: 15,
bespoke: 90,
mentoring: 5,
coaching: 5,
teaching: 5,
}
const connie: Skills = {
commodity: 70,
bespoke: 20,
mentoring: 90,
}
const desired: Skills = {
commodity: 25,
bespoke: 75,
mentoring: 100,
}
function calculateDistance(
a: Skills,
b: Skills
): number {
const sumOfSquares: number =
Object.entries(a)
.reduce(
(acc, [key, value]) => {
const differenceSquared = Math.pow(value - b[key], 2)
return differenceSquared
? acc + differenceSquared
: acc
},
0
)
return Math.round(Math.sqrt(sumOfSquares))
}
calculateDistance(bob, connie) // 123
calculateDistance(bob, desired) // 97
calculateDistance(connie, desired) // 72In this example, we’re only counting the axes for which both a and b have values, but one could simply require values for all the axes.
Here we can see that despite Bob’s vastly greater skill in bespoke coding, Connie is actually a better fit for this role, 72 vs. 97 (remember that a lower number means a shorter distance).
This is because mentoring is highly valued in the role (100) and Connie excels at mentoring (90), which outweighs the difference in bespoke coding skill between Bob and Connie, 75 vs. 20.
Hmm. Think this might actually be useful? I’ve tried to implement a system like this in an enterprise setting if only to help the coaching staff, but with little success. It’s that damn pecking order. You need a champion high enough up in the stupid hierarchy to push it through. Or a tireless evangelist. I’m neither.
Note: I am not recommending that we run around calculating these distances using the above formula and making decisions on pay and careers based on them. There are many stumbling blocks to that approach, not least of which is how do you measure these skills accurately and fairly? And how often do you update these measurements?
And it’s not just about whether someone has a skill, but more importantly it’s about whether they are willing to apply it. In the final analysis, as they say, performance speaks for itself.
No, this is intended as a mental model: a way of looking at complex tasks in terms of the different orthogonal skills that are required and the degree to which each plays a role. Then assessing people using those same axes to determine who is best for a role, as well as where there is need for growth, for both individuals and the organization as a whole.
There can be plenty of other axes, too. For example, a role requiring collaborative effort might have a “plays well with others” axis. Roles might require good analytical skills, time management, organizational skills, people skills, sales or marketing skills, etc. The possibilities are endless.
Each role in a company is unique in its location in the n-dimensional skills space, just as each person in an organization inhabits a unique n-dimensional location as well.
Tags R Us
To avoid the foolish habit of placing varying and orthogonal skills along the same continuum, it might be better to avoid continua and hierarchies entirely.
Why not tag?
It could be as simple as tagging a role with the skills required: coaching, mentoring, teaching. Or the tags could be weighted: coaching(70), mentoring(50), teaching(90).
To do this well, we’ll need to spend time actually analyzing what it is we need to do for our organization to be successful. What is the breakdown of skills and how are they best distributed?
Stop thinking in terms of job titles (the worst idea) or even job descriptions and start thinking in terms of aggregations of mostly orthogonal skills requiring some degree of expertise. Kind of like alchemy, no?
If you can describe the different tasks in the organization clearly using n-dimensional space, and if individuals in an organization can clearly position themselves in an equivalent space, then the organization can see who is best for a task and—better still—individuals in the organization can make decisions about what skills to acquire or enhance.
It’s the career development, stupid.
Don’t hold your breath
Of course, this takes effort: the one thing that is always in very short supply. So much easier just to have some HR person who knows precisely nothing about the role write an insulting job description with lots of pointless and irrelevant criteria, for example, “must have n years experience with x”.
One person can have n - 3 years experience and be superb at x, while another could have n + 5 years experience and be absolutely shit at it. This is a perfect example of a bad metric and, worse, making stupid assumptions based on that metric.
Consider: if I built the same web application twenty times, and in that same period you built twenty distinctly different web applications, are those equivalent?
Obviously, no. If we need a twenty-first iteration of that web app, then I would be the best choice. I’ve built a similar app twenty times already!
But if we need something new using skill x, then you are the clear choice. You’ve done something new with skill x twenty times already!
So it’s a bit more complex than just creating skills axes. But that would at least be a move in the right direction.
I have a lot more to say about this, but that’s enough for today.