3 ms·
Well, yes, I mean, how can we really have this conversation and throw numbers around without defining even what countries and industries we are talking about?
by inimino 3y ago
Well, yes, I mean, how can we really have this conversation and throw numbers around without defining even what countries and industries we are talking about?
But, maybe it's true that most code covers edge cases; then in my opinion, staff developers should be building tools for the rest of the company to use, and if they are powerful enough, you might be better off by having fewer people employed as programmers and more people writing programs. Obviously a lot has to go right for this sort of thing to happen.
- ZephyrBlu 3y agoLike I said, I think most companies don't fit your model so feel free to throw out some industries. I think service/API companies like Netflix are the most suited to your approach, but even with Netflix leaning into that style of company hard they still have thousands of engineers. There is most definitely some amount of irreducible work for a problem/domain/other. > Obviously a lot has to go right for this sort of thing to happen It feels like a very naive approach. When I'm building stuff, the edge cases often require a lot of digging into the surrounding context and working with other teams. I don't think you can solve this by abstracting it away, because it's still working at the same level of abstraction just in a different part of the codebase. There is also the fact that every abstraction is leaky...
- inimino 3y agoWe should be building tools that empower people to solve their own problems, whether that's no-code or low-code tools, or platforms, or scripting languages. We underinvest in internal tool-building for all sorts of non-technical reasons, and the result is people interacting all day at work with terrible software.