3 ms·

We all "know" that, but there are also some engineers that only give a very strong illusion of being more productive. Maybe engineer #1 is constantly pushing u

We all "know" that, but there are also some engineers that only give a very strong illusion of being more productive. Maybe engineer #1 is constantly pushing up code. In the time it takes them to merge 15 PRs, engineer #2 opens only 1 - but maybe they thought really deeply about the problem, and their approach actually saves the team hundreds or thousands of hours of future development work vs how engineer #1 would have solved the problem. Part of what makes this so hard to measure is the long tail effects of development decisions. (Incidentally, that's also a source of burnout for me - the constant mental overhead of worrying about the long term implications of what I'm doing, and particularly how they effect other people. It's very challenging.)

ebiester 2y ago
The problem is that the vast majority of code will not have long term implications so long as it reaches a minimum of design, performance, and does its job without bugs. Consistency of patterns is more important than the optimal pattern for most decisions. There are some core areas of the application that are much more important, but they are often the earliest data structures and built before the problem is known. You will not know how your code will change, so make it as consistent as possible with the rest of the system until you know more.