
Ask HN: Breadth vs. Depth in Learning, What to Aim For? - dprophecyguy
Hey everyone,
This is Vijay. I am a junior developer and I start working for around 6 month ago. Here at my workplace they are using Angular and Node stack along with Mysql.
As I have told that I am working here for 6 month I have been exposed to all of these three technologies and I am learning all three at once. I worked on backend for 3 months then I switched to front end. Also a little bit of mysql for defining views to fetch different type of data that consists of joins and aggregate.<p>I am being careful to learn about all important stuff as in authentication and authorization, defining caching layer at backend side.<p>To learn good practices for good performance UI, where I have realized we have messed up our front end codebase a lot right now. Because we don&#x27;t have any senior I can ask questions too. 
All I could have counted on was myself and all the things I can explore. 
After 6 months of learning and trying all these things have now started to make sense. 
Why codebase layout is super important, why MVP, MVVM and almost anything sucks.<p>I really feel afraid of telling my manager to use any given kind of layout for our code because I can&#x27;t imagine in my head how a given methodology will help us solve make sense of our code in a good way. 
So I think I have a lot of questions right now?<p>1 Am I going on a right path where I am giving breadth of topics more preference over depth.<p>2. How to look at your codebase both backend and front end lay it out in a way that feels natural, what I meant is MVM and MVVM is kind of messed up when you have lot of things to put around. 
My boss is saying to turn monolith app into micro services and to use dockers and all which I still have to learn. 
So any kind if help would be appreciated.<p>Any kind of advice that you can give a 6 month old developer on which path to follow to become a world class problem solver. 
Thank you. I know it&#x27;s long but thanks for reading till now.
======
muzani
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.

------
cimmanom
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.

------
matt_s
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.

------
itamarst
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/](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.)

------
eb0la
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.

------
danschumann
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.

~~~
dprophecyguy
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.

~~~
danschumann
"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

