Hacker News new | past | comments | ask | show | jobs | submit login

1. Find bottleneck.

2. Remove bottleneck.

3. Repeat.

4. Every once in a while, make a bold move to throw something out that can no longer work that way and replace it with something more scalable. But while this is important, it comes up less often than you might think.

The difference is that you spend a lot more time in that loop than a desktop dev, but if you understand programming it isn't a special black art until the very, very top end.

The other thing to get is that it's always about buying time rather than solving the problem forever. The goal is to have bought enough time that you don't have to be stuck in a local optima or make panicked decisions.

This is a good point, to which I would add:

Architect your system so that you have visibility into where it is breaking, and that no piece has more than one simple job. Otherwise you will end up spending all your time trying to figure out where the bottlenecks are, and every bug will take a day or more to track down. Any part of your system that is complex will basically not be fixable, since nobody will know what the consequences of any change actually is until it breaks something else, which will then take another day to fix, and yes this logic does lead to an infinite chain of days fixing bugs caused the previous day.

Small pieces, loosely connected.

... and have at least one other os than prod and just fiddle with it, fiddle with compiler switches, optimisation random testing. occasionally look at the results and see what they mean. for example, freebsd's jails can help setup many different things. use llvm/clang and look at the warnings. these help me find potential problems. what's better than the clairvoyant code-improver/bug-fixer. :-)

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact