4 ms·

> Optimization often involves making code less clear, more > brittle, or with a more pasta-like organization. > Frequently optimization requires writing cod

> Optimization often involves making code less clear, more > brittle, or with a more pasta-like organization. > Frequently optimization requires writing code that if > looked at out of context, doesn't make sense or might > even look wrong. I agree so much with this. It's better to write a sub-optimal implementation for a component which is clear & can be replaced with a more performant version later, when the bottlenecks have been identified + the interface is well-defined and -tested, and the team can accept the maintenance burden of non-obvious code. This does mean you can't skimp on good design, making your project a collection of modular, replaceable components.

HeyImAlex 11y ago
Further, very often we write code that isn't the code we need to write. I have wasted countless hours on needlessly efficient implementations of the wrong interface, or, on the other end of the spectrum, coming up with the perfect interface for code that will never be used again. Because I like puzzles and optimizing is fun and wiring up business processes is not very fun at all. But that doesn't mean it's a good way to write software. Accept that most of what devs do is fairly mundane, and focus your mental effort where it's actually needed and you'll be a better developer than anyone who obsesses over the performance/elegance/extensibility of every line they write. Obviously it's a spectrum, and it takes balance, but I know which side I'm currently on!
- falsedan 11y ago
  > I have wasted countless hours on needlessly efficient > implementations of the wrong interface, or, on the other > end of the spectrum, coming up with the perfect interface > for code that will never be used again. SAME HERE
carussell 11y ago
Examples on either side abound. I know I've certainly done enough optimizations that left the code clearer and shorter (despite often being more verbose with naming), while being more performant due to shedding whatever messy, tortured approach was in use before. Enough small gains like this have come out of code where I was the original author that it isn't a case of conceit. Clear and simple code can frequently beat clever code, regardless of which metric you choose to apply from the "performance or understandability" bag.
- falsedan 11y ago
  Simple code is hard tho

HeyImAlex 11y ago

Further, very often we write code that isn't the code we need to write. I have wasted countless hours on needlessly efficient implementations of the wrong interface, or, on the other end of the spectrum, coming up with the perfect interface for code that will never be used again. Because I like puzzles and optimizing is fun and wiring up business processes is not very fun at all. But that doesn't mean it's a good way to write software. Accept that most of what devs do is fairly mundane, and focus your mental effort where it's actually needed and you'll be a better developer than anyone who obsesses over the performance/elegance/extensibility of every line they write. Obviously it's a spectrum, and it takes balance, but I know which side I'm currently on!

falsedan 11y ago
> I have wasted countless hours on needlessly efficient > implementations of the wrong interface, or, on the other > end of the spectrum, coming up with the perfect interface > for code that will never be used again. SAME HERE

carussell 11y ago

Examples on either side abound. I know I've certainly done enough optimizations that left the code clearer and shorter (despite often being more verbose with naming), while being more performant due to shedding whatever messy, tortured approach was in use before. Enough small gains like this have come out of code where I was the original author that it isn't a case of conceit. Clear and simple code can frequently beat clever code, regardless of which metric you choose to apply from the "performance or understandability" bag.

falsedan 11y ago
Simple code is hard tho