Hacker News Reader

Comment by cs0 | Hacker News Reader

I just replied above, but I've never been amazing at being able to figure out how I should be using for loops to solve problems quickly and efficiently.

I do tend to make things harder for myself, as my boss and fianceè have told me before.

I usually end up with a very convoluted solution which I end up coming back to and refactoring the next day.

View on HN

I was actually going to recommend exactly that - I find that, when I have a problem that I’m having trouble solving, just brute-forcing the damned thing helps me focus on the hard parts of the problem, and then I end up rewriting things in a “better” way that I’m actually not ashamed to put my name to.

Correct first, then simple and fast later. With more experience you'll be able to devise simpler, correct first solutions that you can then speed up later.

I'm curious, what sort of approaches do you take to your programming tasks at work? Is it more like e.g. writing SQL where you'd think more about relating sets of data rather than looping over individual items?

There's an old Kent Beck quote that fits here... "Make it work. Make it right. Make it fast." Your approach fits that.

http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast

I've seen so many projects where the developers have taken this to heart way too much. The problem is they use it as an excuse to give up after stage 2 thinking stage 3 can come along when it actually becomes a problem.

The thing is that performance issues tend to creep up on you so slowly that you don't realise it until you have a very important client with tons of data screaming at you to fix it now. To fix it then you have a huge architecture issue because the whole system is so inefficient. So rather than rewrite the entire code base to actually be efficient you are forced to hack in some kind of caching solution. Then your problems multiply.

Make it fast from the start. Premature optimisation being the root of all evil is a lie!

What is your hypothesis on where that lie comes from?

Ok, it's a bit of an exaggeration and obviously depends a lot on what your definition of premature is. I guess the statement is actually a tautology, by definition premature means too soon. I just see people who think that any optimisation at all is bad, whereas in a lot of instances optimisation as you are writing the initial code is not premature. In my experience...

If you do that you'll write great, fast code but it'll take you longer to do it. That's great if you have unlimited resources, but try doing it in a startup where failing to ship in a month means your whole business fails.

So... Maybe don't prematurely optimize?

I'm not sure you two actually disagree, but rather that you're thinking on different scales. Make it right, then make it fast is usually talking about specific snippets of code, rather than the whole program, so your whole program should be "made fast from the start" because you went through the process of making it right and then making it fast on the components themselves.

Yes, that's a great way of thinking about it!

Reply on news.ycombinator.com