"And don't write longer, more obtuse code because you think it's faster. Remember, hardware gets faster. MUCH faster, every year. But code has to be maintained by programmers, and there's a shortage of good programmers out there. So, if I write a program that's incredibly maintainable and extensible and it's a bit too slow, next year I'm going have a huge hit on my hands. And the year after that, and the year after that.Great quote! Read more on this topic here.
If you write code with more code that's fast now, you're going to have a hit on your hands. And next year, you're going to have a giant mess to maintain, and it's going to slow you down adding features and fixing bugs, and someone's going to come along and eat your lunch." -- Wil Shipley
MT
3 comments:
One should never write obtuse code. There simply is no good reason. It doesn't help anyone.
However, I don't think there is this tradeoff between speed and understandability. Obtuse code is actually harder to optimize.
Too many programmers ignore performance and as a result we have software that gets slower at a pace exceeding the performance increases of hardware according to Moore's Law. Poor software with N-squared algorithms where there could be log-N algorithms trumps Moore's law every time.
You can't ignore performance however or you'll end up with software like Windows where my boot times have increased over the last 20 years.
Fortunately, well designed software is often much faster as well as being less obtuse. It is also much easier to optimize the bottlenecks of understandable and modularized software.
In short, I find that this is almost always a false tradeoff. I've generally found that you can write fast and easy-to-understand code if you think hard enough and understand the performance implications of your decisions. Too many new programmers are taught to ignore performance and as a result we have slow crap much of the time.
- Curtis
Curtis, thanks for the comments. I definitely agree with you. In most of the cases, good coding will take care of performance and understandability. Cause they share the same root cause...efficiency.
Easier to understand 2 + 2 = 4; than sqrt((2 * 4) * 2) = 4. More efficient too.
What I actually like about Shipley's quotation is its hint at designing your code/system for the future instead of the past/current. It's true 2 + 2 = 4 is understandable and efficient. But, those variables may not always be the same in the future. May not always be the same formula. Heck, may not even exist anymore. Designing your code around those possible outcomes in the future...is better [in my opinion] than coding for an outcome that exists now.
Relates very well to backtesting trading systems. If you optimize or develop your system for capturing the past...you're system will most likely make a whiff on the future.
MT
Jesse,
Hey there! Tips on entering the field of programming? Hmmm...
If I had to do it all over again I would probably have gone a very different route. So, I'm probably not the best person to give tips on this field.
But, here's the biggest thing I've learned:
You don't need a job/career/training to begin programming. Just need a project. Pick something...anything...and just dive in. Read books, blogs, magazines on the subject. You'll be amazed at how much is possible this way.
And don't think you have to know it all to begin. Baby steps. Just focus on understanding a piece here and there...pretty soon you'll know a lot.
Tips on getting a job as a programmer? That's hard to answer. Degree in Computer Science is the easiest route. Going that way gives you the opportunity to network with professors, classmates, and possibly intern at companies that hire programmers.
Hope this helps and is focused on what you were asking.
Tell you what...you should email Joel and ask him this question. His site [http://www.joelonsoftware.com/] is a great resource on programming.
Good luck!
MT
Post a Comment