1. Bias against action: There are always plenty of reasons not to take a decision, reasons to wait for more information, more options, more opinions. But real leaders display a consistent bias for action. People who don’t make mistakes generally don’t make anything. Legendary ad man David Ogilvy argued that a good decision today is worth far more than a perfect decision next month. Beware prevaricators.
2. Secrecy: “We can’t tell the staff,” is something I hear managers say repeatedly. They defend this position with the argument that staff will be distracted, confused or simply unable to comprehend what is happening in the business. If you treat employees like children, they will behave that way — which means trouble. If you treat them like adults, they may just respond likewise. Very few matters in business must remain confidential and good managers can identify those easily. The lover of secrecy has trouble being honest and is afraid of letting peers have the information they need to challenge him. He would rather defend his position than advance the mission. Secrets make companies political, anxious and full of distrust.
3. Over-sensitivity: “I know she’s always late, but if I raise the subject, she’ll be hurt.” An inability to be direct and honest with staff is a critical warning sign. Can your manager see a problem, address it headlong and move on? If not, problems won’t get resolved, they’ll grow. When managers say staff is too sensitive, they are usually describing themselves. Wilting violets don’t make great leaders. Weed them out. Interestingly, secrecy and over-sensitivity almost always travel together. They are a bias against honesty.
4. Love of procedure: Managers who cleave to the rule book, to points of order and who refer to colleagues by their titles have forgotten that rules and processes exist to expedite business, not ritualize it. Love of procedure often masks a fatal inability to prioritize — a tendency to polish the silver while the house is burning.
5. Preference for weak candidates: We interviewed three job candidates for a new position. One was clearly too junior, the other rubbed everyone up the wrong way and the third stood head and shoulders above the rest. Who did our manager want to hire? The junior. She felt threatened by the super-competent manager and hadn’t the confidence to know that you must always hire people smarter than yourself.
6. Focus on small tasks: Another senior salesperson I hired always produced the most perfect charts, forecasts and spreadsheets. She was always on time, her data completely up-to-date. She would always volunteer for projects in which she had no core expertise — marketing plans, financial forecasts, meetings with bank managers, the office move. It was all displacement activity to hide the fact that she could not do her real job.
7. Inability to hire former employees: I hired a head of sales once with (apparently) a luminous reputation. But, as we staffed up, he never attracted any candidates from his old company. He’d worked in sales for twenty years — hadn’t he mentored anyone who’d want to work with him again? Every good manager has alumni, eager to join the team again; if they don’t, smell a rat.
8. Allergy to deadlines: A deadline is a commitment. The manager who cannot set, and stick to deadlines, cannot honor commitments. A failure to set and meet deadlines also means that no one can ever feel a true sense of achievement. You can’t celebrate milestones if there aren’t any.
9. Addiction to consultants: A common — but expensive — way to put off making decisions is to hire consultants who can recommend several alternatives. While they’re figuring these out, managers don’t have to do anything. And when the consultant’s choices are presented, the ensuing debates can often absorb hours, days, months. Meanwhile, your organization is poorer but it isn’t any smarter. When the consultant leaves, he takes your money and his increased expertise out the door with him.
10. Long hours: In my experience, bad managers work very long hours. They think this is a brand of heroism but it is probably the single biggest hallmark of incompetence. To work effectively, you must prioritize and you must pace yourself. The manager who boasts of late nights, early mornings and no time off cannot manage himself so you’d better not let him manage anyone else.

Lots of Javascript libraries and frameworks have come up. It has been made to make the life of developer really easy. Here is the list of all available Javascript frameworks, http://www.javascriptlibraries.com/

But, I have got a very big question to ask, “are these framework making the life of Developer really easy?”

With the increase in the speed and number of the javascript framework, its getting difficult for the developers to decide which framework is to be used where.

Here, http://mootools.net/slickspeed/, you can test the speed/validity selector test for some of the major frameworks available.

You can get comparison matrix for most of the Javascript framework here,

http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks

The following guidelines might help you to decide which framework you should go for,

What are your project requirements?

The first and most important question you need to ask yourself is what are your project requirements? Is this a Web site or application that requires AJAX, robust support for handling events, or how about a library of effects? How much functionality do you need out-of-the-box, and what level of experience will be required by other programmers and designers to support this framework? If you have few requirements, you could find success with an extremely lightweight, modular library. Also you need check if your project requires effects, AJAX, graphics, tools etc

Does the framework supports all the browsers?

Once you know your audience, and your project requirements, you need to consider whether or not your JavaScript framework supports all the needed browsers. Most frameworks do, but there are often some exceptions in the fine print — typically with Safari on the Mac. If you are building an internal Web application for an Intranet, you might only be required to support a limited set of browsers.

How mature is the framework?

More than anything, the maturity of a framework demonstrates a commitment to longevity, as well as a solid foundation. A mature framework will no longer be in beta, and will have been through a full release cycle. There should be a growing, if not thriving community, and depending on the open-source license, a mature framework might also support a Subversion or CVS version repository. Any bug fixes can be rolled into a build without a public release, which is a huge plus.

How often are updates publicly released?

If you find that the community questions or complains about the release cycle, then that could be a warning sign. Long delays and bloated releases are also a sure sign that you will not enjoy supporting the framework on future projects. Alternatively, too many public releases could indicate instability, or a lack of focus.

How friendly is the documentation?

A major differentiators between JavaScript frameworks today is documentation. This not only includes official documentation for the API, but also includes books, tutorials, and blogs. The worst documentation is the sort that is only focused on syntax. Look for a framework that includes examples with each method and property, and that is updated to meet the needs of the community. Documentation is simple to research, and it can be a lifesaver when dealing with tight deadlines.

Is there an active community?

An active community does not guarantee a quality framework, but it does help a framework evolve. The character of the community is also an excellent gage of the type of help you might receive in the future when caught in a bind. Are there forums, or a Google Group? Are experienced users willing and able to lend a helping hand, or will they send you elsewhere for assistance? Are developers creating extensions, or contributing to the core framework? All of these are important questions.

Are benchmark tests performed regularly?

Benchmark tests are often questionable when determining the quality of workmanship put into a framework, but they do demonstrate a developer’s willingness to adopt some quality assurance best practices. Even a modest gain in speed, or a decrease in download size during a release cycle can be seen as a positive improvement.

How extensible is the framework?

Extensibility is typically a requirement of experienced programmers, and is rarely a request of designers. Plugin support is definitely a plus for any JavaScript framework, but developers usually just want to know — how difficult will it be to troubleshoot the core library? Layers of functionality provided by an active community do give a framework uniqueness, but this is a beneficial byproduct, and not often a necessity.

Do you like the API style?

This is an important, but complicated question that is answered for most developers only after using several JavaScript frameworks on numerous projects. Complaints about frameworks like Yahoo! UI are generally in regards to the style with which the API has been designed. Terseness, as well as chainability, are two very important features that should not be overlooked. Remember, you can grow irritated quickly because of cumbersome implementation details.