Broad and shallow vs narrow and deep

Junior level developers often struggle to find work. There are a lot of reasons for this, more than I can go into in one article (I will be writing about that more). Junior developers also often struggle to figure out how to become mid level developers.

I've seen a lot of anti-patterns come up as junior devs take on these struggles.

In this article I hope to expose one of the major anti-patterns I've seen, and hopefully help a few would-be developers and software engineers get onto a useful path.

Firstly, why do I get to talk about this?

I have trained a lot of developers myself, and I have spent a lot of time setting up education systems for training software development skills. I know what it takes to get someone with no prospects (but with grit and aptitude) into a junior level dev job.

The latest stats are that over 90% of the people who have graduated the gold-standard web development course I set up for Umuzi since 2020 are employed.

So I know a lot about junior level talent.

I've also interviewed and interacted with a lot of people trying to get into mid-level positions. I've filtered out hundreds of people who call themselves mid level, but don't have much in the way of useful skills. It's not that these folks are incapable, it's just that a lot of people have a misguided approach to pursuing skills.

When I turn a person down I generally tell them why. There is a piece of advice I give over and over again.

That is what this article is about.

Misguided conclusions

Here's some misguided reasoning:

A mid level developer knows more stuff than a junior. They have a broader array of skills. Therefore to become a mid, a junior should broaden their skill-base by learning a whole lot of different technologies. They should also advertise that they have these skills by putting them on their CVs and public profiles so that employers can see that they have a broad industry knowledge.

Please.. no...

What's wrong with that?

What ends up happening is junior and aspiring devs go out and do a whole lot of introductory tutorials on a whole lot of different things so that they can put fancy sounding words on their CVs.

The thing is that introductory tutorials and courses tend to only scratch the surface of what a technology is capable of. Most importantly, they are typically designed to take learners down an easy and narrow path, they isolate learners from real life struggles and decisions. They typically do not advertise the limitations of the tools they focus on.

Of course, not all courses are created equal. I mean, I work in tech ed and I believe in the courses I've worked on. But it's a bit of a wild-west out there.

So what is a devling to do?

Get good at something. Really good.

If I see someone who knows a limited set of tools, but managed to do something significant with those tools then I'll come to the conclusion that this person:

• has some degree of mastery over their tools
• can probably master other tools
• has the grit and focus to pull off something challenging, they can hit their heads on hard problems and keep at it until they win
• has learned at least a few of those lessons you only really learn by tripping over your own shitty code. We suffer our way to wisdom

That last point is a really big deal! There are soooo many foot-guns in coding, and sometimes the best way to learn a lesson is the hard way. If you make a decision and have to deal with the consequences yourself then you develop a set of skills that are very hard to impart in a course.

How to go deep

Build something.

I'd suggest building something from scratch, even if it's something silly or niche. If you are learning a musical instrument, write some code to help you practice. If you have a collection of Magic cards, write some code to help catalogue your collection, if you like to travel, write some code to help you pack the right clothes based on the weather. If you can't think of any ideas, ask a friendly AI to help you out.

I'm honor bound to suggest that you contribute to an open source project ;) There are a lot. And you can learn a lot by contributing to a large code base, and interacting with people who really know what's up. Once you have started to develop depth of knowledge on your tools of choice, go look for related open source projects you can help out with.

For example, if you decide to build a Django application then you might want to contribute to an open source Django app that someone else kicked off.

But...

I in no way want to discourage curiosity.

A broad and surface-level understanding of a large ecosystem is very useful. It's handy to know the lay of the land. If you come across a problem and you know a little bit about a great many things then you might have an idea about where to look for a solution.

It goes a bit deeper than that: Knowledge of different technologies can allow you to think different kinds of thoughts. Imagine if you were around before batteries were a thing, there are all sorts of ideas you would not even be able to think of.

Ideas are built upon ideas.

So go broad, follow your curiosity, play with lots of things. Just make sure you keep your priorities straight.

Prioritize realistic projects so you can get the depth of knowledge, the mastery, that you will need to be successful.