Clear questions and runnable code
get the best and fastest answer
Maxims for Programmersby perrin (Chancellor)
|on May 18, 2002 at 17:58 UTC||Need Help??|
Over the years, I've discovered a number of truths about programming and the way programmers interact with others in their jobs. These have evolved into a sort of mini-philosophy, and I thought I would share a few of the more interesting ones here. Here they are, in no particular order:
Good programmers don't require much project management. No amount of project management will make bad programmers good.
You will never get exact and complete requirements, and even if you did, they would change by the time the project was complete. Your only hope is to plan for changes and talk to your users.
Commercial application frameworks (e.g. application servers) never do quite what you need them to do, and you can't change them to meet your needs because you don't have the source.
No amount of documentation is a good enough substitute for the source code.
Management assumes that the programmers at the company trying to sell you an application framework must be better than the ones at your company.
SQL is very high-level and easy to write. Be very wary of people who try to save you from "hand-coded" SQL by giving you some huge proprietary API to use.
New technologies rarely are. The problem you're working on now has been solved at least a thousand times before, and probably at least a decade ago.
There are very few problems that are best solved by a distributed object system.
One good programmer is more useful than many not-so-good ones. Hiring a bunch of not-so-good ones will slow down the good ones.
The performance bottleneck for most web applications is the database. If that isn't the case with yours, you're probably doing something wrong.
Choice of algorithm has a much greater effect on performance than choice of language does.
Your sloppy, ugly, unmaintainable code is not Perl's fault!