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

9 点作者 dprophecyguy超过 7 年前

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.I am being careful to learn about all important stuff as in authentication and authorization, defining caching layer at backend side.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'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.I really feel afraid of telling my manager to use any given kind of layout for our code because I can'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?1 Am I going on a right path where I am giving breadth of topics more preference over depth.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.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's long but thanks for reading till now.

6 条评论

muzani超过 7 年前

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超过 7 年前

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超过 7 年前

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超过 7 年前

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 <a href="http://intercoolerjs.org/" rel="nofollow">http://intercoolerjs.org/</a> 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超过 7 年前

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超过 7 年前

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.

评论 #16389906 未加载