frizzle112

I think it depends on the complexity of what you're building. If it's something very novel or something that requires a lot of domain or technical expertise, then you might need a principal engineer to be the point person to figure out how to even build it, or build it right. Some problems are best solved by a single person with the right skills.

Some career ladders allow for this, others are more rigid about the size of team you need to be directly leading .

Author describes a classic tragedy of the commons situation - many reap the benefits but there's little incentive to invest in OSS.

Analysis from there is weak. The incentives I think fairly clearly lead to major underinvestment in open source relative to the ideal level because of the incentive problems Even if there is some investment and some significant success if there was investment of time and money order proportional to usage of major OSS components.

Basing the argument on single company stock reliably going up is a big mistake, but I do think the longer-dated stock awards are advantageous to many employees because they're effectively an employee option - every month/quarter/year you have the option to quit for a market rate job elsewhere or accept whatever the stock is worth.

Also if a stock dips many employers in competitive markets will end up compensating somehow. It's difficult to model because it depends on how employers behave and how much they want to retain you. If they reliably give you extra grants/bonus to get people back to target compensation after a decrease in stock price, then the downside risk of longer-dated grants is reduced a lot, but you still have significant upside.

Reality is that people don't want to job hop always, not everyone can easily find a market rate job, employers don't 100% true people up after a stock dips and and employer might not be invested in retaining even a good employee. So YMMV.

I think it all comes down to judgement and there are definitely ways people can write code in their individual style without hurting maintainability.

That said, maintaining a codebase where there is a lot of variation in idioms, style and formatting can be a big headache.

It adds cognitive overhead and if you're changing files you constantly have to balance preserving the local style with other factors. E.g. if someone likes aligning their equal signs, and you add a new line where the LHS is one character longer, do you reformat the whole block?