type Thing = {
name: string,
};
function getThing(): Thing {
return JSON.parse('{"error": "invalid id"}')
}
const thing: Thing = getThing(); // lie to me!
console.log(thing.name);
This is a trivial example to illustrate the idea that it's relatively easy to make a type that cascades through a very large app but which is backed by a complete lie.
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.