4 ms·
I think economically it may make sense to hire fresh people for less money, burn them out and then have them leave soon. This may be one reason for ageism .
by Ididntdothis 7y ago
I think economically it may make sense to hire fresh people for less money, burn them out and then have them leave soon. This may be one reason for ageism .
- wongarsu 7y agoProvided it's easy to get new people up to speed and experience isn't overly important
- the_gipsy 7y agoLong term, no. Short term maybe, or it's not "economically" but "politically" desirable.
- justin66 7y ago> I think economically it may make sense to hire fresh people for less money, burn them out and then have them leave soon. If the job is focused on smashing rocks with a hammer to make smaller rocks, that's probably true.
- OccamsMirror 7y agoAbsolute bullshit, but the metrics being gathered are all askew. When you've already fucked your productivity with bad management, what difference does a high turnover rate have?
- james_s_tayler 7y agoThe people I've seen add the most value and be the most productive are always the ones with the longest tenure. Because they know the software backwards and they know the domain too. 18 months is barely a blip on the radar.
- Cerium 7y agoAbsolutely agree. At my job, 2 years is still a baby, many people are at 5, 10, or even 15 years; and the company is only about 25 years old!
- ChrisMarshallNY 7y agoThat may be why there is so much emphasis placed on dev frameworks like React, because you can get JS programmers right out of BootCamp onboarded fairly quickly (and cheaply). Also, there is a great deal of emphasis placed on process. If you will have new people taking over the code all the time, you should have a fairly strict requirement for patterns like MVVM and VIPER, and require new hires to be able to adapt to these quickly. The Japanese had a similar structure, because they rotate engineers around every couple of years. The engineers stay with the company forever, but they change jobs frequently. That means that it's very important to have a strict policy of heavily-documented, inflexible process, and you can have vast legacy codebases that people are afraid to change. If you can farm a lot of that out to a dependency framework, then it becomes S.E.P. (Somebody Else's Problem). I'm not a huge fan of this approach, but many companies seem to feel it works. There was a company called Taligent that took this to extremes. I read their style guide (I spent a great deal of time researching how other people did development -it made me quite the cynic). They had the strictest, most convoluted structure I've ever encountered. Taligent eventually collapsed under its own weight. The idea was to only have Architects be creative, making line programmers little more than data entry. Programmers couldn't do stuff like create new classes without getting permission from an Architect.
- Ididntdothis 7y agoDon’t forget that large companies internally are very similar to a communist planned economy. They have five year plans and central planning. Everything flows from the top. They value predictability over everything else. So it makes sense to run everything like an assembly line where every position knows what they are supposed to do and can easily be trained. Only a few elite people get to work on the big picture and be creative. Personally I don’t like this but I’ll admit that it works.
- ChrisMarshallNY 7y agoIt does work, but is not a particularly good approach for consumer (or even pro) software. You keep delivering yesterday's technology, tomorrow. It's the kind of approach that you might use for space launch software, but even that can be iterated (as SpaceX is showing).