aeschinder

In the 1980s, COBOL was taught in my computer database class. I actually used my COBOL skills at the federal government Veteran's Affairs job I had for several years after college.

If you are always chasing the latest language and get high on syntactic sugar, you are likely going to be a problem for management if you work at an IT shop because you'll be writing important one-off programs in various languages that people after you will be required to support or rewrite.

John Carmack wanted to hire only C++ devs when he was at Oculus but had to relent and hire JavaScipt bros because of Meta.

TCO isn't just a question on your business class exam.

Just so I understand...two stimmy checks are to blame for inflation and product shortages? I know this is a popular talking point, but there needs to be some facts to back this up. Supply chains were wrecked by shipping container shortages due to bottlenecking at ports as well as factory shutdowns. There are proven instances where businesses increased prices just because they could.

Microservices are excellent when you have a self-contained set of APIs that need to be updated independently of other code. You must adhere to a contract, publish the contract and provide backwards compatibility for all existing clients.

Perfect example is a Payment Service. You have API tiers, client tiers, backend service tiers and likely customer service tiers hitting it and getting payment histories, issuing refunds, and hopefully requesting payment transactions. This code will likely change constantly and you want to deploy it on your own schedule versus having to match the schedules of all of the clients.

Other candidates might be an image upload service that crops, resizes and creates copies for CDN origin calls or a fraud scanning API that scores text submissions.

You definitely want to keep the number of microservices SMALL. At some threshold the number of services becomes unmanageable because you have to support all the old interface versions.

Is the current API testable? So many times I've taken ownership of code that requires an active connection to a database to even be up and running. Changing the code so it's testable usually changes the code so much it is very hard to have confidence it works the same way as the original implementation.

My old company lived and died by its instrumentation of DAU (daily active users). We would try to refactor the code to an IoC pattern with DI but invariably we'd get blamed for a downturn in the numbers - but never lauded if the reverse was true. It was a losing game - we finally had to get management to commit to the modernization (never, ever say "rewrite") and power through the days of low DAU.

I've been thrown to the wolves many times before, having to absorb and trace huge commercial codebases and be productive the same week on making updates and answering questions. Over abstraction is a real thing - real smart developers seem to pride themselves on how much juice they can squeeze out of dependency injection frameworks such as Structure Map and leverage the syntactic sugar of these tools until the solution is almost crystallized with hyper engineering.

I'm telling you this because I don't think it's you necessarily, but that more and more there are codebases that are dense with this kind of thick obfuscating abstraction.

I dropped out of IT when I was 52. I'm 55 now and don't think I could keep up with the constant myriad changes in literally all aspects of tech. Change for change sake is a scourge that lots of companies fall prey to in the name of keeping up which feels to older developers like chasing the rainbow that is just over the next hill...

I was a manager at a well known .com for several years. HR exists to protect the company from its own employees. That's why you have to sit through mandatory DEI training, sexual harassment training and other indignities. Studies have shown that mandatory training does very, very little to change anyone's mind. It is simply to protect the company in case there is an incident.

As for layoffs, it is always Finance and HR that know about all of the plans before anyone else. HR will try its best to perform layoffs under the guise of "reorganization" of departments or the whole company. This gives them cover to get rid of undesirables, older (read "expensive") employees and other people problems.

Firing people is the hardest thing. It is simplicity itself if you are an executive VP or higher, but below that it takes a ream of paperwork, a performance plan and months-long periods where the employee sabotages work, "quiet quits" and makes things miserable for everyone around them. HR doesn't want to create a scene that might reflect poorly on the company.

I'm super jaded after 30 years in IT so I apologize if this is too negative a response.

Previous company of mine wanted to make drastic reorganization changes and so they hired McKinsey to simply echo what they already wanted to happen. This is to provide cover for upper management (a.k.a. the "wooden desks") who can then use the official McKinsey report as a shield against any backlash. They can simply point at the report and shrug their shoulders in apparent helplessness in the face of the recommendations of the "experts". It was quite the Office Space moment.