Ask HN: Breadth vs. Depth in Learning, What to Aim For?

Programming via practice is actually a very inefficient way of learning to program. It's sort of like a professional basketball player learning by playing matches. It wears people out fast and teaches them very little they don't know.

To truly improve, they have to train properly. A basketball player trains their dribbles, running, shots, peripheral vision. A programmer has a lot of other small things to train - algorithm, optimization, passing around bits of code from one class to another, or disciplining themselves to stay in flow.

My training routine breaks things down into 4 levels:

1. Understanding the concept. Also includes knowing how to google certain types of code, knowing what to look for, what to copy.

2. Being able to build it without any hints.

3. Feeling/instinct. You no longer have to think. Not only that, but you can immediately 'feel' a mistake or error, and where.

4. Potency. You do it faster and smaller. There's no end to it.

The people who are deep in level 4 are invisible to those at level 2 or less. Sometimes it seems like magic, sometimes it seems like incompetence or stubbornness.

Creativity only happens when you have many parts at level 3 and above. You have to internalize/feel the parts, before you can code very effectively. Then when you have a problem you're trying to solve, your brain just sorts it out in the shower.

But with programming, once you code something once, it becomes a function. Many people don't solve the same problem twice. It gets copied and pasted. And thanks to Stack Overflow, it's possible to go 20 years of experience without ever reaching level 1 skill.

This is not necessarily a bad thing. This means you can ignore parts like memory management or effective sort algorithms and focus on the important things. It's up to you to figure out which skills are really core to your ambition and focus on that.

A lot of juniors make the mistake of choosing breadth first. But there's so much breadth involved in making a modern web app that if you go for breadth it'll take you a decade to get to be good enough at anything for someone else to trust you to do it without micromanagement (i.e. To be mid-level instead of junior).

At the beginning you need only as much breadth as is required to survive with your stack. It's ok for entire other sections to be black boxes ("we get requests from the front end in JSON and we process the request this way return other JSON and somehow <hand wave> it gets rendered").

After that you want to work on depth until you can work on a single part of the stack (pick back end, front end, or sysadmin/ops) without help or supervision. To get there, you may need to even focus on understanding one site feature and its technologies and concepts at a time. You may need to spend multiple years on this first portion of the stack before hitting mid-level competency with it. That's totally normal.

Once you've gained the competency to work independently in one area, you're ready to increase your breadth again: pick another part of the stack and do a deeper dive there.

It sounds like you have gone with the breadth approach so far. Maybe go deep on a couple of things where there are problems at work.

You mentioned "little bit of mysql" dive on that a bit more. There is a huge amount of tuning that can be done on SQL queries to make them faster. If you have small data sets that are expected to grow over time, they may be fast now but will slow down. This is usually the biggest bottleneck on any web app.

In the early, wild west days of the internet, people stuck SQL code, Javascript, CSS and HTML into one PHP page (or Perl script or whatever). Good idea or bad idea? Those types of things have driven a need for separation of concerns. That is why MVC, MVVM, etc. have come about. Usually you are stuck with whatever design pattern your tooling uses.

Maybe have a discussion with your manager about what is driving the need to use micro services and docker containers? Typical useful answers are scale, traffic and reuse. If you get more of a blank stare or jumbled type of answer "monoliths are bad" then it sounds like someone wants to get buzzwords on a resume.

Part of the problems you may be suffering from is a system that is overcomplicated for no good reason.

1. Unless you have a truly massive number of users, or a very interactive UI, chances are you don't need Angular.js at all. Just node should suffice, perhaps with something like http://intercoolerjs.org/ if it's interactive enough.

2. Unless you have large number of developers, chances are you don't need microservices.

So maybe instead of thinking about breadth vs. depth, think in terms of simplicity vs. complexity— given what you now know, how would you simplify the system you have now? What can you take out?

(Organizational constraints might mean you can't actually simplify, but it's a useful learning exercise.)

Read code. In paper.

Do not clone a repo, compile it, and run it.

Get code about something you want to learn about, or code written by someone you admire, make a printed copy, and read it carefully.

Follow how stuff is done. Try to understand the hows and whys without a compiler at hand. Without documentation.

Then, start looking for stuff you don't know how it works and consult documentation only after you cannot figure out what's happening.

I learnt a lot of C++ and Win32 this way from Microsoft Systems Journal (a long time ago).

And believe me, it works.

If I were you, I'd just start a weekend project and see where it leads you. On a weekend project, you can make any change you want without anyone telling you not to. You'll find what you like.

Another great technique is looking back on your life and find some peak experiences. "Start with why" is a pretty cool course to go through, but you could also just reflect on your own. Find your best experiences, and do similar things.

I have tried doing the weekend project but there I have this problem that I want them to do the right way only. Result of this I almost spent my day exploring through all the packages and libraries and just starting enough that I can't move forward in any direction. I know I have to overcome this and do something concrete but yeah this is where I am.

A lot of time I spent my weekends doing datastructures and algo. It seems at that time that I am learning but there too I didn't see myself making any progress it resets every time I take a break of a week or two and I myself admit that I am not persistent in any of my choices on what to do on weekends. I work in a 6 day job here. So I got only one day, i am working on my efficiency and try to put myself in place where I can make some quantifiable amount of progress. But yeah happy to here that weekends are the way to assess and do new things.

"If it's worth doing, it's worth doing wrong before you can do it right." (because otherwise you won't do anything at all)

Don't use a library then. Do it all yourself manually, go through all the headaches. Then look at a library and see how they did it, pain is good soil for learning.

When you do things the wrong way, experience the pain ( the reason they are wrong ), and then you discover the right way, you really learn the lesson.

This is also the deep route ( doing everything manually without libraries ). So I'd suggest depth.

If you just want someone to tell you a framework: use nodejs, knex.js(mysql), express; react, redux, react-router, immutable-js, reselect

For a weekend project you should choose something useful to you so you have motivation to finish it.

Are you a blogger? Write your own blogging software so you don't have to deal with Wordpress and ton of plugins, build something tailor made for you.

That's just an example but I recommend choosing something which will benefit you personally as a weekend project otherwise it might be difficult to motivate yourself to finish it.