Knowledge of algorithms has very little to do with programming skill. As some random dude* on the internet once said: "When in doubt, use brute force." Let's unpack what this means.
A good programmer knows how to implement a dictionary algorithm in Python. A great programmer knows that someone smarter than she is has already implemented a dictionary as part of the python language, and trusts that it will work well enough for most purposes.
A good programmer tries to pick the best algorithm in terms of performance. A great programmer picks the simplest non-stupid algorithm and only considers changing it later if performance is an issue (it almost never is), if changing the algorithm will significantly improve overall performance (it almost never does), and if the performance improvement justifies the cost of making the change (how many dollars is a 5% overall improvement worth?).
Good programmers have a deep understanding of big-O notation. Great programmers know that in the real world, battles are won and lost in the coefficients. (This is particularly true in kernel and compiler coding.)
Good programmers know that they'll spend 98 days/year debugging and 2 days/year doing performance optimization. Great programmers tilt that ratio towards optimization by choosing simpler algorithms that are easier to understand and easier to debug.
To give an analogy: you don't really need to understand assembly language to be a great programmer, unless you happen to be writing operating system or compiler code. Likewise, you don't really need a deep understanding of algorithms unless you're writing mathematical libraries, in which case, you do.
A good programmer knows how to implement a dictionary algorithm in Python. A great programmer knows that someone smarter than she is has already implemented a dictionary as part of the python language, and trusts that it will work well enough for most purposes.
A good programmer tries to pick the best algorithm in terms of performance. A great programmer picks the simplest non-stupid algorithm and only considers changing it later if performance is an issue (it almost never is), if changing the algorithm will significantly improve overall performance (it almost never does), and if the performance improvement justifies the cost of making the change (how many dollars is a 5% overall improvement worth?).
Good programmers have a deep understanding of big-O notation. Great programmers know that in the real world, battles are won and lost in the coefficients. (This is particularly true in kernel and compiler coding.)
Good programmers know that they'll spend 98 days/year debugging and 2 days/year doing performance optimization. Great programmers tilt that ratio towards optimization by choosing simpler algorithms that are easier to understand and easier to debug.
To give an analogy: you don't really need to understand assembly language to be a great programmer, unless you happen to be writing operating system or compiler code. Likewise, you don't really need a deep understanding of algorithms unless you're writing mathematical libraries, in which case, you do.
362
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
