4 ms·

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 learni

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.

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.