4 ms·

Start off by going deep, not wide. You'll pick up other languages and technologies over time. Pick a stack that appeals to you and focus on it for a while, lear

Start off by going deep, not wide. You'll pick up other languages and technologies over time. Pick a stack that appeals to you and focus on it for a while, learning its idioms and best practices and improving your development fundamentals.

1_player 8y ago
Good advice, mine is somewhat opposite :) Never, ever, stop learning. Don't feel too bad if you can't find time for a personal project like everybody else seems to have. Just make sure you are up-to-date with the hectic changes in the programming world. Every single time you're on HN and you're reading an article about Kubernetes while you're just a frontend web developer expands your horizons and advances your career. And when you know something about most things, with some specialisation, go freelance and expand your skillset and knowledge further. The moment you stop learning is the moment your career crystallises and dies.
- sheepz 8y ago
  Reading is good, but often gives us a illusory perception of understanding, but things tend to stick even better when you experiment with them.
- rejschaap 8y ago
  Don't overestimate reading an article about Kubernetes. It creates awareness of the concept and what it could offer, but that is not the same as going wide, it is too superficial.
kenha 8y ago
I agree to this, but in the sense that you should dig deep and understand how something works under the hood. For example, ElasticSearch is “fast”, but what makes it so? What trade offs were made to make it “fast”? You may start seeing patterns on how good/bad tech stack are built (aka the meta), and those meta would help you a lot down the road in knowing what type of toolset you can use, common type of problems a given architecture would exposed to.
maxxxxx 8y ago
Agreed. Do something really deeply and for a long time. Getting started with a tech is always easy but only through several release cycles you learn the real difficulties of programming which are making changes to an old codebase, when to refactor, training new people on the system, deciding on adding new tech. But then don't get attached to this but be willing to move to other things if they make better sense. In summary try to develop good judgement based on real world experience.

1_player 8y ago

Good advice, mine is somewhat opposite :) Never, ever, stop learning. Don't feel too bad if you can't find time for a personal project like everybody else seems to have. Just make sure you are up-to-date with the hectic changes in the programming world. Every single time you're on HN and you're reading an article about Kubernetes while you're just a frontend web developer expands your horizons and advances your career. And when you know something about most things, with some specialisation, go freelance and expand your skillset and knowledge further. The moment you stop learning is the moment your career crystallises and dies.

sheepz 8y ago
Reading is good, but often gives us a illusory perception of understanding, but things tend to stick even better when you experiment with them.
rejschaap 8y ago
Don't overestimate reading an article about Kubernetes. It creates awareness of the concept and what it could offer, but that is not the same as going wide, it is too superficial.

kenha 8y ago

I agree to this, but in the sense that you should dig deep and understand how something works under the hood. For example, ElasticSearch is “fast”, but what makes it so? What trade offs were made to make it “fast”? You may start seeing patterns on how good/bad tech stack are built (aka the meta), and those meta would help you a lot down the road in knowing what type of toolset you can use, common type of problems a given architecture would exposed to.

maxxxxx 8y ago

Agreed. Do something really deeply and for a long time. Getting started with a tech is always easy but only through several release cycles you learn the real difficulties of programming which are making changes to an old codebase, when to refactor, training new people on the system, deciding on adding new tech. But then don't get attached to this but be willing to move to other things if they make better sense. In summary try to develop good judgement based on real world experience.