[hi-v-rocknroll]

> if you can’t read the code you Shldnt be working on it

An ultimate expression of insider elitism and knowledge hoarding, which can be a self-interested asset to profitable, closed-source, specialized software.

For everyone else, code should present no surprises whenever possible with semantic expressiveness and reserve comments for explanation of surprises, design choices, and protocols.

[xelxebar]

I don't know about you, but if you don't know the basics about woodworking and have no interest in learning, I certainly don't want you building my furniture. That, um, has nothing to do with elitism.

There is a real tradeoff between making code friendly to the uninitiated and making code ergonomic for the expert. It's completely natural that non-initiates feel unwelcome when the code is written for domain experts. In your company's codebase, is it really best to optimize for onboarding newcomers over optimizing for the productivity of your engineers? Where along that spectrum maximizes your goals?

Are we building chairs or are we building chair-builders?