4 ms·

> there’s a big difference between having ten years of experience and having one year of experience repeated ten times Love this thought! It's surprisingly com

by 1920musicman 3y ago

> there’s a big difference between having ten years of experience and having one year of experience repeated ten times Love this thought! It's surprisingly common to meet engineers with 6-7 years of experience with incredibly bad habits that they picked up working essentially at a single company that they joined right out of college. Repeating the same questionable patterns for 6 years doesn't provide a lot of growth opportunity. In this context, FAANG's obsession with hiring new grads is a questionable practice, people get stuck.

roncesvalles 3y ago
I will always value someone who has worked at 5 companies for 2 years each more than someone who has worked at the same company for 10 years. Most of the learning in any job happens during the first year. Imagine someone who has onboarded 5 times into 5 different company cultures and architectural systems. Such a person is a walking software engineering textbook.
- medler 3y ago
  So you actually see “1 year of experience repeated 10 times” as a positive! I like that, but do I think there’s value in thinking about how a system should evolve over the long term and in seeing the long-term consequences of your own architectural decisions.
  - stouset 3y ago
    I’ve seen this play out so many times I’m tired of it. New team member joins. Super “productive”, rewrites enormous chunks of existing code and builds six new things. Great. Then they leave, and you find out the bits they rewrote were the carefully crafted and well documented protobuf APIs now replaced by ad hoc JSON where the parsing and spec are strewn across thirty places. The new projects you quickly realize make no sense whatsoever and don’t actually do the things they were supposed to do, but kind of look like it if you aren’t paying too close attention. Now they’re a “senior engineer” at the next company.
  - PH95VuimJjqBqy 3y ago
    I have a _perfect_ example of this. very often development teams will value re-use and dry to the point that they'll conclude they need to stuff most things into a common library and share it amongst all their codebases. Anyone who has seen this done long term has seen this accrete until everyone is afraid to change the common library for fear of breaking _everything_. IOW, the risk profile of something like this grows over time. It starts out small but each time a project adds it as a dependency the risk grows. and yes, I understand everyone is going to post about versioning and change management and all the myriad ways one can try and mitigate this. the point here is that when using a common library like this you must be circumspect in what you put into it. The risk threshold for it being worth going into this common library is going to be much lower for someone who pushes for a common lib and then skips to the next job vs someone who was there over the next 3-5 years and personally experienced the pain and fear such approaches invoke longer term. and to repeat myself since I know this is HN. No one is saying you can never have common libraries like this, what's being said is that the long term risk is much more likely to be respected by someone who long term experience and therefore that person with long term experience is much more likely to be able to design a system that can be worked on productively over the long term.
- djur 3y ago
  I couldn't disagree more. The first year is when you learn how to work at that specific company, on that specific software. The subsequent years are when you refine your understanding and decision-making by building on top of your first year's learning. It's when you learn which of the ideas you learned actually work and how they might go wrong. Being a "walking textbook" doesn't make you a good programmer. Thinking about how to build things, building them, and then taking responsibility for them -- these are skills that take time and sustained effort to develop.
  - roncesvalles 3y ago
    This sounds like it makes sense but in practice I've noticed two things: a) Many people who have only ever worked at 1 or 2 companies have some really critical gaps in their technical breadth. Every time I've switched jobs, I've had multiple "I can't believe we didn't use this at my last job" moments. b) I've seen many "lifers" in big companies who built some great big system at some point in the past and now do very little other than maintain this hairball. It's very rare that, for someone who has been in the same role for 10 years, their last 5 years were as productive as their first 5. Despite promos and all. You get older, the job gets easier, and you get lazier.
    - djur 3y ago
      a) This seems like a stronger argument for hiring multiple people with diverse experiences rather than favoring individual hires with lots of short gigs. b) This seems like a problem you can screen for during the interview process rather than engaging in resume discrimination.
    - espe 3y ago
      you both describe valid approaches, similar to a breadth- or depth-first search. one will get into deep waters with "some great big system", regardless of the specifics.
    - stouset 3y ago
      And on the flip side, people who hop around every year or two always seem to be able to build things quickly… and then they leave and everyone else gets both the surprise of learning how badly everything was slapped together plus the joy of of maintaining that hairball for years to come. Somebody who never spends an appreciable amount of time in one role never has to deal with the long-term consequences of their decisions and misses out on that opportunity to learn and grow.
CipherThrowaway 3y ago
I've heard that exact same adage used in reverse by those "6-7 years at the same company" engineers against engineers with careers of shorter stints. The logic being that if you never experience 5/6/7+ years of continuous ownership, you never get to see how your decisions pan out, and you miss out on other forms of longitudinal experience. If one thing is a constant, it is that engineers will always come up with these silly little adages and cliches to discount the experience of their peers and continue telling themselves they are the smartest kid in the room.
- dilyevsky 3y ago
  What are these 7 years projects? Sending a man on the moon? Most large software projects take 2-3 years or else they run serious risk of getting cancelled completely
  - classified 3y ago
    Webshit has a famously short half life, but there are many companies that want real products with real support and development over many years.
  - mcbishop 3y ago
    Your question gets a SaaSy reply.
  - deleted 3y ago
    [deleted]
  - tomasGiden 3y ago
    Very much depends on what you are working on. What SaaS is ever stopped being developed and doesn’t need ownership after 2-3 years? Products with embedded software might ship in 2-3 years but many still need bug fixes and new features long after that so therefore needs ownership.
    - dilyevsky 3y ago
      If it’s a saas then original mvp will take anywhere from 6mo to 2y then it either dies or scales in which case it’ll be nearly rebuilt again with a much larger team this time. Therefore you will not learn anything on year 4 that you didn’t already learn in year 3
randomdata 3y ago
I'm not so fond. As a farmer, I get years of experience. I only see about one crop grow each year, so it really takes decades to start to see patterns in the conditions the crops come up in (e.g. years of drought, years with little sunshine, years that are cold, etc.) with little in my control to change that schedule. Good management decisions require having an understanding of all of those patterns, and as such, a year is significant boundary. But in software, the most significant boundary is how fast you can work. The faster you can work, the more scenarios you can try. Time is not completely removed from the equation, but two developers with different performance characteristics can have wildly different experience levels after an equal amount of time has passed. In this case, a year is not a significant boundary.

roncesvalles 3y ago

I will always value someone who has worked at 5 companies for 2 years each more than someone who has worked at the same company for 10 years. Most of the learning in any job happens during the first year. Imagine someone who has onboarded 5 times into 5 different company cultures and architectural systems. Such a person is a walking software engineering textbook.

medler 3y ago
So you actually see “1 year of experience repeated 10 times” as a positive! I like that, but do I think there’s value in thinking about how a system should evolve over the long term and in seeing the long-term consequences of your own architectural decisions.
- stouset 3y ago
  I’ve seen this play out so many times I’m tired of it. New team member joins. Super “productive”, rewrites enormous chunks of existing code and builds six new things. Great. Then they leave, and you find out the bits they rewrote were the carefully crafted and well documented protobuf APIs now replaced by ad hoc JSON where the parsing and spec are strewn across thirty places. The new projects you quickly realize make no sense whatsoever and don’t actually do the things they were supposed to do, but kind of look like it if you aren’t paying too close attention. Now they’re a “senior engineer” at the next company.
- PH95VuimJjqBqy 3y ago
  I have a _perfect_ example of this. very often development teams will value re-use and dry to the point that they'll conclude they need to stuff most things into a common library and share it amongst all their codebases. Anyone who has seen this done long term has seen this accrete until everyone is afraid to change the common library for fear of breaking _everything_. IOW, the risk profile of something like this grows over time. It starts out small but each time a project adds it as a dependency the risk grows. and yes, I understand everyone is going to post about versioning and change management and all the myriad ways one can try and mitigate this. the point here is that when using a common library like this you must be circumspect in what you put into it. The risk threshold for it being worth going into this common library is going to be much lower for someone who pushes for a common lib and then skips to the next job vs someone who was there over the next 3-5 years and personally experienced the pain and fear such approaches invoke longer term. and to repeat myself since I know this is HN. No one is saying you can never have common libraries like this, what's being said is that the long term risk is much more likely to be respected by someone who long term experience and therefore that person with long term experience is much more likely to be able to design a system that can be worked on productively over the long term.
djur 3y ago
I couldn't disagree more. The first year is when you learn how to work at that specific company, on that specific software. The subsequent years are when you refine your understanding and decision-making by building on top of your first year's learning. It's when you learn which of the ideas you learned actually work and how they might go wrong. Being a "walking textbook" doesn't make you a good programmer. Thinking about how to build things, building them, and then taking responsibility for them -- these are skills that take time and sustained effort to develop.
- roncesvalles 3y ago
  This sounds like it makes sense but in practice I've noticed two things: a) Many people who have only ever worked at 1 or 2 companies have some really critical gaps in their technical breadth. Every time I've switched jobs, I've had multiple "I can't believe we didn't use this at my last job" moments. b) I've seen many "lifers" in big companies who built some great big system at some point in the past and now do very little other than maintain this hairball. It's very rare that, for someone who has been in the same role for 10 years, their last 5 years were as productive as their first 5. Despite promos and all. You get older, the job gets easier, and you get lazier.
  - djur 3y ago
    a) This seems like a stronger argument for hiring multiple people with diverse experiences rather than favoring individual hires with lots of short gigs. b) This seems like a problem you can screen for during the interview process rather than engaging in resume discrimination.
  - espe 3y ago
    you both describe valid approaches, similar to a breadth- or depth-first search. one will get into deep waters with "some great big system", regardless of the specifics.
  - stouset 3y ago
    And on the flip side, people who hop around every year or two always seem to be able to build things quickly… and then they leave and everyone else gets both the surprise of learning how badly everything was slapped together plus the joy of of maintaining that hairball for years to come. Somebody who never spends an appreciable amount of time in one role never has to deal with the long-term consequences of their decisions and misses out on that opportunity to learn and grow.

CipherThrowaway 3y ago

I've heard that exact same adage used in reverse by those "6-7 years at the same company" engineers against engineers with careers of shorter stints. The logic being that if you never experience 5/6/7+ years of continuous ownership, you never get to see how your decisions pan out, and you miss out on other forms of longitudinal experience. If one thing is a constant, it is that engineers will always come up with these silly little adages and cliches to discount the experience of their peers and continue telling themselves they are the smartest kid in the room.

dilyevsky 3y ago
What are these 7 years projects? Sending a man on the moon? Most large software projects take 2-3 years or else they run serious risk of getting cancelled completely
- classified 3y ago
  Webshit has a famously short half life, but there are many companies that want real products with real support and development over many years.
- mcbishop 3y ago
  Your question gets a SaaSy reply.
- deleted 3y ago
  [deleted]
- tomasGiden 3y ago
  Very much depends on what you are working on. What SaaS is ever stopped being developed and doesn’t need ownership after 2-3 years? Products with embedded software might ship in 2-3 years but many still need bug fixes and new features long after that so therefore needs ownership.
  - dilyevsky 3y ago
    If it’s a saas then original mvp will take anywhere from 6mo to 2y then it either dies or scales in which case it’ll be nearly rebuilt again with a much larger team this time. Therefore you will not learn anything on year 4 that you didn’t already learn in year 3

randomdata 3y ago

I'm not so fond. As a farmer, I get years of experience. I only see about one crop grow each year, so it really takes decades to start to see patterns in the conditions the crops come up in (e.g. years of drought, years with little sunshine, years that are cold, etc.) with little in my control to change that schedule. Good management decisions require having an understanding of all of those patterns, and as such, a year is significant boundary. But in software, the most significant boundary is how fast you can work. The faster you can work, the more scenarios you can try. Time is not completely removed from the equation, but two developers with different performance characteristics can have wildly different experience levels after an equal amount of time has passed. In this case, a year is not a significant boundary.