As a first principle, you have to acknowledge that your time and energy are limited resources. Active collaboration (e.g. architecture reviews, code reviews, pairing) is strictly dependent on your time and energy. At a certain team size and development velocity, your capacity for active collaboration will be exhausted by total development output. The exact numbers will vary by organization, but I’d expect this effect to become visible at 5 engineers and well-established at 10. At this point, your value to the company reaches an inevitable threshold, bounded by an input constraint (your labor).
As they approach this threshold, talented engineers will often optimize their active collaboration. They'll move around the company and serve as core contributors on high-priority feature projects. This can be a viable approach to engineering career growth when a company's user and revenue growth is extremely rapid but at best can only establish a somewhat higher threshold. The labor constraint remains.
To break through, you need to pursue contributions that have value proportional to total development output rather than your labor. As software engineers, we are fortunate to have this essentially built into the medium. Computer hardware is infinitely complex but computer software can manipulate it in simple terms thanks to countless layers of abstraction. The productivity gains offered by an effective abstraction will be directly proportional to the number of users (i.e., developers).
So, in order to multiply your value beyond your personal labor capacity, you need to create abstractions that improve development output or product performance. Abstractions range from thin (documentation) to thick (network services) and must be calibrated to the company's need. Poor abstractions can very possibly impose greater costs than benefits. Effective ones, however, represent an asset to the company. This asset delivers value throughout its lifetime, independent of the author's tenure with the company.
The most valuable (and most senior) engineers in a company are those who can identify core engineering problems and institute appropriate abstractions. In highly effective teams, abstraction and automation are engineering techniques embraced by all and not a job title held by one (e.g., Software Architect).
The most valuable abstraction skills for me have been:
- Organization: The ability to separate code into logical modules/services and express a clear understanding of implications for testing, access control, composability/decomposition, etc.
- Decision Selection: The ability to focus on the most difficult decisions to change/undo and avoid bikeshedding implementation details.
Both skills contribute to the development of good interfaces (APIs), which serve as the connecting tissue of an increasingly growing (and valuable) software system.
Open source has definitely played a significant role in helping me refine those skills. Within a single startup, it's easy to become comfortable in a homogenous/static software stack, leading to tunnel vision and reduced motivation to improve. In small teams, changes can be carefully coordinated. In open source, the software stands on its own and contact between the author and users is limited. Changes cannot be coordinated and multiple versions will always be in use. Breaking changes are possible but often avoided/batched.
I am frequently presented with requests (issues, pull requests) to extend a module's API with either new attributes or behavior and need to consider whether the proposal fits within the module's expressed purpose or should be implemented by the caller. Often the requester is motivated by immediate personal convenience, while I need to consider the fitness for other users and potential maintainability risks. Open source maintainers have full autonomy over their work and can make that decision entirely on the technical merits of the proposal.
In a corporate environment, where politics can inject emotions into decision making, I've found the OSS model reduces contention. Decisions are not "yes" or "no" and instead become "this is handled for me" or "I'd need to implement this myself." This helps ensure a focus on quality abstractions over quantity and provides balance between software quality and short-term productivity.
Open source experience shaped these values for me but is not required. Every engineer has opportunities to simplify code and/or reduce toil in the codebases they work on. The best way to improve technically is to build a regular practice of making every repetitive task you encounter easier and more accessible to everyone else, whether that's the world (OSS) or your coworkers.