> If you write software for a living (or for fun) ask yourself this: When was the last time you calculated the Big O on something you wrote?
Two or three times this week. While writing software you should always be asking questions like this to yourself. To mirror an analogy in the post, "Imagine a composer who didn't know the difference between an 8th note and a 16th note. Could they create some music? Maybe. Could they be great? Probably not."
To which I'd add that the reason why Big-O notation is significant is that software is subject to physical constraints. There are physical limits on how fast you can write bits to memory or fetch data from a network. An exponential-time algorithm may look like a beautiful work of art on the screen, but you'll never scale it up. An artist, on the other hand, can paint anything on their canvas that they want, and it doesn't have to conform to physical reality - it's as easy to paint a flying purple unicorn as it is to paint a horse.
A software developer who doesn't understand the fundamental limitations of their hardware and software is like an engineer building a bridge who doesn't know the equations for computing the amount of steel needed to hold the bridge up. Sure, they can build a bridge that looks nice, but you wouldn't want to drive your car over it. This developer may be able to write beautiful code, but if their server takes five seconds to respond, nobody will use their creation (or they'll have to pay for ten times the server hardware to get the same job done), and the game is over.
Software development does have elements of art in it, but it's primarily engineering. The art in software is like the art in designing a nice-looking car, whose primary purpose is to safely get from one place to the other, and whose looks shouldn't get in the way of its handling or fuel efficiency.
Calculating Big-O 2-3 times a week on code you wrote? There's a reasonably high probability that you're following a premature optimization anti-pattern.
No, I am not even tho ugh I disagree that it's an anti-pattern. I write a lot of small programs that are meant to deal with large amounts of data, but data that is different enough to require a separate 100 line program. The difference of thinking about these things is the difference between 20 minutes and 2 minutes for the program's run-time.
4 comments
[ 3.1 ms ] story [ 17.0 ms ] threadTwo or three times this week. While writing software you should always be asking questions like this to yourself. To mirror an analogy in the post, "Imagine a composer who didn't know the difference between an 8th note and a 16th note. Could they create some music? Maybe. Could they be great? Probably not."
A software developer who doesn't understand the fundamental limitations of their hardware and software is like an engineer building a bridge who doesn't know the equations for computing the amount of steel needed to hold the bridge up. Sure, they can build a bridge that looks nice, but you wouldn't want to drive your car over it. This developer may be able to write beautiful code, but if their server takes five seconds to respond, nobody will use their creation (or they'll have to pay for ten times the server hardware to get the same job done), and the game is over.
Software development does have elements of art in it, but it's primarily engineering. The art in software is like the art in designing a nice-looking car, whose primary purpose is to safely get from one place to the other, and whose looks shouldn't get in the way of its handling or fuel efficiency.