3 ms·

I find these arguments going back in circles and concluding nothing. All teams are different, and a good rule of thumb is to write code the least skilled or ex

I find these arguments going back in circles and concluding nothing. All teams are different, and a good rule of thumb is to write code the least skilled or experienced person can understand on its own without guidance. Since teams vary so do these limits change. I had teams where it would've been odd to even try use any abstraction, let alone algebraic data types, and teams practicing lots of abstraction and architectural patterns all on top of functional effects. The teams widely different in proficiency of the best and weakest members and so did the codebase patterns. It's like in sports, different teams demand different approaches because the qualities and proficiencies differ, there are no universal truths but solutions that fit better different teams.

m000 3y ago
> All teams are different, and a good rule of thumb is to write code the least skilled or experienced person can understand on its own without guidance. This. Also, if your team develops on framework X and people are hired based on that, stick to the damn patterns used by your framework! I had once worked with a developer that one day unilateraly decided that the abstractions provided by the framework we used were not good enough. Instead, we should use the abstractions from a "design pattern" described in a shitty blog post they dug up, and "everyone should read". There wasn't enough pushback, so we had ended up with some seriously unmaintainable code.
pmontra 3y ago
I write code that I can understand when I'll come back to it after one year or two. Sometimes I don't understand what my old code does and I realize that I failed. It wasn't simple enough.