3 ms·

I completely agree with you that an architecture like this would likely become cumbersome to maintain as product requirements shift. That said, I've noticed tha

I completely agree with you that an architecture like this would likely become cumbersome to maintain as product requirements shift. That said, I've noticed that new tech kinda feels like an arms race in terms of recruiting. Top companies pledge to use newer technologies as a carrot to lure in devs as older technologies fall out of style, so the expectation is then placed on developers to learn new tech in order to get those top jobs. I see this as the dark side of "always be learning new things", because we often justify the need to learn these new technologies by translating them into job opportunities.

PragmaticPulp 5y ago
> Top companies pledge to use newer technologies as a carrot to lure in devs as older technologies fall out of style, so the expectation is then placed on developers to learn new tech in order to get those top jobs. Having been on both sides of this (IC and hiring manager), I've realized it goes both ways: A lot of candidates assume that unless your company is using the latest technologies, it's not a good place to work. This drives a lot of team leads and engineering managers to try to play Buzzword Bingo to make their project look most attractive to candidates. Candidates see this and assume that they also have to play Buzzword Bingo to be compatible with those most attractive jobs. It's a vicious cycle.
kodah 5y ago
Like usual, our society operates in extremes. When I first came into tech businesses would use old, cumbersome stacks because refreshing every 5 years was of no benefit to business oriented people. A good chunk of businesses (still) don't really like the word refactor, so they don't integrate a certain percentage of it into the roadmap. Then engineers got tired of maintaining software that was on life support without acknowledgement, and the competition for engineers took over. Now you have incredibly new relatively untested stacks and tech being used as a recruitment tool. This might be my personal opinion, but if you write modular code and dedicate about 40% of your roadmap to refactor, commiting code upstream, and engineering related tasks you won't run into near as many long term maintainability issues.

PragmaticPulp 5y ago

> Top companies pledge to use newer technologies as a carrot to lure in devs as older technologies fall out of style, so the expectation is then placed on developers to learn new tech in order to get those top jobs. Having been on both sides of this (IC and hiring manager), I've realized it goes both ways: A lot of candidates assume that unless your company is using the latest technologies, it's not a good place to work. This drives a lot of team leads and engineering managers to try to play Buzzword Bingo to make their project look most attractive to candidates. Candidates see this and assume that they also have to play Buzzword Bingo to be compatible with those most attractive jobs. It's a vicious cycle.

kodah 5y ago

Like usual, our society operates in extremes. When I first came into tech businesses would use old, cumbersome stacks because refreshing every 5 years was of no benefit to business oriented people. A good chunk of businesses (still) don't really like the word refactor, so they don't integrate a certain percentage of it into the roadmap. Then engineers got tired of maintaining software that was on life support without acknowledgement, and the competition for engineers took over. Now you have incredibly new relatively untested stacks and tech being used as a recruitment tool. This might be my personal opinion, but if you write modular code and dedicate about 40% of your roadmap to refactor, commiting code upstream, and engineering related tasks you won't run into near as many long term maintainability issues.