3 ms·
It's not popular because it's not realistic in most environments. In many cases it's advantageous to use those things you listed because that's what the market
by bstar77 5y ago
It's not popular because it's not realistic in most environments. In many cases it's advantageous to use those things you listed because that's what the market can provide talent-wise. I'd rather deal with learning new tech that's well documented than some custom lib that "just works" but no one understands because the architect left years ago. My whole career has been about consistent education, so that doesn't intimidate me. Working on undocumented architectures that I have to make substantial changes to (and not knowing all of the side effects) is what intimidates me.
Turnover is a reality that can't be ignored. New people come in and now have to figure out something that reads like a stream of conscience. It isn't well documented, doesn't follow the latest best practices and doesn't support modern paradigms and uses outdated frameworks/libs, but works great.
The apps I build always take into consideration the talent pool my employer intends to pull from. The reality is that they (usually) can't hire general "technologists" that are proficient at all layers of the stack. If the project is something that only you will ever work on, then you can do whatever you want and this whole conversation is moot.
- solipsism 5y agoit's advantageous to use those things you listed because that's what the market can provide talent-wise More silliness. Pay developers enough so that they'll stick around. If they stick around, then you don't need to hire for talent in a particular framework or language. You can hire for intelligence, creativity, passion, drive, whatever... and invest in training people when they get there. Jumping from framework to framework and language to language as the talent pool does is incredibly wasteful.
- bstar77 5y ago> Pay developers enough so that they'll stick around It's amazing FANG companies have any turnover based on that logic. Turnover happens for a variety of reasons... like global pandemics... you can't make a blanket statement like that and expect to be taken seriously.
- solipsism 5y agoSorry, I was speaking in common parlance and assuming most readers would realize that I don't mean literally 0 turnover.
- Oras 5y agoI believe you have agreed with me in your points especially regarding talent and turnover. The shiny tech today will be a legacy 6 months later or a year if you’re lucky. Then the talent pool will change and you can’t attract the devs who religiously follow new trends. You’ll end up hiring people to deal with your {legacy} system or as you pointed out .. substantial changing it.
- bstar77 5y agoReact/Redux/Angular all have staying power so I don't understand your point. I don't know what you mean by "shiny" tech. Other than specific libs that go unmaintained, most popular tech has some staying power.
- rapind 5y agoThat’s not a universal truth. Java was shiny once upon a time. Rails was shiny once, even C was shiny once. This stuff is still being used (not legacy). I’m sure when rails first showed up, people were calling it a fad. In JS land there’s a ton of churn though for sure if that’s what you were thinking about. Not all of it though.
- Oras 5y agoBeing used does not mean it is not legacy. Do you consider a system running in Java 6 up to date? But if it is stable, serving customers requirements then there is no need to replace it. The point I am making is, using the current {shiny} tools might not be the correct answer (it could be though depending on the use case). Just use whatever gets the job done faster and then iterate. Some developers will start solutionising based on technology instead of focusing what is the purpose of the system and how it will help users. AKA: CV driven development :)