Of necessity, I've become a big believer in this idea. In fact, I've come to believe that one of the best things a senior developer can do is to introduce thoughtful abstractions in order to reduce that mental load. In doing so, we can help other developers focus on what needs to be done, not necessarily how.
I work in a unique environment - a University. We hire lots of part-time CS students (usually starting in 2nd year), so we have the most junior of junior developers. It is therefore really important for us to keep cross-cutting concerns, like deployment and authentication, out of their way, so that they can focus on implementing the business rules and use cases of an application. This allows us to be force multipliers, increasing the amount of useful work done by other developers, and thus by the organization as a whole. It also reduces our load, as we can trust that our abstractions are always the same, and focus on reviewing the parts of the juniors' code that is actually important.
As an example: We're in the process of finalizing and adopting a specification for RESTful APIs that our architects and those from other universities have been working on, called University API. It's a fairly complex spec, as it need to bring unity and consistency the many complex use cases we've discovered in our decade of doing APIs.
The first few APIs implemented to this specification have been done at a very low-level - lots of manually-written OpenAPI docs, manually-defining HTTP methods and paths, etc. This has lead to lots and lots of duplicated work and even more errors and inconsistencies with the spec.
So, me and a few others took it upon ourselves to abstract this work away from our developers, so that we could implement the rules of the specification once, and give people ways to hook into that to provide their specific logic.
So, instead of defining every little HTTP route, we operate at a very high level. Developers provide implementations of a 'Resource' API, which can have lots of operations and views. They don't worry about how to map all of those to HTTP, they just provide their resources to a 'UAPIRuntime' which assembles them all, figures out the relationships between them, maps them to HTTP, outputs an OpenAPI document, and take care of concerns such as error handling, logging, performance tracing, serializing responses, deserializing requests, authentication, enforcing developer-defined authorization rules, etc. Developers get to focus on the details of their application, and never have to worry about spec compliance - we take care of all of the hard parts of that for them. We are also going to provide lifecycle hooks so that, if we run into cases that our high-level API can't handle, our devs can dive in one level deeper and and make things work how they need to. It also allows to to conduct interesting experiments, like taking an existing HTTP API and re-using the same code to offer a GraphQL API alongside it, with only one line of code changed in the application.
It's still a work in progress, but other such tools have paid big dividends for us. We've really seen that a small group of dedicated, thoughtful people can have a big impact on how hard it is for others to do their jobs.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Of necessity, I've become a big believer in this idea. In fact, I've come to believe that one of the best things a senior developer can do is to introduce thoughtful abstractions in order to reduce that mental load. In doing so, we can help other developers focus on what needs to be done, not necessarily how.
I work in a unique environment - a University. We hire lots of part-time CS students (usually starting in 2nd year), so we have the most junior of junior developers. It is therefore really important for us to keep cross-cutting concerns, like deployment and authentication, out of their way, so that they can focus on implementing the business rules and use cases of an application. This allows us to be force multipliers, increasing the amount of useful work done by other developers, and thus by the organization as a whole. It also reduces our load, as we can trust that our abstractions are always the same, and focus on reviewing the parts of the juniors' code that is actually important.
As an example: We're in the process of finalizing and adopting a specification for RESTful APIs that our architects and those from other universities have been working on, called University API. It's a fairly complex spec, as it need to bring unity and consistency the many complex use cases we've discovered in our decade of doing APIs.
The first few APIs implemented to this specification have been done at a very low-level - lots of manually-written OpenAPI docs, manually-defining HTTP methods and paths, etc. This has lead to lots and lots of duplicated work and even more errors and inconsistencies with the spec.
So, me and a few others took it upon ourselves to abstract this work away from our developers, so that we could implement the rules of the specification once, and give people ways to hook into that to provide their specific logic.
So, instead of defining every little HTTP route, we operate at a very high level. Developers provide implementations of a 'Resource' API, which can have lots of operations and views. They don't worry about how to map all of those to HTTP, they just provide their resources to a 'UAPIRuntime' which assembles them all, figures out the relationships between them, maps them to HTTP, outputs an OpenAPI document, and take care of concerns such as error handling, logging, performance tracing, serializing responses, deserializing requests, authentication, enforcing developer-defined authorization rules, etc. Developers get to focus on the details of their application, and never have to worry about spec compliance - we take care of all of the hard parts of that for them. We are also going to provide lifecycle hooks so that, if we run into cases that our high-level API can't handle, our devs can dive in one level deeper and and make things work how they need to. It also allows to to conduct interesting experiments, like taking an existing HTTP API and re-using the same code to offer a GraphQL API alongside it, with only one line of code changed in the application.
It's still a work in progress, but other such tools have paid big dividends for us. We've really seen that a small group of dedicated, thoughtful people can have a big impact on how hard it is for others to do their jobs.