07 Aug, 2010, Chris Bailey wrote in the 21st comment:
Votes: 0
I agree with Runter here. I'm finally seeing the light about premature optimization, and it's really just a waste of time that prevents us from getting things off the ground. Just get it all working, refactoring is for later.
07 Aug, 2010, KaVir wrote in the 22nd comment:
Chris Bailey said:
Just get it all working, refactoring is for later.
Don't do today what you can put off until tomorrow?
I think it's worth remembering Donald Knuth's full quote: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil".
Personally I find it's better to keep performance goals in mind from the start. That certainly doesn't mean always putting them first - but it's not fun refactoring huge chunks of code. In fact it can greatly increase the amount of effort. So if you know from the start that your solution will eventually need to be optimised, I would suggest doing it sooner rather than later.
07 Aug, 2010, Chris Bailey wrote in the 23rd comment:
KaVir - Correct as always! :P
I was speaking specifically of situations such as this one but you have explained it in a much better way. =)
I was speaking specifically of situations such as this one but you have explained it in a much better way. =)
08 Aug, 2010, Runter wrote in the 24th comment:
Most people poorly set their goals based on misconceptions of what is and isn't clutch.
As programmers become more experienced they often realize getting things done is most clutch.
The best way to go about it is having a gameplan on your overall program design rooted in experience. Then later identifying bottle necks. The road to obtaining that experience is usually ugly and getting your feet wet is the best way.
However, I think its impossible to identify bottlenecks precognitively as a new programmer. Refactoring and optimizing every bit of code is a poor idea but its what a lot of people do.
Sorry for the tldr'r but one last point. I'd rather spend time refactoring for readibilty and maintainability. Programmer efficiency has became my main time sink.
As programmers become more experienced they often realize getting things done is most clutch.
The best way to go about it is having a gameplan on your overall program design rooted in experience. Then later identifying bottle necks. The road to obtaining that experience is usually ugly and getting your feet wet is the best way.
However, I think its impossible to identify bottlenecks precognitively as a new programmer. Refactoring and optimizing every bit of code is a poor idea but its what a lot of people do.
Sorry for the tldr'r but one last point. I'd rather spend time refactoring for readibilty and maintainability. Programmer efficiency has became my main time sink.
08 Aug, 2010, David Haley wrote in the 25th comment:
It's also not always easy to *know* what the bottlenecks will be, even if you have experience (although it certainly helps). Besides, there is great value in prototyping quickly, sometimes, *even when* you fully know you will eventually have to toss it all. It can inform you that an idea is not worth pursuing regardless.
Random Picks
