Unexpected glass ceilings for junior developers

You've all used spreadsheet applications, right? I'm referring to things like Microsoft Excel or Google Sheets. If you haven't, then this article won't make much sense. Also, you're missing out.

Imagine

Let's imagine that a company hires a new employee. Let's call him Jeff.

Jeff's job involves a lot of spreadsheet wrangling. Jeff doesn't know how to use spreadsheet formulae, so he fills in all the cells by hand. Jeff works sloooowly because he doesn't know how to use the tools at his disposal.

One day, Jeff presented a spreadsheet to his manager, Sheryl. Sheryl pokes around and immediately realizes Jeff hasn't used formulae - it's easy enough to notice; you just have to look at the cells. Or you just have to change a cell value and get surprised when related cells don't change value.

Sheryl can then tell Jeff about formulae and set him straight so he can be faster and more accurate on his next task.

The fact that Jeff did not know how to write formulae was a problem. Jeff's effectiveness was blocked. He hit a ceiling.

But the problem was discoverable. That means it is likely to be solved.

A better Jeff

Now that Jeff knows about formulae, he is able to work much faster.

But he has not yet discovered that you can drag formulae and values across a sheet. So when he writes a formula into a cell he can't reuse it, he needs to do a lot of repetitive typing to make sure all the formulae in all the cells are set up right.

He's better than he was, but he's still pretty slow and prone to human error. And he's not entirely sure he likes the whole formula-vibe. It seems like a lot of work for the benefit sometimes.

One day, Jeff presents another spreadsheet to Sheryl. She pokes around, and the values change as they are meant to. She checks the formulae in a few cells, and they check out.

So long as Jeff was diligent and didn't introduce obvious human errors in formulae, this problem is not very discoverable. Most people would not think to look for the use of $ signs in formulae or to look over Jeff's shoulder while he is working (especially if Jeff works remotely).

If Jeff's lack of knowledge is not addressed, then he will be doomed to move slowly, have a really tedious job, and be prone to hard-to-notice human error.

Jeff hit another ceiling. He's slow. He can't handle complicated things, he can't even reason about the capabilities of his tools. Sheryl is not impressed.

Discoverable and undiscoverable skill gaps

The main thing I want to convey is that if you hire someone, especially someone junior, there will be gaps in their knowledge. Some of those gaps will be easy to spot and, therefore, easy to fix. Some of those skill gaps will be harder to spot.

Skill gaps have symptoms. Discoverable skill gaps have symptoms that are easy to diagnose. Undiscoverable skill gaps have symptoms too, but they can be misleading.

When Jeff didn't know about dragging formulae on a spreadsheet, but was very diligent to make sure he didn't get any formulae wrong, then the symptoms would be:

• He is slow to deliver work
• He might also stick to building very simplistic spreadsheets because building anything too big would suck on a few levels. The size of the problems he could reasonably solve would be limited

Jeff's career growth is obviously limited until this gets sorted out.

Skill gaps limit career growth. And some skill gaps are hard to discover.

Undiscoverable skill gaps in code

Now consider the junior coder. If you hire a junior and they do things like copy-paste data and configuration across files, then it's easy enough to tell them that their stuff should be DRY and that they should be importing things where needed.

Now, imagine a junior whose algorithmic code is not DRY. They have multiple functions that do the same thing, or they have the same piece of code pasted into various places in the same function. You can tell them to make their code DRY, loosely coupled and cohesive, but that wouldn't help if they didn't understand what a return statement did or how the call stack worked.

It might seem like a silly example, return statements are obvious, right? It's so very fundamental...

Unfortunately, in my experience of teaching hundreds of people to code directly and indirectly through my work, I can tell you that a great number of very clever people get confused about return statements and call stacks.

And what happens when a person doesn't understand return statements and the call stack? They have problems similar to Jeff's in a way - functions are a fundamental mechanism for code reuse. If someone doesn't grok functions then they will be limited in the kinds of problems they can solve.

The sad thing is that this kind of skill gap is very easy to spot and fix if you know how to look. It just typically isn't noticed because the symptoms of this skill gap can be badly misunderstood.

A coder might hit a ceiling because they seem a bit sloppy, or lacking in aptitude. Maybe it looks like they are ignoring feedback and instructions.

Little misunderstandings can have very big effects.

Reasons for skill gaps

There are a lot of little skill gaps and subtle misunderstandings that are common in software development. There are many reasons for this - a lot comes down to a lack of metacognition skills: the many school systems teach people that memorization and understanding are the same thing. This causes a lot of problems. There are also confusing things built into languages and coding tools; for example, REPLs tend to get people to think that return and print(Python) or console.log (JavaScript) are equivalent. Programming is full of subtleties.

Of course, there are many problems and skill gaps a junior might have. This is because they are juniors. It comes with the territory.

A lot of those simple skill gaps would be easy to fill if discovered. But some of them are just very hard to notice unless you are very adept at working with junior coders.

The big problem is that some of these skill gaps have really bad symptoms. A junior could write very convoluted algorithms, buggy code, useless functions and generally bad code. They can only be capable of writing repetitive code that fits into tidy little boxes defined by someone else. They can be exceedingly hard to get value out of, not for a lack of aptitude or willingness to work, but because of subtle misunderstandings in how code works.

Just think about all the ways return statements, function calls, loops and order of operations can be misunderstood. A lot of new coders need to get coaching just so that they know what order lines of code run in.

This is a learning profession

If you want to be a successful developer or software engineer, you need to be an expert learner. It is up to the would-be or junior coder to get to a point where they are able to spot and solve their own skill gaps. There is a lot that can be said about developing one's skill in learning.

I can also say that I have met a lot of self-taught coders who have entered this industry and thrived through their own conscientiousness and power to learn.

That said, a lot of human potential can be wasted if skill gaps aren't discovered and fixed. Sometimes the fix is very easy - a half-hour conversation and a bit of practice can work wonders.

The hard part

Plugging skill gaps often isn't hard. Sometimes it can even feel a bit face-palmy if you have been in this game for a while.

The hard part is spotting skill gaps. If you have been coding for a while then you wouldn't think certain problems and misunderstandings exist, knowing to look for those problems and understanding how to decode their symptoms is not a skillset most software professionals develop.

Most employers and businesses are not well set up to spot these problems. There is a skill in this; there are techniques to do this efficiently. But often, the methods to discover a skill gap are different per skill gap.

A lot can be solved with pair programming, but in a business environment, pair programming usually is not done by skilled and trained teachers. And it's usually not done with the intention to teach; but rather the intention to produce code. It's a very useful tool, but not a silver bullet.

Takeaways

If you are a tech educator, it's your job to detect these hard-to-detect skill gaps and plug them. You usually can't just point a person at a tutorial or a video for passive consumption. Dunning-Kruger often keeps people from accepting corrections. This is the work.

If you are a junior or aspiring coder, interrogate your own understanding. Make sure you understand the order in which lines of code execute, and make sure you understand what each line of code does. Find ways to test yourself. Read up on "illusions of competence" and make sure you are not kidding yourself. This is the tip of the iceberg, but it's a start.

If you are an employer who works with junior devs, it's worth hiring mids and seniors with teachers' hearts. Get them to read this article. Get them trained as teachers. Or work with a code school who focuses on strong foundations and evidence-based teaching methods rather than catchy keywords and a fast pace.