|
|
|
|
|
by kevinmannix
2074 days ago
|
|
Your second point broadly makes sense. In fact, it's almost a truism: if you don't put time into learning, you won't have the skills necessary to be able to execute. However, it seems detached from your first point. If one's role is a front-end developer, is it necessary that they know about back-end development? If it is outside their intended job function, why would they need to know about it, if it doesn't get in the way of performing their job? If you are a backend developer, do you need to know about how to host your own infrastructure? Handle your own networking? Chip design? Your logic could be applied to any job function. Each level of the stack benefits from the levels below it being abstracted. We all stand on the shoulders of giants, and we're all much better for it. Overall, I do think it's better that one has a good understanding about the various components one interacts with. Having a grasp of the overall system will come in handy. A curiosity into other parts of the system is beneficial, and likely is one of many indicators of success. However, if job functions can be simplified and superfluous context removed, why should we fault those for taking advantage of that? This issue with "lowering the bar" and being glad that a simplification has "failed" (which, is yet to be determined), reeks to me like gatekeeping. The same logic could be applied to any job role which benefits from simplification. In an extreme example, this logic could be extrapolated to support the notion that anyone who cannot build their own machine from the ground up should never work in a programming position. What height is appropriate for the "bar"? |
|