I worked in a near-ideal development culture once.
Thank you very much for this description. I find it gratifying and inspiring.
Everyone was quick to assume that if other people thought their code was confusing, then it probably was...There's unspoken machismo, which put into words would sound like this: "Nasty opaque codebase? What's wrong, can't take the complexity, little man?"
Also, I find this to be key. There is room for raw talent and huge, inspiring amounts of clever -- but it needs to be focused exactly where it does the most good. Let's just assume that one's competitors are in the same league when it comes to intellectual horsepower. Then it behooves one to make sure one's resources are focused where they do the most good. Let the competition dissipate their intellectual powers in developer pissing matches while you quietly outperform them.
Of late, I've come around to a radical stance on this. Modulo DRY, one should almost always target one's code to the lowest common denominator programmer on the team -- the newbie. This should probably follow an 80/20 or 90/10 rule. If a bog-standard well informed and competent programmer can't come in and start fixing 80% of your code within an hour, and it's not due to lack of non-programming specialized domain knowledge, then you're doing it wrong. There's room for elegant abstractions and the odd clever hack -- but you only get to have at most 7 of these in any given subsystem, and the code involved should be the minority of your codebase.
Thank you very much for this description. I find it gratifying and inspiring.
Everyone was quick to assume that if other people thought their code was confusing, then it probably was...There's unspoken machismo, which put into words would sound like this: "Nasty opaque codebase? What's wrong, can't take the complexity, little man?"
Also, I find this to be key. There is room for raw talent and huge, inspiring amounts of clever -- but it needs to be focused exactly where it does the most good. Let's just assume that one's competitors are in the same league when it comes to intellectual horsepower. Then it behooves one to make sure one's resources are focused where they do the most good. Let the competition dissipate their intellectual powers in developer pissing matches while you quietly outperform them.
Of late, I've come around to a radical stance on this. Modulo DRY, one should almost always target one's code to the lowest common denominator programmer on the team -- the newbie. This should probably follow an 80/20 or 90/10 rule. If a bog-standard well informed and competent programmer can't come in and start fixing 80% of your code within an hour, and it's not due to lack of non-programming specialized domain knowledge, then you're doing it wrong. There's room for elegant abstractions and the odd clever hack -- but you only get to have at most 7 of these in any given subsystem, and the code involved should be the minority of your codebase.
Clever is a valuable resource. Use it wisely.