Regarding Simplicity
Always implement the simplest possible solution that fits your understanding of the problem space modulated by your anticipation of the inputs you’ll be dealing with.
This may sound like a re-statement of the K.I.S.S. principle but it’s not — it’s more robust than Keep It Simple, Stupid and is self justifying in the following way: The added complexity of parsing this rule is worth the sacrifice in communicability in order to more accurately express the argument behind it.
The “KISS Principle” is often rejected by those who know better. Their experience in a field has taught them that the simplest possible solution is likely unsuited to any amount of serious usage in the real world. They then abandon this principal and resort to implementing along lines that too often show signs of Second System Syndrome. The resulting code being heavily influenced by what they’ve done before only, this time, improved upon by the lessons they’ve learnt the first time they wrote something similar.
These people are smart and are learning from the mistakes they’ve made in the past. Anyone worth their salt should be at this self correcting level. But there is, as always, another level beyond that.
I call this next level the “Fuck It” level, though that may be too technical a term for some.
Achieving the Fuck It level entails knowing the problem space well enough and understanding the limits of your inputs well enough that you can gauge how complex an implementation will be required to match the requirements you’ve been given. Many nerds come to believe that their task is to come to the most optimal solution given the input and the hardware. That’s cool, they’re nerds, they do that. The actual task is to come to the best solution that suits the requirements in the shortest amount of time. That’s what your manager wants and that’s what the company wants. Where you shine, as a fancy pants and experienced engineer, is in doing exactly that while leaving yourself wiggle room to get more performance and more features out of what you’ve written once they come back to you for more. The trick is never in building the best possible implementation — the trick is in building the implementation that will provide the best possible future. The best possible implementation changes from year to year according to hardware trends or the software you’ve build upon. The implementation that will provide you with the best possible future changes far less frequently. When you understand the problem space well enough you’ll be able to define the implementation accordingly. When you do, implement the simplest possible solution you can and leverage the abstractions you’ve built from your experience to give you as much wiggle room to change things the next time out.
Details change quickly, patterns change slowly, your code base is glacial. Make it broad and adaptive and don’t overly tax yourself fitting into the cracks.