Hacker News new | ask | show | jobs
by dblooman 1878 days ago
As a recovering platform engineer, nearly 2 years out of the game, i identify a lot here. My experience is that platform engineers are mostly people who never actually write code for the platform that they have built, other than toy services to test, which are usually written in a language which isn't the company default.

Communication is difficult because platform, like SWEs, are supporting people, but the support is direct, so platform often have a torrent of people asking for things. This is a problem when the SWE doesn't know what they want because they are a newbie out of university, or worse, they know what they want, but don't know how to work the insane platform mono repo that requires 9 items on a checklist to get a IAM permission added that the platform team member told them about in a support slack channel.

I think a lot of platform teams also make their own lives harder by making too many abstractions. If it is impossible for an SWE to add a new resource to the cloud without a platform engineer helping, then platform are always going to be disadvantaged.

Control is also a big issue.

Platform want all the control and believe giving control away is going to cause a disaster. In reality, SWEs want 5% control, just to do the thing they have to ask you as a platform engineer to do anyway. But maybe platform engineers like that hero complex.

4 comments

An internal "platform" team is often just a mismanaged infrastructure team. Careerist managers and engineers advocate for a sweeping, complex, centralized system which competes with real-world products sold by outside companies. It starts with "my team will reduce costs" and then it snowballs into "the platform delivers value! Look at all the people working on the platform! We need to hire more people to build even more! We make money!"

A few years later, the platform's code is rotting, its interfaces are unusable, and all the original proponents have chosen to depart rather than to maintain the mess they created. The company is stuck with a legacy system, far inferior to the real-world product, which has been shaped by market forces and not the political dynamics of one, single company.

Polemic aside, I think internal engineering platforms are ok to build when the industry solution hasn't matured yet, isn't available, or is otherwise too expensive. Otherwise, I think the infrastructure manager should seek out the minimum abstraction (and team) that enables the simplest path towards buying from the outside.

Platform don’t want control they just don’t want to inherit infra that was setup by someone who didn’t know wtf they were doing. The common antipattern is fullstack would set something up then hand it over to platform when they leave or can’t keep it up and running
>In reality, SWEs want 5% control, just to do the thing they have to ask you as a platform engineer to do anyway

My experience has been product engineers ask for full root permissions when they need 5% and immediately report anything less as an impediment.

My experience as a product engineer and lack of root is that I spend 50% of my time asking people to do things that I could have done myself in 5 minutes.

I’ll confess that I sometimes break something that takes a day to fix, but I’m not sure if that’s worth it.

Especially considering I regularly wait weeks until platform can get around to fixing my specific issue.

I’d say you’re still in a somewhat decent position. I miss those times. The real worries start when you realize you’re spending the other half of your time fixing bugs that would have never come to existence if you wrote it the first time.
I'm curious in what world (company) platform engineers aren't SWEs.
When the "platform" is a cobbled-together mangle of CloudFormation, Python Lambdas, and Terraform. They call the people who did that SREs.

And by "They" I mean the Sales and HR people who get assigned to run engineering orgs at 100-200mm private businesses all over the US. AKA "Enterprise."

You would be surprised how few devops/platform engineers cannot write code that would get them a junior position for the code that runs on the platform.
Where people still follow old SysAdmin vs Dev silos. If you have follow checklists, open tickets, follow up on slack you are not really working on a platform, thus not a platform engineer either.
The dev-ops axis is orthogonal to the product-infra axis.