Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Can you give some concrete examples of in depth learning that one can't learn in a year?


Oh, lawd, help me.

Kidding. You ask a legitimate question. This is by no means a comprehensive answer, but...

1. Domain knowledge. I think most of us enjoy the creative and problem solving parts of software engineering. That takes domain knowledge and domain knowledge takes time. You will get an intro to your domain in a year, but mastery? I would bet against it.

2. Working on a hard project from start to finish and sticking around for the lessons learned after. This is just a math problem. You're useless for at least 30 days no matter how good you are. (More like 90 IMO...). So if you start working on a larger project with a new team, and that project takes 6 months, your year is ending rapidly.

3. Mastering truly large code bases. Not everything is a rails app. Some things are just hard. Mastery is difficult to achieve.

4. Engineering leadership. Even if you don't want to be on a management track, it's important for a seasoned, senior-level engineer to be able to lead/drive a project from start to finish.

...And I suppose you may think "But I do all of those." And maybe you do? Or maybe it's just really hard to see something that you're convinced isn't there.


Domain knowledge is only useful if you work in the same domain year after year. That's often not the case. Atleast I've worked with three completely different domains the past year.


Exactly. And you can't learn domain knowledge that quickly. And there is a pile of money and senior-level engineering positions available to those who can marry understanding of the technology with domain expertise.


Impact of architectural and design decisions. How hard to decipher certain code parts you are so proud about today are a year later - my experience is that people used to work on small projects or who change projects a lot generate hard to maintain/understand code.

Learning non-trivial codebase often takes much more time. I worked on bigger projects and someone who worked there only six months would not be allowed to do bigger or core changes.

Then there is domain knowledge (finance, healthcare, law, etc) if you do that kind of software. Six months is enough to learn surface in anything non-trivial and everything is much more effective if developer already learned that.

Of course, last two points are not really valid for small projects world.


Most of the things you describe are deep, but also very narrow and domain-specific; frequently it is also very company-specific. Such knowledge is far less transferable than one might imagine.


"Most of the things you describe are deep, but also very narrow and domain-specific; frequently it is also very company-specific. Such knowledge is far less transferable than one might imagine."

Agreed. It is the quickest way to become a 10x employee but unfortunately your current company won't give you a substantial raise for knowing their product and domain well and it is not transferable to other workplaces.


Working on a big/long running project end to end. If you jump ship after a year you won't really understand the impact of a lot of the decisions you made months ago.

Most companies wont let you make any high risk or big impact decisions in your first year of employment with them (regardless of whether you get hired at a junior or senior or tech lead level).

Experience in solving the more difficult problems that require expertise with the companies particular stack and internal architecture.

And many more. There are ways to mitigate these problems but few do.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: