10x Engineers: The Purple Developer
While it&#x27;s obviously easier to change something you built yourself I wouldn&#x27;t attribute this  factor to productive-in-this-codebase alone. I&#x27;ve seen tons of cases where taking in a senior developer to the team in just weeks outrun the juniors who&#x27;s been in the code base for years. You can pair program to keep everybody on same level but let go of that and guess what, same developers as before will take the lead again.<p>Pairing, documenting the system, keeping everybody up to date and involved in decisions is obviously still important but i really don&#x27;t buy the claim that this is what constitutes these differences alone.<p>There are these gurus who know how know how to hook up all kinds of debuggers, cross-compilers, IDE, profilers, fuzzers and packet sniffers which can jump into any other teams unknown module and in just a day or two kill of bugs they have been struggling with for weeks. I&#x27;ve seen this happen over and over again. These guys know how to systematically break down a problem, find the external dependencies, google-fu how to set up a dev-environment, create a minimum isolated test case for it, and get to the bottom of the problem, regardless if it&#x27;s Java, Python, Node, C++, their own codebase or someone elses. In bigger systems they know how to build a mental model of all the microservice relations and database tables.<p>On the other extreme end of the spectrum you have the trial-and-error developer who will happily add a dependency to your database inside the otherwise stateless math-module. This difference has absolutely nothing to do with productive-in-this-codebase.<p>You could also stretch the original definition to say productive-in-X also includes any past experience with surrounding external dependencies. Such as linux, the programming language, its libraries and ecosystem. Those years of experience can&#x27;t easily be shared with others, as the article explains.