25 Programming Quotes

25 Favorite Programming Quotes that are Funny too

Recently I was looking for some good programming quotes for one of my presentation. I was amazed to find that there are some good programming quotes that are really funny and need some brains to figure out the fun part.
Here are 25 of them I like in random order.
The best thing about a boolean is even if you are wrong, you are only off by a bit. (Anonymous)
Without requirements or design, programming is the art of adding bugs to an empty text file. (Louis Srygley)
Before software can be reusable it first has to be usable. (Ralph Johnson)
The best method for accelerating a computer is the one that boosts it by 9.8 m/s2. (Anonymous)
I think Microsoft named .Net so it wouldn’t show up in a Unix directory listing. (Oktal)
If builders built buildings the way programmers wrote programs, then the first woodpecker that came along wound destroy civilization. (Gerald Weinberg)
There are two ways to write error-free programs; only the third one works. (Alan J. Perlis)
Ready, fire, aim: the fast approach to software development. Ready, aim, aim, aim, aim: the slow approach to software development. (Anonymous)
It’s not a bug – it’s an undocumented feature. (Anonymous)
One man’s crappy software is another man’s full time job. (Jessica Gaston)
A good programmer is someone who always looks both ways before crossing a one-way street. (Doug Linder)
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. (Martin Golding
Programming is like sex. One mistake and you have to support it for the rest of your life. (Michael Sinz)
Deleted code is debugged code. (Jeff Sickel)
Walking on water and developing software from a specification are easy if both are frozen. (Edward V Berard)
If debugging is the process of removing software bugs, then programming must be the process of putting them in. (Edsger Dijkstra)
Software undergoes beta testing shortly before it’s released. Beta is Latin for “still doesn’t work. (Anonymous)
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. (Anonymous)
It’s a curious thing about our industry: not only do we not learn from our mistakes, we also don’t learn from our successes. (Keith Braithwaite)
There are only two kinds of programming languages: those people always bitch about and those nobody uses. (Bjarne Stroustrup)
In order to understand recursion, one must first understand recursion. (Anonymous)
The cheapest, fastest, and most reliable components are those that aren’t there. (Gordon Bell)
The best performance improvement is the transition from the nonworking state to the working state. (J. Osterhout)
The trouble with programmers is that you can never tell what a programmer is doing until it’s too late. (Seymour Cray)
Don’t worry if it doesn’t work right. If everything did, you’d be out of a job. (Mosher’s Law of Software Engineering)
So what are your favorite and funny quotes? Please share with all of us.


:Source:

Software Development-The 7 Deadly Sins


The 7 deadly sins of software development

Recognize the worst traits of programmers everywhere and save yourself from developer hell


Being a good developer takes a lifetime of training and practice. But without proper discipline, even the best programmers risk falling prey to their worse natures. Some bad habits are so insidious that they crop up again and again, even among the most experienced developers. I speak of nothing less than the seven deadly sins of software development. Read on to hear how lust, gluttony, greed, sloth, wrath, envy, and pride may be undermining your latest programming project as we speak.
First deadly sin of software development: Lust (overengineering)
Modern programming languages tend to add features as they mature. They pile on layer after layer of abstraction, with new keywords and structures designed to aid code readability and reusability -- provided you take the time to learn how to use them properly.

At the same time, the discipline of programming has changed over the years. Today you have giant tomes of design patterns to pore over, and every few months someone comes up with a new development methodology that they swear will transform you into a god among programmers.
But what looks good on paper doesn't always work in practice, and just because you can do something doesn't mean you should. As programming guru Joel Spolsky puts it, "Shipping is a feature. A really important feature. Your product must have it." Programmers who fetishize their tools inevitably lose sight of this, and even the seemingly simplest of projects can end up mired in development hell. Resist your baser impulses and stick to what works.
Second deadly sin of software development: Gluttony (failing to refactor)
Nothing is more gratifying than shipping software. Once you have a working product out in the wild, the temptation is strong to begin planning the next iteration. What new features should it have? What didn't we have time to implement the first go-round?
It's easy to forget that code seldom leaves the door in perfect shape. Then, as features accumulate with successive rounds of development, programmers tend to compound mistakes of the past, resulting in a bloated, fragile code base that's too tangled to maintain effectively.
Instead of gobbling up plate after plate of new features, restrain yourself. Evaluate your existing code for quality and maintainability. Make code refactoring a line item on your budget for each new round of development. Clients may see only the new features in each release, but over the long term, they'll thank you for keeping off the fat.
Third deadly sin of software development: Greed (competing across teams)
The excessive desire for wealth and power -- how else to explain the motives of programmers who compete with their own coworkers? It starts when other teams are left off email lists, then proceeds to closed-door meetings. Next thing you know, one team has written a library that reimplements more than half of the functionality already coded by another team.
Programming teams seldom reinvent the wheel out of malice, but lacking clearly defined objectives, they can easily latch onto responsibilities much broader than are strictly necessary. The result is a redundant, unmanageable code base, to say nothing of the budget lost to duplicated efforts. One of the top priorities of managing a development project should be to make sure each hand knows what the other is doing, and that all the teams are working toward a common goal. Share and share alike should be your motto.

Fourth deadly sin of software development: Sloth (not validating inputs)
The list of basic programming mistakes is long, but the sin of failing to validate input is so pernicious that it bears special consideration. Why this seemingly amateur error still crops up in code written by experienced programmers is baffling. And yet, many commonplace security vulnerabilities, from buffer overruns to SQL injection attacks, can be traced directly to code that operates on user input without validating it for correct formatting.
Modern programming languages provide many tools to help coders keep this from happening, but they have to be used properly. Remember, a Web form that uses JavaScript to validate its inputs can be easily sidestepped by disabling JavaScript in the browser or not using a browser to access it at all. Input validation should be baked into the core of your application, not sprinkled onto the UI. Anything less is simple laziness.
Fifth deadly sin of software development: Wrath (not commenting code)
What act could be more hostile to your fellow programmers than failing to comment your code? I know, I know: Well-written code is its own best documentation. Well, guess what? Those methods you wrote at two in the morning last Thursday weren't exactly well-written code. (And if you're a Perl hacker, you owe me nine Hail Marys.)
It's easy for programmers to forget that the code they write today may live on long after they've left the job. To the programmers who replace them falls the unenviable task of figuring out what each snippet of code actually means. So have mercy, and leave them a few hints.
But remember, unintelligible comments or commenting too much can be as bad as not commenting at all. Comments like "this is broken" or "don't touch this ever" aren't much help to anybody. Neither are redundant comments explaining simple operations, such as variable initializations. Code is its own best documentation of what it does; comments should be there to explain the why.
Sixth deadly sin of software development: Envy (not using version control)
It's hard to believe there are still software projects in 2011 that exist as a directory tree on a file server, jealously guarded by one "master maintainer." Scattered around the office are duplicates of this tree on individual developers' workstations, each slightly different -- though no one knows exactly how.
Maybe you have reasons for not implementing version control on your projects. Maybe it started small and just got out of hand. But powerful, effective version control systems are readily available today for free. Service providers are even available to host code for distributed projects for minimal cost. There is no reason why you shouldn't make starting a code repository one of the first steps in any project, even small ones -- unless, that is, you can't stand to see anyone commit code changes but yourself.
Seventh deadly sin of software development: Pride (not unit testing)
It's often tempting to pat yourself on the back for a programming job well done. But how do you know it's well done? What are your metrics?
Unless you've validated your code against specific test cases, you have no idea whether it works as advertised and is completely free of defects. But all too many developers fail to produce unit tests for their code. They claim time spent testing is time not spent implementing features. In fact, some developers fail to even write QA testing into their project budgets.
What can I say, except that pride goeth before a fall? By the time defective code arrives in the client's hands, it's too late to undo the mistake. The more you plan for unit testing before your code ships, the more damage control you can avoid later.



Source: infoworld

The 5 types of Programmers

The 5 types of Programmers
Awesome Code
In my code journeys and programming adventures I’ve encountered many strange foes, and even stranger allies. I’ve identified at least five different kinds of code warriors, some make for wonderful comrades in arms, while others seem to foil my every plan.
However they all have their place in the pantheon of software development. Without a healthy mix of these different programming styles you’ll probably find your projects either take too long to complete, are not stable enough or are too perfect for humans to look upon.

The duct tape programmer

Duct TapeThe code may not be pretty, but damnit, it works!
This guy is the foundation of your company. When something goes wrong he will fix it fast and in a way that won’t break again. Of course he doesn’t care about how it looks, ease of use, or any of those other trivial concerns, but he will make it happen, without a bunch of talk or time-wasting nonsense. The best way to use this person is to point at a problem and walk away.

The OCD perfectionist programmer

PerfectionYou want to do what to my code?
This guy doesn’t care about your deadlines or budgets, those are insignificant when compared to the art form that is programming. When you do finally receive the finished product you will have no option but submit to the stunning glory and radiant beauty of perfectly formatted, no, perfectly beautiful code, that is so efficient that anything you would want to do to it would do nothing but defame a masterpiece. He is the only one qualified to work on his code.

The anti-programming programmer

Anti-ProgrammingI’m a programmer, damnit. I don’t write code.
His world has one simple truth; writing code is bad. If you have to write something then you’re doing it wrong. Someone else has already done the work so just use their code. He will tell you how much faster this development practice is, even though he takes as long or longer than the other programmers. But when you get the project it will only be 20 lines of actual code and will be very easy to read. It may not be very fast, efficient, or forward-compatible, but it will be done with the least effort required.

The half-assed programmer

Half-assedWhat do you want? It works doesn’t it?
The guy who couldn’t care less about quality, that’s someone elses job. He accomplishes the tasks that he’s asked to do, quickly. You may not like his work, the other programmers hate it, but management and the clients love it. As much pain as he will cause you in the future, he is single-handedly keeping your deadlines so you can’t scoff at it (no matter how much you want to).

The theoretical programmer

TheoreticalWell, that’s a possibility, but in practice this might be a better alternative.
This guy is more interested the options than what should be done. He will spend 80% of his time staring blankly at his computer thinking up ways to accomplish a task, 15% of his time complaining about unreasonable deadlines, 4% of his time refining the options, and 1% of his time writing code. When you receive the final work it will always be accompanied by the phrase “if I had more time I could have done this the right way”.

Where do you fit?

Personally, I’d have to classify myself as the perfectionist. So, which type of programmer are you? Or perhaps you know another programming archetype that is missing from my list? Post a comment below and I’ll add it to a new updated list.


Source:stevenbenner