To be a good X you must follow the rules. To be a great X you
must have followed the rules so well as to learn why they’re there and when they should be broken.
Works for almost any X - writer, programmer, driving, etc.
Works for almost any X - writer, programmer, driving, etc.
In my experience slavishly following the "rules" or "best practices" can actually be worse than never following them. Not understanding when it's good to deviate usually means of a lack of understanding of why the "rules" or "best practices" exist in the first place. So much attention is spent following the letter of the rule rather than what problems it was meant to solve.
Look no further than modern day "Agile" vs the actual Agile Manifesto
KISS and DRY are different paradigms, i.e. come from different schools of programming.
Most people would not recognize simple code if it hit them I'm the mouth.
KIES (keep it easy, stupid) is what they mean, and that means following idioms, frameworks, that are familiar.
My more nuanced take I guess is "don't duplicate logic, except if it may in fact be mutable data". It does take some forward thinking to think that this e.g. list of 10 rules should be unrolled and not compressed by meaningless helpers, etc
DRY is about knowledge management. The intention is to not avoid duplication of code which is a knowledge representation of the same thing. It does not mean every coincidentally similar looking code must be made into a function, as it would result in a premature abstraction, etcetera etcetera. It's why "minimum three duplication" principle is effective, because it filters which duplication represents the same knowledge and which does not.
KISS is (ironically) a more complex topic. C2 wiki talks about this in an interesting way. https://wiki.c2.com/?KeepItSimple
He does well to explain how PEP 8 can be good but some people focus on it because they may not have experience to contribute otherwise.
Another example is that I recently wrote a comment that received greater than 10 votes and was flagged (I presume by users) almost immediately. The comment was thus both commonly agreeable (perhaps people could empathize to the subject matter) and yet a violation of social norms. An unspoken social rule violation.
That comment also received contradictory responses: I’m not woke, but.... Contradictory responses are generally an explicit mention of internal confusion where the person cannot even agree with themselves on social conformance: I’m not lying, but.... If it’s not complete bullshit then don’t posture with a qualifier.
"Some consider it noble to have a method; others consider it noble not to have a method. Not to have a method is bad; to stop entirely at method is worse still. One should at first observe rules severely, then change them in an intelligent way. The aim of possessing method is to seem finally as if one had no method."
“Learn the rules like a pro, so you can break them like an artist.” - Pablo Picasso
In my opinion, once you play a game for a while, it's easy to know exactly when and how to break ANY rule: you must understand what the rules are there for.
Think of any agile framework, a ton of them are practiced like cults by the most. However, if you think that those are there for 2 simple purposes:
1. you want to ensure nobody in the team is ever idle
2. you want to ensure everyone is working on the most relevant available task that hasn't been picked up from others
This is just an easy example, this is really about anything in life though!
I think mine are closer to the agile manifesto, but perhaps yours are closer to how agile is actually practiced in most places.
Problem 1: you want to ensure that you build the right thing.
Solution 1: you should get feedback from end users as frequently as possible.
Problem 2: you want to be using work processes that are appropriate for your team and task.
Solution 2: teams should be able to modify their own work processes.
And by rules, I don't mean offside, handball, freekick rules. I mean how to hold the line, when to dribble, when to shoot, to hold formation, play as a team, end product etc.