Common man give it a break xumer is not everything , if you don’t know whats SEO quit marketing,spamming all round isn’t something worth the trouble.My site is no follow any way,Mo rover its manually approved,so save trouble-DON’T SPAM THIS BLOG.

If you can read the
following paragraph, forward it on to your friends and the person that sent it to you with ‘yes’ in the subject line.

Only great minds can read
this

fi yuo cna
raed tihs, yuo hvae a sgtrane mnid too

Cna yuo raed tihs? Olny 55 plepoe
out of 100 can.

i cdnuolt blveiee taht I cluod aulaclty uesdnatnrd waht
I was rdanieg. The phaonmneal pweor of the hmuan mnid, aoccdrnig to a rscheearch
at Cmabrigde Uinervtisy, it dseno’t mtaetr in waht oerdr the ltteres in a wrod
are, the olny iproamtnt tihng is taht the frsit and lsat ltteer be in the rghit
pclae. The rset can be a taotl mses and you can sitll raed it whotuit a pboerlm.
Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe. Azanmig huh? yaeh and I awlyas tghuhot slpeling was ipmorantt!
if you can raed tihs forwrad it

FORWARD ONLY IF YOU CAN READ IT

Forward it & put ‘YES’ in the Subject
Line

It will take just 37 seconds to read this and change your thinking..

Two men, both seriously ill, occupied the same hospital room.

One man was allowed to sit up in his bed for an hour each afternoon to help drain the fluid from his lungs.

His bed was next to the room’s only window.

The other man had to spend all his time flat on his back.

The men talked for hours on end.

They spoke of their wives and families, their homes, their jobs, their involvement in the military service, where they had been on vacation..

Every afternoon, when the man in the bed by the window could sit up, he would pass the time by describing to his roommate all the things he could see outside the window.

The man in the other bed began to live for those one hour periods where his world would be broadened and enlivened by all the activity and colour of the world outside.

The window overlooked a park with a lovely lake.

Ducks and swans played on the water while children sailed their model boats. Young lovers walked arm in arm amidst flowers of every colour and a fine view of the city skyline could be seen in the distance.

As the man by the window described all this in exquisite details, the man on the other side of the room would close his eyes and imagine this picturesque scene.

One warm afternoon, the man by the window described a parade passing by.

Although the other man could not hear the band – he could see it in his mind’s eye as the gentleman by the window portrayed it with descriptive words.

Days, weeks and months passed.

One morning, the day nurse arrived to bring water for their baths only to find the lifeless body of the ma n by the window, who had died peacefully in his sleep.

She was saddened and called the hospital attendants to take the body away.

As soon as it seemed appropriate, the other man asked if he could be moved next to the window. The nurse was happy to make the switch, and after making sure he was comfortable, she left him alone.

0A

Slowly, painfully, he propped himself up on one elbow to take his first look at the real world outside.
He strained to slowly turn to look out the window besides the bed..

It faced a blank wall.

The man asked the nurse what could have compelled his deceased roommate who had described such wonderful things outside this window.

The nurse responded that the man was blind and could not even see the wall.

She said, ‘Per haps he just wanted to encourage you.’

Epilogue:

There is tremendous happiness in making others happy, despite our own situations.

Shared grief is half the sorrow, but happiness when shared, is doubled.

If you want to feel rich, just count all the things you have that money can’t buy.

‘Today is a gift, that is why it is called The Present .’

source:-Via Email

Damn kids. They’re all alike.

But did you, in your three-piece psychology and 1950’s technobrain, ever take a look behind the eyes of the hacker? Did you ever wonder what made him tick, what forces shaped him, what may have molded him?

I am a hacker, enter my world…

Mine is a world that begins with school… I’m smarter than most of the other kids, this crap they teach us bores me…

Damn underachiever. They’re all alike.

I’m in junior high or high school. I’ve listened to teachers explain for the fifteenth time how to reduce a fraction. I understand it. “No, Ms. Smith, I didn’t show my work. I did it in my head…”

Damn kid. Probably copied it. They’re all alike.

I made a discovery today. I found a computer. Wait a second, this is cool. It does what I want it to. If it makes a mistake, it’s because I screwed it up. Not because it doesn’t like me… Or feels threatened by me.. Or thinks I’m a smart ass.. Or doesn’t like teaching and shouldn’t be here…

Damn kid. All he does is play games. They’re all alike.

And then it happened… a door opened to a world… rushing through the phone line like heroin through an addict’s veins, an electronic pulse is sent out, a refuge from the day-to-day incompetencies is sought… a board is found. “This is it… this is where I belong…” I know everyone here… even if I’ve never met them, never talked to them, may never hear from them again… I know you all…

Damn kid. Tying up the phone line again. They’re all alike…

You bet your ass we’re all alike… we’ve been spoon-fed baby food at school when we hungered for steak… the bits of meat that you did let slip through were pre-chewed and tasteless. We’ve been dominated by sadists, or ignored by the apathetic. The few that had something to teach found us willing pupils, but those few are like drops of water in the desert.

This is our world now… the world of the electron and the switch, the beauty of the baud. We make use of a service already existing without paying for what could be dirt-cheap if it wasn’t run by profiteering gluttons, and you call us criminals. We explore… and you call us criminals. We seek after knowledge… and you call us criminals. We exist without skin color, without nationality, without religious bias… and you call us criminals. You build atomic bombs, you wage wars, you murder, cheat, and lie to us and try to make us believe it’s for our own good, yet we’re the criminals.

Yes, I am a criminal. My crime is that of curiosity. My crime is that of judging people by what they say and think, not what they look like. My crime is that of outsmarting you, something that you will never forgive me for.

I am a hacker, and this is my manifesto. You may stop this individual, but you can’t stop us all… after all, we’re all alike.

note:-this was origianlly written by +++The Mentor+++
Written January 8, 1986
here the hacker usually represnets a black hat hacker

A clever person solves a problem.
A wise person avoids it.

– Einstein

André Bensoussan once explained to me the difference between a programmer and a designer:

“If you make a general statement, a programmer says, ‘Yes, but…’
while a designer says, ‘Yes, and…’”

No matter what the problem is,
it’s always a people problem.

Jerry Weinberg

Wexelblat’s Scheduling Algorithm:

Choose two:

* Good
* Fast
* Cheap

Craziness is doing the same thing and expecting a different result.

Tom DeMarco, rephrasing Einstein, who said

Insanity: doing the same thing over and over again and expecting different results.

“There’s no time to stop for gas, we’re already late”

– Karin Donker
Deming’s 14 points

1. Create constancy of purpose.
2. Adopt the new philosophy.
3. Cease dependence on mass inspection to achieve quality.
4. Minimize total cost, not initial price of supplies.
5. Improve constantly the system of production and service.
6. Institute training on the job.
7. Institute leadership.
8. Drive out fear.
9. Break down barriers between departments.
10. Eliminate slogans, exhortations, and numerical targets.
11. Eliminate work standards (quotas) and management by objective.
12. Remove barriers that rob workers, engineers, and managers of their right to pride of workmanship.
13. Institute a vigorous program of education and self-improvement.
14. Put everyone in the company to work to accomplish the transformation.

We know about as much about software quality problems as they knew about the Black Plague in the 1600s. We’ve seen the victims’ agonies and helped burn the corpses. We don’t know what causes it; we don’t really know if there is only one disease. We just suffer — and keep pouring our sewage into our water supply.

– Tom Van Vleck
The Troops Know

* The schedule doesn’t have enough time for maintenance in it.
* A lot of bugs get past the tests.
* Most old code can’t be maintained.

To go faster, slow down. Everybody who knows about orbital mechanics understands that.

– Scott Cherf
Everybody Knows:

* Discipline is the best tool.
* Design first, then code.
* Don’t patch bugs out, rewrite them out.
* Don’t test bugs out, design them out.

Everybody Knows:

* If you don’t understand it, you can’t program it.
* If you didn’t measure it, you didn’t do it.

Everybody Knows:

If something is worth doing once, it’s worth building a tool to do it.

Your problem is another’s solution;
Your solution will be his problem.
Everybody Knows:

* If you’ve found 3 bugs in a program, best estimate is that there are 3 more.
* 60% of product cost comes after initial shipment.

The significant problems we face cannot be solved by the same level of thinking that created them.

– Albert Einstein

On the radio the other night, Jimmy Connors said the best advice he ever got was from Bobby Riggs:

* do it
* do it right
* do it right now

It is not enough to do your best: you must know what to do, and THEN do your best.

– W. Edwards Deming

A leader is best when people barely know that he exists.
Less good when they obey and acclaim him.
Worse when they fear and despise him.
Fail to honor people, and they fail to honor you.
But of a good leader, when his work is done, his aim fulfilled,
they will say, “We did this ourselves.”

– Lao-Tzu

You must be the change
You wish to see in the world

– Gandhi

Experiment escorts us last,
His pungent company
Will not allow an axiom
An opportunity.

– Emily Dickinson

when the cart stops
do you whip the cart
or whip the ox?

Q: How many QA testers does it take to change a lightbulb?
A: QA testers don’t change anything. They just report that it’s dark.

Kerry Zallar

Q: How many software engineers does it take to change a lightbulb?
A: Just one. But the house falls down.

Andrew Siwko

One test is worth a thousand opinions.

“If you didn’t write it down, it didn’t happen.”

This saying is popular among scientists (doing experiments), but I believe it applies to software testing, particularly for real-time systems.

–Larry Zana

We reject kings, presidents, and voting.
We believe in rough consensus and running code.

–Dave Clark (1992)

I am a design chauvinist. I believe that good design is magical and not to be lightly tinkered with. The difference between a great design and a lousy one is in the meshing of the thousand details that either fit or don’t, and the spirit of the passionate intellect that has tied them together, or tried. That’s why programming—or buying software—on the basis of “lists of features” is a doomed and misguided effort. The features can be thrown together, as in a garbage can, or carefully laid together and interwoven in elegant unification, as in APL, or the Forth language, or the game of chess.

– Ted Nelson

Software is Too Important to be Left to Programmers, by Meilir Page-Jones.

“If you think good architecture is expensive, try bad architecture.”

– Brian Foote and Joseph Yoder

Abraham Lincoln reportedly said that, given eight hours to chop down a tree, he’d spend six sharpening his axe.

– TidBITS 654, quoted by Derek K. Miller, via Art Evans

… while we all know that unmastered complexity is at the root of the misery, we do not know what degree of simplicity can be obtained, nor to what extent the intrinsic complexity of the whole design has to show up in the interfaces. We simply do not know yet the limits of disentanglement. We do not know yet whether intrinsic intricacy can be distinguished from accidental intricacy.

– E. W. Dijkstra, Communications of the ACM, Mar 2001, Vol. 44, No. 3

You can only find truth with logic if you have already found truth without it.

– Gilbert Keith Chesterton (1874-1936) ” The Man who was Orthodox”, via Paul Black
And here is the rest of it.

Introductory-level programming courses teach students to comment early and comment often. The idea is that it’s better to have too many comments than to have too few. Unfortunately, many programmers seem to take this as a personal challenge to comment every single line of code. This is why you will often see something like this code snippit taken from Jeff Atwood’s post on Coding Without Comments:

[code:c#]

r = n / 2; // Set r to n divided by 2

// Loop while r - (n/r) is greater than t
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}

[/code]

Do you have any idea what this code does? Me neither. The problem is that while there are plenty of comments describing what the code is doing, there are none describing why it’s doing it.

Now, consider the same code with a different commenting methodology:

[code:c#]

// square root of n with Newton-Raphson approximation
r = n / 2;

while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}

[/code]

Much better! We still might not understand exactly what’s going on here, but at least we have a starting point.

Comments are supposed to help the reader understand the code, not the syntax. It’s a fair assumption that the reader has a basic understanding of how a for loop works; there’s no need to add comments such as “// iterate over a list of customers”. What the reader is not going to be familiar with is why your code works and why you chose to write it the way you did.

9. Interruptions

Very few programmers can go from 0 to code at the drop of a hat. In general, we tend to be more akin to locomotives than ferraris; it may take us awhile to get started, but once we hit our stride we can get an impressive amount of work done. Unfortunately, it’s very hard to get into a programming zone when your train of thought is constantly being derailed by clients, managers, and fellow programmers.

There is simply too much information we need to keep in mind while we’re working on a task to be able to drop the task, handle another issue, then pick up the task without missing a beat. Interruptions kill our train of thought and getting it back is often a time-consuming, frustrating, and worst of all, error-prone process.

8. Scope creep

From Wikipedia:

Scope creep (also called focus creep, requirement creep, feature creep, and sometimes kitchen sink syndrome) in project management refers to uncontrolled changes in a project’s scope. This phenomenon can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered a negative occurrence that is to be avoided.

Scope creep turns relatively simple requests into horribly complex and time consuming monsters. It only takes a few innocent keystrokes by the requirements guy for scope creep to happen:

• Version 1: Show a map of the location
• Version 2: Show a 3D map of the location
• Version 3: Show a 3D map of the location that the user can fly through

Argh! What used to be a 30 minute task just turned into a massively complex system that could take hundreds of man hours. Even worse, most of the time scope creep happens during development, which requires rewriting, refactoring, and sometimes throwing out code that was developed just days prior.

7. Management that doesn’t understand programming

Ok, so maybe there are some perks.

Management is not an easy job. People suck; we’re fickle and fragile and we’re all out for #1. Keeping a large group of people content and cohesive is a mountain of a task. However, that doesn’t mean that managers should be able to get away without having some basic understanding of what their subordinates are doing, especially in the tech industry. When management cannot grasp the basic concepts of our jobs, we end up with scope creep, unrealistic deadlines, and general frustration on both sides of the table. This is a pretty common complaint amongst programmers and the source of a lot of angst (as well as one hilarious cartoon).

6. Documenting our applications

Let me preface this by saying that yes, I know that there are a lot of documentation-generating applications out there, but in my experience those are usually only good for generating API documentation for other programmers to read. If you are working with an application that normal everyday people are using, you’re going to have to write some documentation that the average layman can understand (e.g. how your application works, troubleshooting guides, etc.).

It’s not hard to see that this is something programmers dread doing. Take a quick look at all the open-source projects out there. What’s the one thing that all of them are constantly asking for help with? Documentation.

I think I can safely speak on behalf of all programmers everywhere when I say, “can’t someone else do it?“.

5. Applications without documentation

I never said that we weren’t hypocrites. Programmers are constantly asked to incorporate 3rd party libraries and applications into their work. In order to do that, we need documentation. Unfortunately, as mentioned in item 6, programmers hate writing documentation. No, the irony is not lost on us.

There’s nothing more frustrating than trying to utilize a 3rd party library while having absolutely no fricken idea what half the functions in the API do. What’s the difference between poorlyNamedFunctionA() and poorlyButSimilarlyNamedFunctionB()? Do I need to perform a null check before accessing PropertyX? I guess I’ll just have to find out through trial and error! Ugh.

4. Hardware

Any programmer who has ever been called upon to debug a strange crash on the database server or why the RAID drives aren’t working properly knows that hardware problems are a pain. There seems to be a common misconception that since programmers work with computers, we must know how to fix them. Granted, this may be true for some programmers, but I reckon the vast majority of us don’t know or really care about what’s going on after the code gets translated into assembly. We just want the stuff to work like it’s supposed to so we can focus on higher level tasks.

3. Vagueness

“The website is broken”. “Feature X isn’t working properly”. Vague requests are a pain to deal with. It’s always surprising to me how exasperated non-programmers tend to get when they are asked to reproduce a problem for a programmer. They don’t seem to understand that “it’s broken, fix it!” is not enough information for us to work off of.

Software is (for the most part) deterministic. We like it that way. Humor us by letting us figure out which step of the process is broken instead of asking us to simply “fix it”.

2. Other programmers

Programmers don’t always get along with other programmers. Shocking, but true. This could easily be its own top 10 list, so I’m just going to list some of the common traits programmers have that annoy their fellow programmers and save going into detail for a separate post:

• Being grumpy to the point of being hostile.
• Failing to understand that there is a time to debate system architecture and a time to get things done.
• Inability to communicate effectively and confusing terminology.
• Failure to pull ones own weight.
• Being apathetic towards the code base and project

And last, but not least, the number 1 thing that annoys programmers…

1. Their own code, 6 months later

Don’t sneeze, I think I see a bug.

Ever look back at some of your old code and grimace in pain? How stupid you were! How could you, who know so much now, have written that? Burn it! Burn it with fire!

Well, good news. You’re not alone.

The truth is, the programming world is one that is constantly changing. What we regard as a best practice today can be obsolete tomorrow. It’s simply not possible to write perfect code because the standards upon which our code is judged is evolving every day. It’s tough to cope with the fact that your work, as beautiful as it may be now, is probably going to be ridiculed later. It’s frustrating because no matter how much research we do into the latest and greatest tools, designs, frameworks, and best practices, there’s always the sense that what we’re truly after is slightly out of reach. For me, this is the most annoying thing about being a programmer. The fragility of what we do is necessary to facilitate improvement, but I can’t help feeling like I’m one of those sand-painting monks.

Well, there you have it. The top 10 things that annoy programmers. Again, if you feel that I missed anything please be sure to let me know in the comments!

click on image to enlarge..