Hacker News new | ask | show | jobs
by edw519 4149 days ago
Stop worrying about how well your code performs and focus on more important things.

Seriously.

I'm not saying that code performance isn't important; of course it is. It's just that if you're already fairly competent, then code performance is probably not your biggest problem. You're looking for a magic bullet that may not be there.

I'd be more concerned with:

- How easily can another programmer maintain your code? We all tend to believe that our programs will be just right when we finish, but the sad truth is that others will probably change them significantly over the years. Your wish to "squeeze a little more performance" out of your code may actually be counterproductive; no one will understand your clever optimizations and your code will become maintainable. Remember, you're writing for the next programmer as much as for the machine.

- How well are your databases designed? Do this well and you won't have to worry about optimizing your code as much. Take care of the microseconds so that you won't have to worry about the nanoseconds.

- How well are your variables named? Again, this doesn't affect performance, but boy does it ever help maintenance.

- DRY (Don't repeat yourself.) For many reasons, including performance.

- How precise is your definition of "what" to build? Building the wrong thing to run very fast is much less important than building the right thing to run fairly fast.

- Are you doing the right things on the client and the right things on the server? For example, if you're validating data on the client and building the UI on the server (under some conditions), then it really doesn't matter how fast it runs. You're probably doing it wrong.

- Are you especially careful about recursions, early exits, sorting, filtering, parsing, and other fairly standard stuff? Do these things right so you won't have to worry about performance. Do them wrong and all the fine tuning in the world won't help.

- When all else fails, find a peer reviewer whose opinion your respect. They'll probably find the stupid things your blind eye misses. You'll remember their feedback and probably never make that mistake again.

Have fun doing the important things well and stop worrying about fine tuning: a philosophy that has worked very well for me for years. Hope this thinking helps you too.

3 comments

Ed is right in that all these things matter as much or more than making performant code but at the same time your question suggests that performance is your main issue at the moment. If that's not the case then please take Ed's advice to heart and invest your time in all of the above, only concentrate on performance if you are 100% convinced that is what will give you the best return on time invested.
> Stop worrying about how well your code performs and focus on more important things.

It's very naive to think that that's an acceptable tradeoff in every situation. Would you accept it if chrome/FF/<browser of choice> suddenly consumed an extra 30% of memory and CPU time after a single update, because the developers decided that the HTML rendering code wasn't readable enough? Or if you're writing code for cars that needs a response time in sub millisecond ranges to delay for hundreds of milliseconds before engaging traction control because the code wasn't well labelled, so it was rewritten?

There are plenty of cases where performance is absolutely critical, and it is the most important thing.

yep there are also a lot of situations in enterprise where you don't exactly know how your code will be used in near future (in <5 years it could grow to exponentially more customers using it compared to soft releases to select test customers).

Because of that I'd say.... it's not like I see a lot of people get raked over the coals for it, but there is definitely some organizational disappointment when a silly scaling bug crops up in production[1]. I think as a mature dev it is proper to internalize as many performance-related techniques as possible so that you can write more performant code with each subsequent project. Sometimes it doesn't even affect the amount of initial coding hours, it is just one of the freebie gains that comes with experience.

[1] Many more such bugs would probably occur if the company didn't occasionally get around to load-testing, so that should be part of CI or dev cycle if possible.

I like this list much better than much of this thread. A lot of programming doesn't NEED to be that efficient, and it's much better to learn the "soft" stuff and how to properly maintain projects