Microservices limit the productivity of high performing coders
Critical expertise shifts to systems design
A software product or service designed as a collection of microservices divided amongst many engineering teams limits the impact of high performing programmers (what some people refer to as 10x engineers or code ninjas). Why is this? Consider this scenario.
Microservices Scenario: You are tasked with implementing a new feature for a service consisting of 20 microservices divided amongst 5 software engineering teams (Teams A, B, C, D, E). Of the 20 microservices, you find that 8 of them need development work in order to complete the feature. However, the 8 services belong to 3 of the teams. Team A owns 4. Team B owns 2, Team C has 2. You are on Team A. How do you proceed?
A 10x engineer/code ninja might proceed by quickly completing all of the work in the 4 microservices that their team (Team A) owns and then just wait for the other teams to complete their work. This is a valid path forward for a junior engineer sometimes. However, it often isn’t feasible. What if Team A’s code changes cannot be completed without dependencies from Team B or Team C first? If that is the case, then you cannot complete the work any quicker than it takes Team B and Team C to complete theirs (even if you are a 1000x engineer).
A better way to proceed would be to put together a design document detailing the changes required by each team and micro to complete the feature. Present the design to your leadership and the other teams to make sure you have buy-in. Answer any questions and fill in design gaps that the other teams point out (they know their services better than you do after all).
Now contrast the above scenario with this one.
Monolith Scenario: You are tasked with implementing a new feature for a service consisting primarily of a monolith and a few supporting micros for things like auth and notifications. You have access to all of the code for the monolith and the few micros. How do you proceed?
In this scenario, a 10x engineer/code ninja quickly implementing the feature is almost certainly the proper course of action. A design document is likely not needed.
At this point, you might be thinking I’m advocating monoliths over microservices. I’m not. A strong case can be made for either and is dependent on context. Realistically, a strong programmer will likely be more productive in a microservices system when they are implementing features that only require code changes to microservices that their team owns because microservices consist of inherently less complex code bases than an equivalent monolith. The key is the team separation that hinders the impact of strong coders.
For services and products that are distributed amongst microservices across many teams, the key area of expertise needed shifts from the code base to the design of the system and how the various pieces interact. In other words, the design you put together on the whiteboard and diagrams and then formalize in the separation of teams and microservices becomes more important to the productivity of the organization than any single engineer’s strong coding ability.
So, being a 10x engineer for a microservice product is less dependent on your coding ability and more dependent on your ability to harmonize the various microservices and the teams that own them.