3 ms·

> Write super boring code. Write naive but obvious code. “Premature optimization is the root of all evil”. If it was too simple, you can always make it more com

> Write super boring code. Write naive but obvious code. “Premature optimization is the root of all evil”. If it was too simple, you can always make it more complex later. And that moment might never arrive. Don’t write clever code until you simply have to. You will not ever regret writing code that was simple. Hang this in the Louvre.

globular-toast 2y ago
But be very careful not to mistake easy for simple. Too many people think that simple means easy when in fact easy often leads to the most complex code. I don't like that clever is thrown in here. Your software architecture should be clever. It should be clever in that it allows you to write simple code. Three simple functions in three different layers of an architecture is better than one function that couples various layers. See Rich Hickey for the difference between simple and easy: https://m.youtube.com/watch?v=SxdOUGdseq4 https://m.youtube.com/watch?v=SxdOUGdseq4
- suzzer99 2y ago
  Yeah for sure there's an art to it that only comes with experience. But you better be 100% sure you need those three layers. My first big project as a developer was on an over-designed reporting/query-builder application that had like 7 layers of of abstraction between the browser and the database - stuff like just in case we ever want to switch from Oracle to Sybase, unnecessary connection factories, Java controller classes for every type of html form field, etc (still have no idea why we needed a back-end CheckboxController). I ended up maintaining that thing and it was a great lesson in premature optimization. The bottom 3 or 4 layers remained a grey box that I did everything to avoid touching. Just changing the front-end query-builder flow from a series of forms to a flat panel that could do everything in one step involved ripping out half the back-end code. All those layers of abstraction and none of them considered a form-flow change, which is exactly why I never assume anything now. It's so much easier to add a layer than remove an unneeded one, which can be practically impossible on a complex app.
  - globular-toast 2y ago
    Nobody is ever 100% sure. The only thing you can really be sure about is the software will be required to change in ways you have not yet imagined. I've become wary of the "you won't need it" attitude. In my experience, tomorrow rarely arrives. If you don't put work into your architecture up front then you'll just end up building a ball of mud. It's even worse if you've got junior developers who very much code by example.

globular-toast 2y ago

But be very careful not to mistake easy for simple. Too many people think that simple means easy when in fact easy often leads to the most complex code. I don't like that clever is thrown in here. Your software architecture should be clever. It should be clever in that it allows you to write simple code. Three simple functions in three different layers of an architecture is better than one function that couples various layers. See Rich Hickey for the difference between simple and easy: https://m.youtube.com/watch?v=SxdOUGdseq4 https://m.youtube.com/watch?v=SxdOUGdseq4

suzzer99 2y ago
Yeah for sure there's an art to it that only comes with experience. But you better be 100% sure you need those three layers. My first big project as a developer was on an over-designed reporting/query-builder application that had like 7 layers of of abstraction between the browser and the database - stuff like just in case we ever want to switch from Oracle to Sybase, unnecessary connection factories, Java controller classes for every type of html form field, etc (still have no idea why we needed a back-end CheckboxController). I ended up maintaining that thing and it was a great lesson in premature optimization. The bottom 3 or 4 layers remained a grey box that I did everything to avoid touching. Just changing the front-end query-builder flow from a series of forms to a flat panel that could do everything in one step involved ripping out half the back-end code. All those layers of abstraction and none of them considered a form-flow change, which is exactly why I never assume anything now. It's so much easier to add a layer than remove an unneeded one, which can be practically impossible on a complex app.
- globular-toast 2y ago
  Nobody is ever 100% sure. The only thing you can really be sure about is the software will be required to change in ways you have not yet imagined. I've become wary of the "you won't need it" attitude. In my experience, tomorrow rarely arrives. If you don't put work into your architecture up front then you'll just end up building a ball of mud. It's even worse if you've got junior developers who very much code by example.