5 ms·

To be fair, I wouldn't consider someone who has been in the same company for 13 years an expert on the quality and quantity of devs on the market. Your experien

by mcluck 4y ago

To be fair, I wouldn't consider someone who has been in the same company for 13 years an expert on the quality and quantity of devs on the market. Your experience within your one company is not a good indicator of the rest of the market. Most people I know jump jobs every 2-5 years going on to more and more interesting opportunities. Even at these more interesting places, the message is the same: we cannot find enough people.

betaby 4y ago
Job hoppers with 2 years stints can't have any deep domain knowledge. Neither can judge even their own code quality/robustness/usefulness - that way too short period of time.
- BobbyJo 4y ago
  Define "domain". You can have tons of experience in a single domain across many jobs. In fact, I would wager that working in the same domain with differing groups of people, toward differing requirements, gives you a richer understanding of some domains compared to spending 10 years at a single employer. Yeah, they aren't going to be the best with a specific company's stack, but they'll likely have a better perspective on how it can be improved.
- scrollaway 4y ago
  You're way off. There's a huge diminishing return on how much you can learn at a single job. From my own experience, I'd say it peaks around 6-12 months. There's some longer-term things you can only learn by being at the same company for a long time (such as "how to grow a startup from 1 to 100 employees" and what comes with that), but those things are usually outside the realm of what software engineers interest themselves with. If you're spending more than 2 years at the same company, the only domain knowledge you're growing is that of how to be an employee at that particular company, and very little of it is very useful outside of it. Things like "I know how all these Facebook internal tools work inside-and-out". Cool, we don't have or need them cause we're a totally different company, now what? Whereas a lot of even surface-level knowledge can bring a huge amount of unique perspectives and solutions. And my own most successful projects have been the results of combinations of experience in multiple domains at once. And none of this prevents you from actually developing deep domain knowledge. For example, I have NOT held the same job for a decade and a half, but I HAVE been using Python (and other various software) for all that time, in a large amount of very varied situations, and I absolutely have "deep domain knowledge" there.
- yrgulation 4y ago
  “job hoppers”. the era of working at the same factory for 30 years is long gone. job huggers have been out of fashion for a while. in modern tech you need to freshen up every few years or else you’re history.
- hellohowareu 4y ago
  This idea of gathering deep domain knowledge isn't very realistic in my opinion. Not in slow moving, poorly managed companies at least, when compared to being a solo dev or working at a fast paced, well-organized startup. I built a full stack app in about 6 months, at one point, 5 years ago. (frontend js framework, backend js framework, SQL framework) I now work for a company whose applications aren't much more complex than what I built, in terms of systems and complexity. Though the apps are definitely much more polished and with many more complete UX & usage options. It makes millions of dollars. At least at most large companies which are lumbering, slow moving, where 60% of people contribute and 40% of people barely hang on by pretending to work (largely because A. they don't know what's going on due to poor documentation and poor requirements gathering, and B. they aren't qualified in the skills needed for currently under development work). As a solo developer, I move much faster and learn much more on my own, than I do at my current job. Why? Because I direct my own work, on my own projects. I don't have someone who has never built an application, who has a project/product manager title, trying to gather requirements for something they've never done before. Not to mention that they've never founded an organization and led it to success. So, they don't understand how Apps are built, and the don't understand how Organizations are built and guided efficiently... Combine this with a company that has a bunch of legacy applications and is now moving into somewhat over-hyped frameworks... Yeah... Don't get me wrong-- I like the people I work with. I see a lot of under-qualified people in management who are slowing down the system because they can't efficiently organize people to do what they don't understand-- they have too many unknown unknowns in their ability to parse out upcoming work. Unfortunately, most of them were hired for currently-fashionable political reasons.
  - ZephyrBlu 4y ago
    > I now work for a company whose applications aren't much more complex than what I built, in terms of systems and complexity. Though the apps are definitely much more polished and with many more complete UX & usage options. It makes millions of dollars. This is exactly what I’ve found. Most of my work is technically easier than my personal projects. There are definitely parts that are far more complex, but the vast majority of the company isn’t working in those areas. From what I’ve seen, if you want domain knowledge you have to dig for it.
feoren 4y ago
I like how you and everyone below this comment seem to know exactly what my job involves. I've worked on somewhere around 200 different systems and been a/the lead developer on several dozen. I've worked in ~20 different engineering and science domains and gotten enough knowledge that engineers in the individual fields ask me questions about their domains and ask me to QC their Excel spreadsheets and calculations, having nothing to do with software development. I've worked with 6 different database technologies from FoxPro to SQL Server to Redis. I've written code professionally in 8 or 9 languages. I've written programs to calculate statistical outliers, perform mass-balance calculations, do spell/grammar checking, unit conversions, translation, some light AI, and lots more. I've written proposals and made marketing materials. I've worked with hundreds of different people on projects of all sizes. So everyone assuming that I stopped learning anything new 12 years ago can fuck right off. I'm not saying this to brag, I'm saying this to point out that all these assertions that "you should change jobs every 2 years or you stagnate" or "you can't learn your job deeply in 2 years" are both completely unfounded bullshit assumptions. It completely depends on what the job is.
- ZephyrBlu 4y ago
  This is a great copypasta. Where did you find it?
- mcluck 4y ago
  I think you're still missing my original point. You have been in your own bubble for a decade. It may have been a very interesting bubble with a lot to learn but it's still a bubble. You don't have a sense of what other companies are looking for because you haven't asked them or put yourself on their radar. You don't have a sense of the level of skill of developers outside of your bubble. I'm not claiming to be an expert here either but you specifically present yourself as being knowledgeable on the subject because of your 13 years with one company, which just doesn't make sense

by mcluck 4y ago

betaby 4y ago

Job hoppers with 2 years stints can't have any deep domain knowledge. Neither can judge even their own code quality/robustness/usefulness - that way too short period of time.

BobbyJo 4y ago
Define "domain". You can have tons of experience in a single domain across many jobs. In fact, I would wager that working in the same domain with differing groups of people, toward differing requirements, gives you a richer understanding of some domains compared to spending 10 years at a single employer. Yeah, they aren't going to be the best with a specific company's stack, but they'll likely have a better perspective on how it can be improved.
scrollaway 4y ago
You're way off. There's a huge diminishing return on how much you can learn at a single job. From my own experience, I'd say it peaks around 6-12 months. There's some longer-term things you can only learn by being at the same company for a long time (such as "how to grow a startup from 1 to 100 employees" and what comes with that), but those things are usually outside the realm of what software engineers interest themselves with. If you're spending more than 2 years at the same company, the only domain knowledge you're growing is that of how to be an employee at that particular company, and very little of it is very useful outside of it. Things like "I know how all these Facebook internal tools work inside-and-out". Cool, we don't have or need them cause we're a totally different company, now what? Whereas a lot of even surface-level knowledge can bring a huge amount of unique perspectives and solutions. And my own most successful projects have been the results of combinations of experience in multiple domains at once. And none of this prevents you from actually developing deep domain knowledge. For example, I have NOT held the same job for a decade and a half, but I HAVE been using Python (and other various software) for all that time, in a large amount of very varied situations, and I absolutely have "deep domain knowledge" there.
yrgulation 4y ago
“job hoppers”. the era of working at the same factory for 30 years is long gone. job huggers have been out of fashion for a while. in modern tech you need to freshen up every few years or else you’re history.
hellohowareu 4y ago
This idea of gathering deep domain knowledge isn't very realistic in my opinion. Not in slow moving, poorly managed companies at least, when compared to being a solo dev or working at a fast paced, well-organized startup. I built a full stack app in about 6 months, at one point, 5 years ago. (frontend js framework, backend js framework, SQL framework) I now work for a company whose applications aren't much more complex than what I built, in terms of systems and complexity. Though the apps are definitely much more polished and with many more complete UX & usage options. It makes millions of dollars. At least at most large companies which are lumbering, slow moving, where 60% of people contribute and 40% of people barely hang on by pretending to work (largely because A. they don't know what's going on due to poor documentation and poor requirements gathering, and B. they aren't qualified in the skills needed for currently under development work). As a solo developer, I move much faster and learn much more on my own, than I do at my current job. Why? Because I direct my own work, on my own projects. I don't have someone who has never built an application, who has a project/product manager title, trying to gather requirements for something they've never done before. Not to mention that they've never founded an organization and led it to success. So, they don't understand how Apps are built, and the don't understand how Organizations are built and guided efficiently... Combine this with a company that has a bunch of legacy applications and is now moving into somewhat over-hyped frameworks... Yeah... Don't get me wrong-- I like the people I work with. I see a lot of under-qualified people in management who are slowing down the system because they can't efficiently organize people to do what they don't understand-- they have too many unknown unknowns in their ability to parse out upcoming work. Unfortunately, most of them were hired for currently-fashionable political reasons.
- ZephyrBlu 4y ago
  > I now work for a company whose applications aren't much more complex than what I built, in terms of systems and complexity. Though the apps are definitely much more polished and with many more complete UX & usage options. It makes millions of dollars. This is exactly what I’ve found. Most of my work is technically easier than my personal projects. There are definitely parts that are far more complex, but the vast majority of the company isn’t working in those areas. From what I’ve seen, if you want domain knowledge you have to dig for it.

feoren 4y ago

I like how you and everyone below this comment seem to know exactly what my job involves. I've worked on somewhere around 200 different systems and been a/the lead developer on several dozen. I've worked in ~20 different engineering and science domains and gotten enough knowledge that engineers in the individual fields ask me questions about their domains and ask me to QC their Excel spreadsheets and calculations, having nothing to do with software development. I've worked with 6 different database technologies from FoxPro to SQL Server to Redis. I've written code professionally in 8 or 9 languages. I've written programs to calculate statistical outliers, perform mass-balance calculations, do spell/grammar checking, unit conversions, translation, some light AI, and lots more. I've written proposals and made marketing materials. I've worked with hundreds of different people on projects of all sizes. So everyone assuming that I stopped learning anything new 12 years ago can fuck right off. I'm not saying this to brag, I'm saying this to point out that all these assertions that "you should change jobs every 2 years or you stagnate" or "you can't learn your job deeply in 2 years" are both completely unfounded bullshit assumptions. It completely depends on what the job is.

ZephyrBlu 4y ago
This is a great copypasta. Where did you find it?
mcluck 4y ago
I think you're still missing my original point. You have been in your own bubble for a decade. It may have been a very interesting bubble with a lot to learn but it's still a bubble. You don't have a sense of what other companies are looking for because you haven't asked them or put yourself on their radar. You don't have a sense of the level of skill of developers outside of your bubble. I'm not claiming to be an expert here either but you specifically present yourself as being knowledgeable on the subject because of your 13 years with one company, which just doesn't make sense