4 ms·

I think it's specifically a disease of the frontend community to believe that nothing you knew about programming 3 years ago is relevant anymore.

nostrademons 5y ago
Nah, not really. My second example has to do with internal frameworks inside a FAANG, where the average half-life of code is about a year (i.e. half your code is deprecated or deleted a year after you write it). I've observed similar technology shifts with backend code (where MySQL was hot in 2003, PostGres in 2006, MongoDB in 2009, Cassandra in 2011, PostGres again in 2015, and now there's this huge explosion of storage solutions) and in platforms (where we were all about the web in 2007, all about mobile in 2010, all about blockchain in 2013, all about smartwatches & VR in 2015, and all about Ethereum & smart contracts in 2018).
- closeparen 5y ago
  I don't think workers' entire skillsets are obsoleted by any of those changes, unless you specialized in trend-chasing (obvious risk) and maybe if you refused to board the NoSQL train. But even now those 2003 RDBMS skills have a place again! High scalability companies are back to using traditional DBs where it makes sense.
  - munchbunny 5y ago
    I agree with this. While the flavor of the year frontend stack might change, since 2008 when I started dabbling in frontend, the fundamentals really haven't changed: understanding DOM, understanding the JavaScript execution model, understanding the layout models, understanding the complexities of dealing with data binding over asynchronous events and simultaneous users, and so on. jQuery didn't change any of that (although it drastically improved ergonomics). Angular didn't. React didn't either. My experience has been that paradigms and tools can move fast and are relatively straightforward to pick up. Deep understanding of the underlying problem domain and the systems underneath the abstractions is harder to pick up, but the concepts move more slowly.
- quanticle 5y ago
  > Nah, not really. My second example has to do with internal frameworks inside a FAANG, where the average half-life of code is about a year (i.e. half your code is deprecated or deleted a year after you write it). That's exactly the same web-dev mindset, only applied to backend code. I find it remarkable that you take a half-life of 12 months to be a given, rather than a screaming red flag. Yes, the world changes, and code needs to change along with it, but it doesn't change that much. Replacing 50% of your codebase every 12 months, year after year, indicates to me that the organization is just replacing poorly architected code with different poorly architected code, not better code. The codebase is on a random walk, and any forward progress it makes is due to chance and evolutionary pressure, rather than reason and design.
  - closeparen 5y ago
    Remember that the architecture competency in FAANG exists in the context of a 2-3 year average tenure. And this elides a tendency to change teams internally even more frequently than that. It is unlikely that a senior engineer rated "Exceeds" at design and architecture in Silicon Valley has ever learned from or been evaluated on the consequences of their own decisions at more than 4 years out. Median probably one year.
    - kyralis 5y ago
      An average tenure hides a good number of people with longer tenure than that. I'm personally a counterexample to your point, for instance, and I know quite a number of others on other teams at my company (one of the FAANGs). Turnover is definitely not uniform and a 12 month architecture lifespan is not, in my experience, either normal or healthy.
      - closeparen 5y ago
        My experience is that architectures usually last 2-3 employee tenures, the point is the original architect usually doesn't see the outcome of their work.
jjav 5y ago
> I think it's specifically a disease of the frontend community to believe that nothing you knew about programming 3 years ago is relevant anymore. Exactly, and it is a shame. Stability and building on the shoulders of giants is how progress is made. Not by rewriting everything all the time. Luckily I don't work on frontend UI stuff. I learned UNIX, kernels, cryptography, TCP/IP, SQL and similar technologies in the late 80s to early 90s. While all of these areas have evolved and progressed, it's been a gradual incremental change year to year. A textbook on any of these topics from 1990 is still recognizably relevant, even where details have changed over the decades.

nostrademons 5y ago

Nah, not really. My second example has to do with internal frameworks inside a FAANG, where the average half-life of code is about a year (i.e. half your code is deprecated or deleted a year after you write it). I've observed similar technology shifts with backend code (where MySQL was hot in 2003, PostGres in 2006, MongoDB in 2009, Cassandra in 2011, PostGres again in 2015, and now there's this huge explosion of storage solutions) and in platforms (where we were all about the web in 2007, all about mobile in 2010, all about blockchain in 2013, all about smartwatches & VR in 2015, and all about Ethereum & smart contracts in 2018).

closeparen 5y ago
I don't think workers' entire skillsets are obsoleted by any of those changes, unless you specialized in trend-chasing (obvious risk) and maybe if you refused to board the NoSQL train. But even now those 2003 RDBMS skills have a place again! High scalability companies are back to using traditional DBs where it makes sense.
- munchbunny 5y ago
  I agree with this. While the flavor of the year frontend stack might change, since 2008 when I started dabbling in frontend, the fundamentals really haven't changed: understanding DOM, understanding the JavaScript execution model, understanding the layout models, understanding the complexities of dealing with data binding over asynchronous events and simultaneous users, and so on. jQuery didn't change any of that (although it drastically improved ergonomics). Angular didn't. React didn't either. My experience has been that paradigms and tools can move fast and are relatively straightforward to pick up. Deep understanding of the underlying problem domain and the systems underneath the abstractions is harder to pick up, but the concepts move more slowly.
quanticle 5y ago
> Nah, not really. My second example has to do with internal frameworks inside a FAANG, where the average half-life of code is about a year (i.e. half your code is deprecated or deleted a year after you write it). That's exactly the same web-dev mindset, only applied to backend code. I find it remarkable that you take a half-life of 12 months to be a given, rather than a screaming red flag. Yes, the world changes, and code needs to change along with it, but it doesn't change that much. Replacing 50% of your codebase every 12 months, year after year, indicates to me that the organization is just replacing poorly architected code with different poorly architected code, not better code. The codebase is on a random walk, and any forward progress it makes is due to chance and evolutionary pressure, rather than reason and design.
- closeparen 5y ago
  Remember that the architecture competency in FAANG exists in the context of a 2-3 year average tenure. And this elides a tendency to change teams internally even more frequently than that. It is unlikely that a senior engineer rated "Exceeds" at design and architecture in Silicon Valley has ever learned from or been evaluated on the consequences of their own decisions at more than 4 years out. Median probably one year.
  - kyralis 5y ago
    An average tenure hides a good number of people with longer tenure than that. I'm personally a counterexample to your point, for instance, and I know quite a number of others on other teams at my company (one of the FAANGs). Turnover is definitely not uniform and a 12 month architecture lifespan is not, in my experience, either normal or healthy.
    - closeparen 5y ago
      My experience is that architectures usually last 2-3 employee tenures, the point is the original architect usually doesn't see the outcome of their work.

jjav 5y ago

> I think it's specifically a disease of the frontend community to believe that nothing you knew about programming 3 years ago is relevant anymore. Exactly, and it is a shame. Stability and building on the shoulders of giants is how progress is made. Not by rewriting everything all the time. Luckily I don't work on frontend UI stuff. I learned UNIX, kernels, cryptography, TCP/IP, SQL and similar technologies in the late 80s to early 90s. While all of these areas have evolved and progressed, it's been a gradual incremental change year to year. A textbook on any of these topics from 1990 is still recognizably relevant, even where details have changed over the decades.