[lhorie]

Big tech companies have entire departments dedicated to this sort of engineering, usually developer platform/experience/productivity, or other similar infra/platform orgs. I'm an author of an open source framework who got scouted to work at one (and I'm currently a staff eng).

IME, yes there's comparatively far more CRUD roles than platform roles. But bluntly speaking as someone who's been on both sides of the fence, platform roles are not for everyone. For these roles, there is a expectation of quality by very technical stakeholders and this creates some pressures and incentives that don't necessarily exist in orgs that cater to non-technical faceless stakeholders.

In practice, a big challenge is to avoid being someone who is "not hardcore enough" (i.e. incapable of implementing large scale reusability due to lack of ability, tendency to cave to timeline or other pressures, or distaste for "office politics") but also avoid being "too hardcore" and being constantly in the weeds chasing some cool clever idea that might not align w/ overall picture.

One thing that is often overlooked in open source projects with sizable communities is the amount of cat herding you need to do. People have all sorts of ideas for "features and improvements" and sometimes your job as a BDFL may be to say "no" to your most ardent supporters. This also happens a lot for staff level platform work.

[jacurtis]

> sometimes your job as a BDFL may be to say "no" to your most ardent supporters. This also happens a lot for staff level platform work.

You hit the nail on the head. You've heard of a "yesman" (i recognize the sexism in that phrase, but it is the colloquial term), people that simply say yes to everything. I always joke that I am a "no-man". My job is literally to say "no" to probably 12-15 people a day. I say "yes" maybe once a week. It is actually exhausting and frustrating to be in this position.

I can't talk too much about what I do, but I am a staff level platform engineer and run a platform that no one has heard of, and no one has used directly, but it affects most people reading this. Because of how important the security and infrastructure is, my job is to field requests all day long, say "no" to almost all of them, and accept 1-3 things a month that our team actually works on.

Saying "no" so often and being "the bad guy" that no one wants to give ideas to is frustrating and difficult. It is the hardest part of the job, far more than the technical component. I actually discuss it with my therapist nearly weekly, it takes that significant of a toll on me. I enjoy the core of the work, but these externalities of the job wear me thin and I often fantasize of going back to the time when I just showed up in a daily standup, took a ticket, and went away to work on it. Essentially what I am saying is "the grass is always greener", remember that.

[hgsgm]

Why are your people asking so many bad questions?

Good questions are "how can we X?" And good answers are "here's how: Y"

Then the asker decides if they are willing and able to Y.

[grepLeigh]

Most of these kinds of questions have to do with feasibility, where the question asker doesn't have all the context needed to:

1) Decide: is this worth it for the business? NOW?

2) Delegate: ok, we've decided it's worth it NOW. Who is best equipped to execute?

So, that's not a "bad question."

Most of the time, saying "no" also comes with helping the requester de-scope to meet the crux of their obligations, save face on any commitments they won't be able to meet.

Saying "yes" means figuring out what the work will displace.

A significant part of my job as a staff infrastructure engineer was carrying this kind context between planning rituals with various time horizons, ranging from weekly to quarterly to annually.

Occasionally I would drop down into execution mode myself to knock out something particularly gnarly, or set up some pins for someone else to knock down (e.g. promo season).

[suchire]

Because most questions are not bad questions. In isolation, if you have good teammates, ideas and questions are good. It’s just that you have to say “No” in the broader context, because you always have a limited budget of time and money

[pitched]

If the constraint is time and money, maybe that could be the answer instead of a hard no? Like, “the project you’re currently on is making X dollars per day and the new idea has to at least match that.” You might start getting more interesting proposals if you train your people to pitch them properly.

[mgaunard]

You just explained exactly what's wrong with big tech companies.

Application/product developers are seen as less capable and they put their best developers in infrastructure/platform/sdk/libraries.

This is all completely backwards. The application is what generates revenue and what needs the most attention to ensure the tech is a good fit. The needs of the application should be what drives the infrastructure to support it, but instead those companies have infrastructure people call the shots and heavily constrain how all applications should be built.

Thankfully there are sectors where application developers have full freedom on their tech stack in order to satisfy their business requirements and infrastructure is just people maintaining a collection of tooling and services that others can opt in to use or not.