You're pretty obviously not a developer. I've worked in places with shiny new PCs and I've worked in places with stuff that was obsolete five years before. Given how expensive developers are and how comparatively cheap PCs are, it's a complete waste for a company to give developers old and slow machines to work on. Whether a company respects its developers' work enough to give them quality tools to work on is a fundamental consideration when deciding where to work. But sure, developers who don't respect themselves might be happy in a place that gives them bad tools.

@Kyralessa I am a developer actually.. and have been so professionally for the past 15+ years. FWIW I completely agree with you regarding PCs and other tools - when I talked about "toys" I was referring to things like frameworks, languages etc. Not PC's - BTDT with being given a shed of a dev machine and I couldn't agree with you more about it being sheer insanity. Can see how that might not have been 100% clear though.

Ah, then in that case we can reconcile, as I agree with you. While it's nice to have the opportunity to learn a new framework by doing the company's latest project in it, a lot of companies aren't interested in that, for good reason.

@Kyralessa Yep sounds like we're on the same team :)

This is all assuming that use of old tech & legacy code is the only issue. But I suspect there are management issues as well, particularly a failure to clearly articulate the vision and reasoning behind the technology choices that have been made (if there is any; if not then that's the primary problem), and perhaps a lack of openness to feedback and discussion from those in the trenches.

I find your distinction between hardware tools and programming tools to be completely arbitrary and unconvincing. I actually think that working with outdated programming tools can be way worse than working with sub-par hardware. This doesn’t mean jumping on every fashionable new bandwagon but that isn’t what you are describing.

@KonradRudolph The difference is that computers are cheap to replace, (compared to a developer's salary) but rewriting your codebase to use a new framework, or even worse, a new language, can be hellishly expensive. Sometimes a rewrite might be needed, but there's a big difference.

@Kyralessa actually, I think it is wonderful idea to give developers older and slower machines. It does wonders for code quality, as the code they manage to make run sluggishly on their machines will absolutely fly on the newer machines the customers have. On the other hand, if you give developers top of the line machines, they will still write the code that will still run sluggishly on their machines, but now that code will be absolute abomination when run on lower-end customer machines.

@MatijaNalis: It may improve code performance (though I doubt it), but it certainly won't improve code quality, because the more time-consuming you make it for devs to test their code, the less they'll do so. More broadly . . . if you get better results from making your employees less productive, then clearly you have a much bigger problem.

There's a whole lot of stuff in between "brand new shiny toys" and "legacy code". Sometimes companies will downplay the amount of legacy programming an employee will do while they are interviewing/applying, in which case, they have every right to be upset about being required to work on it too much. As someone who has worked on massive codebases written 10-20 years before I looked at it, I wouldn't have been happy if I didn't know I would be working on it before I accepted the offer to join the company. So instantly jumping to adjectives like "bratty" and "entitled" are a bit knee-jerk

And aligned with this, you can respond to the reviews by explaining that you do respect developers and buy them appropriate tools and equipment (assuming that you do) but that, yes, your work often involves working on older frameworks and supporting legacy code and that's not a secret. If you don't suck, then explain why the complaints aren't legitimate. If you do suck, fix it.

@Clay07g you mean **exactly"" what I recommend in the last paragraph of my answer?

@KonradRudolph That comment is weird, I don't see any mentions of hardware in the answer. Do you think "toys" means hardware, or where is the discrepancy?

@pipe Hardware is mentioned in prior comments.

@PatrickM I didn’t talk about a rewrite, let alone a complete one. It’s always surprising to me how utterly luddite software engineers can be. The arguments are literally indistinguishable.

@KonradRudolph You claim that I'm not talking about jumping on new fashionable frameworks etc despite my explicit clarification saying that's what I'm talking about. I have no problem whatsoever with you or anyone disagreeing with what I'm saying - but misrepresenting what I'm saying is just plain insulting.

@motosubatsu If that’s indeed the case then you are seriously attacking a straw man. Most people (including those pushing for changing development tools) are a lot more reasonable than what your description implies: Calling them “bratty” kind of set the tone for the discussion. Incidentally, that also makes it seem a bit odd when you then subsequently complain about being insulted. As for the misrepresentation: your answer can certainly be reasonably interpreted to be in line with your last comment. But your first comment invites misunderstanding.

If it is old SOFTWARE tools, there might be good reasons behind that (devil you know attitude, old customer specifications in long term projects, certified environments that leave no room for upgrades without recertification....)

@KonradRudolph Or maybe if you came off your seeming crusade to twist and doubt everything I say you might realize that I was carrying on the terminology as used in the OP and that the term wasn't aimed at any one person in particular, let alone you. If you think that is somehow equivalent to making direct attacks on me I suggest looking up the term "false equivalence". Look, I don't know what on earth I've done to earn your ire. I've given a good faith answer and attempted to respond to comments (including yours) in good faith to clarify where I feel there has been a misunderstanding. [cont]

Honestly at this point I don't know what else to say to try and make my position any clearer and whatever opinion you have of me and what I've said will just have to stand as frankly I'm done defending myself about things I haven't even said.

@motosubatsu Until your last comment it didn’t even occur to me to feel personally attacked (language like “bratty” is certainly insulting but it didn’t insult me). But, in they same vein, I have actually never attacked you. I attacked what I still think can be reasonably inferred as your position from your answer and first comment, where you explicitly call languages and frameworks “toys”. This, I maintain, is fundamentally a bad take, and smacks of luddism. And I don’t need to misrepresent your position to say that, I just need to take it at face value.

@motosubatsu Incidentally, I also agree with Patricks’s answer to my comment (as you would, presumably): switching tools all the time would be prohibitively expensive. But it’s a straw man position: Virtually nobody actually wants to do this.

@KonradRudolph oh I 've seen plenty of devs who joined a team and wanted to push for "their" solutions, "their" frameworks and "their" development tools. Sometimes those are good ideas, sometimes it's just what they are used to or they ignore the fact that the project needs to keep running and it's business-wise a bad decision to just switch it's framework. Similar for dev tools, you want to use your own fancy IDE, probably possible, perhaps too costly to get a commercial license package just for you. Switching to your favourite review tool? [cont]

@KonradRudolph You need to get the team onboard and continued discussions can distract the team. It's not black and white and it certainly happens.

@KonradRudolph I explicitly call new languages and frameworks "toys" because that's how I've seen many (particularly junior) devs treat them - as something interesting to "play" with rather than an evaluation as to the suitability from a business perspective. That said I have no problem with you disagreeing with that take. FWIW I've always taken the approach of suitability for the scenario at hand being paramount, regardless of relative age of a language/framework/tool/whatever. No luddism here! [cont]

This question is bizarre, the answer is somewhat bizarre, and the incredibly long comment chain here is fully bizarre. What's even more bizarre is that the mods here haven't deleted this comment chain yet.

@Fattie Well since most of the comments on here are (more or less) for discussion around clarifying the answer rather than seeing how many times they can fit the word "bizarre" into the comment length limit perhaps they thought they were useful?

"You're pretty obviously not a developer." It's amazing what folks will say online, assuming they will never actually meet in a bar and eg. get the crap punched out of them :O

The problem I see with the 'business' logic used by @motosubatsu is that, while I understand that the business itself has needs that must be met, the developers also have needs that must be met. As a developer, you know that our tools and technologies changes very quickly and if, as a developer, you want to keep yourself employable, rather than stuck, then working with old/obsolete tools and tech is a, well, dumb mistake.

I had a co-worker at a former employer that had been writing code, in COBOL, for the last 10 years (that was back in 2008), while I was using C# for newer projects. Guess who did not get stuck and was able to move on to get hired elsewhere after some time?

And he was aware of it himself... he said, and I quote (translated): "I committed career suicide for doing this same thing all this time; I don't know anything else."

Learn from my former co-worker and don't ignore your own 'business needs'.

@code_dredd which is why I say that the company should be upfront about what technologies they need people to work on - so potential employees can make an informed decision about whether it suits their needs as well. It's not a zero sum game.