Always Do Extra
Oh, God.  This sums up one of my coworkers.  Smart, productive, generates lots of LOC that almost always do the right thing, but oh my God, the "Extra."  Dig into any of his code and you'll always find something Extra, like the front end is built in SomeObscureLanguage.js, or the business logic is expressed in a custom DSL implemented by macros, or some piece of the app seems to be mysteriously absent, until you discover it's injected via a custom plugin for the build tool.<p>Everything he does can be theoretically justified by DRY or some other principle of software engineering (it's almost always DRY, and when it isn't, it's type safety) but the payoff for the extra complexity is always an order of magnitude away.  Like, the custom build plugin would make sense if we had a bunch of apps that were structured the same way, but we only have one.  The custom DSL for the business rules would make sense if there were a hundred rules, but there are only a dozen or so.  Using SomeObscureLanguage.js might theoretically (for the sake of argument) give us an edge that would be worth it if this were one of our reputation-critical consumer UIs supported by dedicated team, but it's an internal tool, and the bugs never get fixed because there's only one person who knows SomeObscureLanguage.js, and he's always doing something more Important.<p>I don't disagree with the article.  Extra will distinguish you more than More, and if done right, it can speed up your team.  Just be sure that all the Extra you do makes your teammates Extra productive, and that you aren't adding Extra burdens that slow everybody down and make software development Extra responsible for the slow pace of launching products for new markets.