Very Important Please Dont Miss it.
Review these typical interview questions and think about how you would answer them. Read the questions listed; you will also find some strategy suggestions with it.
1. Tell me about yourself?
Ans : The most often asked question in interviews. You need to have a short statement prepared in your mind. Be careful that it does not sound rehearsed. Limit it to work-related items unless instructed otherwise. Talk about things you have done and jobs you have held that relate to the position you are interviewing for. Start with the item farthest back and work up to the present.
2. Why did you leave your last job?
Ans: Stay positive regardless of the circumstances. Never refer to a majorproblem with management and never speak ill of supervisors, co-workers or the organization. If you do, you will be the one looking bad. Keep smiling and talk about leaving for a positive reason such as an opportunity, a chance to do something special or other forward-looking reasons.
3. What experience do you have in this field?
Ans: Speak about specifics that relate to the position you are applying for. If you do not have specific experience, get as close as you can.
4. Do you consider yourself successful?
Ans:You should always answer yes and briefly explain why. A good explanation is that you have set goals, and you have met some and are on track to achieve the others.
5. What do co-workers say about you?
Ans: Be prepared with a quote or two from co-workers. Either a specific statement or a paraphrase will work. Jill Clark, a co-worker at Smith Company, always said I was the hardest workers she had ever known. It is as powerful as Jill having said it at the interview herself.
6. What do you know about this organization?
This question is one reason to do some research on the organization before the interview. Find out where they have been and where they are going. What are the current issues and who are the major players?
7.. What have you done to improve your knowledge in the last year?
Try to include improvement activities that relate to the job. A wide variety of activities can be mentioned as positive self-improvement. Have some good ones handy to mention.
8. Are you applying for other jobs?
Be honest but do not spend a lot of time in this area. Keep the focuson this job and what you can do for this organization. Anything else is a distraction.
9. Why do you want to work for this organization?
This may take some thought and certainly, should be based on the research you have done on the organization. Sincerity is extremely important here and will easily be sensed. Relate it to your long-term career goals.
10. Do you know anyone who works for us?
Be aware of the policy on relatives working for the organization. This can affect your answer even though they asked about friends not relatives. Be careful to mention a friend only if they are well thought of.
11. What is your Expected Salary?
A loaded question. A nasty little game that you will probably lose if you answer first. So, do not answer it. Instead, say something like, That's a tough question. Can you tell me the range for this position? In most cases, the interviewer, taken off guard, will tell you. If not, say that it can depend on the details of the job. Then give a wide range.
12. Are you a team player?
You are, of course, a team player. Be sure to have examples ready. Specifics that show you often perform for the good of the team rather than for yourself are good evidence of your team attitude. Do not brag, just say it in a matter-of-fact tone. This is a key point..
13. How long would you expect to work for us if hired?
Specifics here are not good. Something like this should work: I'd like it to be a long time. Or As long as we both feel I'm doing a good job.
14. Have you ever had to fire anyone?
How did you feel about that? This is serious. Do not make light of it or in any way seem like you like to fire people. At the same time, you will do it when it is the right thing to do. When it comes to the organization versus the individual who has created a harmful situation, you will protect the organization. Remember firing is not the same as layoff or reduction in force.
15. What is your philosophy towards work?
The interviewer is not looking for a long or flowery dissertation here. Do you have strong feelings that the job gets done? Yes. That's the type of answer that works best here. Short and positive, showing a benefit to the organization.
16. If you had enough money to retire right now, would you?
Answer yes if you would. But since you need to work, this is the type of work you prefer. Do not say yes if you do not mean it.
17. Have you ever been asked to leave a position?
If you have not, say no. If you have, be honest, brief and avoid saying negative things about the people or organization involved.
18. Explain how you would be an asset to this organization ?
You should be anxious for this question. It gives you a chance to highlight your best points as they relate to the position being discussed. Give a little advance thought to this relationship. .
19. Why should we hire you?
Point out how your assets meet what the organization needs. Do not mention any other candidates to make a comparison..
20. Tell me about a suggestion you have made ?
Have a good one ready. Be sure and use a suggestion that was accepted and was then considered successful. One related to the type of work applied for is a real plus.
21. What irritates you about co-workers?
This is a trap question. Think real hard but fail to come up with anything that irritates you. A short statement that you seem to get along with folks is great.
22. What is your greatest strength?
Numerous answers are good, just stay positive. A few good examples: Your ability to prioritize, Your problem-solving skills, Your ability to work under pressure, Your ability to focus on projects, Your professional expertise, Your leadership skills, Your positive attitude
23. Tell me about your dream job ?
Stay away from a specific job. You cannot win. If you say the job you are contending for is it, you strain credibility. If you say another job is it, you plant the suspicion that you will be dissatisfied with this position if hired. The best is to stay genetic and say something like: A job where I love the work, like the people, can contribute andcan't wait to get to work.
24. Why do you think you would do well at this job?
Give several reasons and include skills, experience and interest.
25. What are you looking for in a job?
See answer # 23
26. What kind of person would you refuse to work with?
Do not be trivial. It would take disloyalty to the organization, violence or lawbreaking to get you to object. Minor objections will label you as a whiner.
27. What is more important to you: the money or the work?
Money is always important, but the work is the most important. There is no better answer.
28. What would your previous supervisor say your strongest point is?
There are numerous good possibilities: Loyalty, Energy, Positive attitude, Leadership, Team player, Expertise,Initiativ e, Patience, Hard work, Creativity, Problem solver
29. Tell me about a problem you had with a supervisor?
Biggest trap of all. This is a test to see if you will speak ill of your boss. If you fall for it and tell about a problem with a former boss, you may well below the interview right there. Stay positive and develop a poor memory about any trouble with a supervisor.
30. What has disappointed you about a job?
Don't get trivial or negative. Safe areas are few but can include: Not enough of a challenge. You were laid off in a reduction Company did not win a contract, which would have given you more responsibility.
31. Tell me about your ability to work under pressure.
You may say that you thrive under certain types of pressure. Give an example that relates to the type of position applied for.
32. Do your skills match this job or another job more closely?
Probably this one. Do not give fuel to the suspicion that you may want another job more than this one.
33. What motivates you to do your best on the job?
This is a personal trait that only you can say, but good examples are: Challenge, Achievement, Recognition
34. Are you willing to work overtime? Nights? Weekends?
This is up to you. Be totally honest.
35. How would you know you were successful on this job?
Several ways are good measures: You set high standards for yourself and meet them. Your outcomes are a success. Your boss tell you that you are successful
36. Would you be willing to relocate if required?
You should be clear on this with your family prior to the interview if you think there is a chance it may come up. Do not say yes just to get the job if the real answer is no. This can create a lot of problems later on in your career. Be honest at this point and save yourself future grief.
37. Are you willing to put the interests of the organization ahead of your own?
This is a straight loyalty and dedication question. Do not worry about the deep ethical and philosophical implications. Just say yes.
38. Describe your management style ?
Try to avoid labels. Some of the more common labels, like progressive, salesman or consensus, can have several meanings or descriptions depending on which management expert you listen to. The situational style is safe, because it says you will manage according to the situation, instead of one size fits all.
39. What have you learned from mistakes on the job?
Here you have to come up with something or you strain credibility. Make it small, well intentioned mistake with a positive lesson learned. An example would be working too far ahead of colleagues on a project and thus throwing coordination off.
40. Do you have any blind spots?
Trick question. If you know about blind spots, they are no longer blind spots. Do not reveal any personal areas of concern here. Let them do their own discovery on your bad points. Do not hand it to them.
41. If you were hiring a person for this job, what would you look for?
Be careful to mention traits that are needed and that you have.
42. Do you think you are overqualified for this position?
Regardless of your qualifications, state that you are very well qualified for the position.
43. How do you propose to compensate for your lack of experience?
First, if you have experience that the interviewer does not know about, bring that up: Then, point out (if true) that you are a hard working quick learner.
44. What qualities do you look for in a boss?
Be generic and positive. Safe qualities are knowledgeable, a sense of humor, fair, loyal to subordinates and holder of high standards. All bosses think they have these traits.
45. Tell me about a time when you helped resolve a dispute ?
between others. Pick a specific incident. Concentrate on your problem solving technique and not the dispute you settled.
46. What position do you prefer on a team working on a project?
Be honest. If you are comfortable in different roles, point that out.
47. Describe your work ethic ?
Emphasize benefits to the organization. Things like, determination to get the job done and work hard but enjoy your work are good.
48. What has been your biggest professional disappointment?
Be sure that you refer to something that was beyond your control. Show acceptance and no negative feelings.
49. Tell me about the most fun you have had on the job.
Talk about having fun by accomplishing something for the organization.
50. Do you have any questions for me?
Always have some questions prepared. Questions prepared where you will be an asset to the organization are good. How soon will I be able to be productive? and What type of projects will I be able to assist on? are examples.
And Finally Best of Luck Hope you will be succussful in the interview you are going to face in coming days.
"Never take some one for granted,Hold every person Close to your Heart because you might wake up one day and realise that you have lost a diamond while you were too busy collecting stones." Remember this always in life.
Saturday, August 08, 2009
Monday, November 17, 2008
Windows 7 [Vienna]
Windows 7( Vienna)
Formerly known as Blackcomb and Vienna is the successor of Windows Vista. Windows 7 is expected to be released sometime in 2010
Windows 7 (formerly known as Blackcomb and Vienna) is the working name for the next major version of Microsoft Windows as the successor of Windows Vista.[1] Microsoft has announced that it is "scoping Windows 7 development to a three-year timeframe", and that "the specific release date will ultimately be determined by meeting the quality bar."[2] Windows 7 is expected to be released sometime in 2010.[3] The client versions of Windows 7 will ship in both 32-bit and 64-bit versions.[2] A server variant, codenamed Windows Server 7, is also under development.
Formerly known as Blackcomb and Vienna is the successor of Windows Vista. Windows 7 is expected to be released sometime in 2010
Windows 7 (formerly known as Blackcomb and Vienna) is the working name for the next major version of Microsoft Windows as the successor of Windows Vista.[1] Microsoft has announced that it is "scoping Windows 7 development to a three-year timeframe", and that "the specific release date will ultimately be determined by meeting the quality bar."[2] Windows 7 is expected to be released sometime in 2010.[3] The client versions of Windows 7 will ship in both 32-bit and 64-bit versions.[2] A server variant, codenamed Windows Server 7, is also under development.
Friday, November 07, 2008
WHY EMPLOYEES LEAVE ORGANISATIONS ?
Every company faces the problem of people leaving the company for better pay or profile.
Early this year, Mark, a senior software designer, got an offer from a prestigious international firm to work in its India operations developing specialized software. He was thrilled by the offer.
He had heard a lot about the CEO. The salary was great. The company had all the right systems in place employee-friendly human resources (HR) policies, a spanking new office,and the very best technology,even a canteen that served superb food.
Twice Mark was sent abroad for training. "My learning curve is the sharpest it's ever been," he said soon after he joined.
Last week, less than eight months after he joined, Mark walked out of the job.
Why did this talented employee leave ?
Arun quit for the same reason that drives many good people away.
The answer lies in one of the largest studies undertaken by the Gallup Organization. The study surveyed over a million employees and 80,000 managers and was published in a book called "First Break All The Rules". It came up with this surprising finding:
If you're losing good people, look to their manager .... manager is the reason people stay and thrive in an organization. And he 's the reason why people leave. When people leave they take knowledge,experienc e and contacts with them, straight to the competition.
"People leave managers not companies," write the authors Marcus Buckingham and Curt Coffman.
Mostly manager drives people away?
HR experts say that of all the abuses, employees find humiliation the most intolerable. The first time, an employee may not leave,but a thought has been planted. The second time, that thought gets strengthened. The third time, he looks for another job.
When people cannot retort openly in anger, they do so by passive aggression. By digging their heels in and slowing down. By doing only what they are told to do and no more. By omitting to give the boss crucial information. Dev says: "If you work for a jerk, you basically want to get him into trouble. You don 't have your heart and soul in the job."
Different managers can stress out employees in different ways - by being too controlling, too suspicious,too pushy, too critical, but they forget that workers are not fixed assets, they are free agents. When this goes on too long, an employee will quit - often over a trivial issue.
Talented men leave. Dead wood doesn't.
Early this year, Mark, a senior software designer, got an offer from a prestigious international firm to work in its India operations developing specialized software. He was thrilled by the offer.
He had heard a lot about the CEO. The salary was great. The company had all the right systems in place employee-friendly human resources (HR) policies, a spanking new office,and the very best technology,even a canteen that served superb food.
Twice Mark was sent abroad for training. "My learning curve is the sharpest it's ever been," he said soon after he joined.
Last week, less than eight months after he joined, Mark walked out of the job.
Why did this talented employee leave ?
Arun quit for the same reason that drives many good people away.
The answer lies in one of the largest studies undertaken by the Gallup Organization. The study surveyed over a million employees and 80,000 managers and was published in a book called "First Break All The Rules". It came up with this surprising finding:
If you're losing good people, look to their manager .... manager is the reason people stay and thrive in an organization. And he 's the reason why people leave. When people leave they take knowledge,experienc e and contacts with them, straight to the competition.
"People leave managers not companies," write the authors Marcus Buckingham and Curt Coffman.
Mostly manager drives people away?
HR experts say that of all the abuses, employees find humiliation the most intolerable. The first time, an employee may not leave,but a thought has been planted. The second time, that thought gets strengthened. The third time, he looks for another job.
When people cannot retort openly in anger, they do so by passive aggression. By digging their heels in and slowing down. By doing only what they are told to do and no more. By omitting to give the boss crucial information. Dev says: "If you work for a jerk, you basically want to get him into trouble. You don 't have your heart and soul in the job."
Different managers can stress out employees in different ways - by being too controlling, too suspicious,too pushy, too critical, but they forget that workers are not fixed assets, they are free agents. When this goes on too long, an employee will quit - often over a trivial issue.
Talented men leave. Dead wood doesn't.
What worries Me....
What worries me most about the credit crunch is that if one of my cheques is returned stamped "insufficient funds", I won't know whether that refers to mine or the bank's!
Wednesday, September 24, 2008
Changing Good Programmers into Great
Not everybody is cut out to be a programmer. But for those who are, there is no reason you, as a manager or executive, can't help them move from just good to great, amazing and even awesome. Jeff Cogswell shows you how.
During the past two decades, I've worked with some really great programmers and software developers. And, unfortunately, I've worked with more than a few who probably should have chosen a different field. But the vast majority of the programmers fell somewhere in the middle. They were good. Not amazing, but definitely not bad either.
For managers and executives who have programmers and software developers reporting to them, the variation in skill can present quite a problem when you're trying to build a great product. How can you transform the good programmers into fantastic, amazing, awesome programmers?
Believe it or not, you can. Let's see how to do it.
First, you need to make sure your programmers have the essential skills, the fundamentals. Some do; some don't. (Just because they survived an undergrad program in computer science doesn't meant they do.)
Now this is going to sound obvious, but at the very least, every software developer must be a master of writing good lines of code. You've seen those who aren't, the programmers who sit there for hours, staring at 10 lines of code, trying to figure out what's wrong and can't. This kind of thing can happen to all of us programmers occasionally. But the problem is the programmer who does that on a regular basis.
I've worked with these programmers and you've probably had some working for you. They would come to me all the time, interrupting my work, and drag me to their cube to debug their code.
And this is going to sound rough, but the reality is some people just aren't cut out for programming. I'm talking about a very small percentage of people here, fortunately. But they're out there. If you have such a programmer on your staff, it might be time for a meeting with HR and a talk about other opportunities, perhaps in sales, customer support, testing (QA) or some other area of the company. He or she may excel in these areas. But you probably don't want him or her dragging the whole team down.
Fortunately, that's just a small percentage. Let's talk about the huge population that are in the middle, those who are good but not amazing. These are the ones you can help.
In fact, many of them are future experts but are, right now, just younger and less experienced. Such people don't always know about all the issues that can arise in software development. This isn't a problem with their ability; it's really just a problem of inexperience, something they'll overcome with time.
Probably the single biggest issue that younger programmers overlook is the hidden complexity in today's software systems. This is true especially for today's Web-based systems that can serve multiple Web users simultaneously.
In the old days, we would run what was called "stress testing" on our desktop applications. This involved running a program that would put our computer into a low-memory, low-disk-space state, allowing us to see whether our software could function. But with today's multiuser Web sites, the biggest problems aren't so much stress on memory and disk space, since typically the software will be running on large servers with a team of IT people making sure there's plenty of both. Instead, today the problems come more from multiple users trying to do the same thing simultaneously. And that's where the less experienced programmers might fall short in their coding.
Here's an example: Suppose your team is developing an ASP.NET application that will be storing data in an XML file. Ask your team what it takes to write data to the file. If they’re inexperienced, they might express the answer very simply, as in:
· You open the file.
· You write to it.
· You close the file.
Or, you ask them how to read a file:
· You open the file.
· You read the data you need.
· You close the file.
Seems simple and straightforward enough. But it's not. There are actually far more complex issues that can come up, issues that experienced programmers are well aware of but less experienced programmers might overlook, causing major problems when the software is running in a production environment. For example, what if two people are visiting the site simultaneously? Both are entering data into a Web form that needs to be saved. Your server is handling both people at the same time. Remember, the servers can run multiple "threads" at once (that is, the program is running the same parts of the code simultaneously). A separate thread is used to handle each user.
And that's where things get messy. The programmers might have written the code to open the file, read the whole thing into memory and close the file. Then the program would add on the user's new data to the data in memory, and write the whole thing back to the file, effectively replacing the entire file. This is common practice and it works well.
The problem is that if there are two users accessing the system, both threads might open the file, read the data in and close it at roughly the same time. Then simultaneously each thread might modify its own private version of the data. The first thread will write the data to the file and close it. Then the second thread will do the same, perhaps a tiny moment later, overwriting the first thread's version, losing the first user's data.
Or, one thread might open the file for writing, and then the second thread might try to do the same but not be able to (because the operating system locked the file when the first thread opened it), and this thread might not handle the situation appropriately and could crash the whole site, causing error messages to show up in the browsers of all the people visiting the site.
I've seen this kind of thing happen many times. And that's when we programmers get a phone call at 3 in the morning because the operations team couldn't get the software up and running again. And then we have to either connect remotely or drag our butts into the office in the middle of the night, load up on caffeine and track down the problem.
And then we find exactly what the problem is and how to fix it. In our example in particular, it turns out the programmer would have been better off using a set of classes built into the .NET framework that allow for read and write locks on files. These classes are easy to use and take only a couple lines of code. Had the programmer used these, the problem wouldn't have occurred.
As a programmer, I remember seeing such mess-ups in code and complaining to others in the company about it. One tech writer friend of mine laughed and said, "Oh, you guys each have your own way of doing things, and neither is better than the other."
Oh, really? Well there's a good litmus test for determining if the code is right: Does it crash?
Good software doesn't crash. Good software doesn't cause phone calls in the middle of the night where panicked people have to try and figure out why the software crashed.
I've expressed this litmus test before to others, but was met with severe resistance from other programmers. People don't like criticism. But the fact is, perfect software doesn't crash. The reality is that with today's massive systems it's nearly impossible to get every single bug out. But it's certainly within reason to get as many as bugs as possible out, minimizing crashes as much as possible and not using the excuse that "Bugs are inevitable and we should live with them."
And writing code for a Web server that crashes when two users connect to it simultaneously is unacceptable.
Handling things correctly, a manager can teach his or her team to not allow such bugs in the first place, and can oversee the process to prevent such bugs. How can this be done?
First, the team (and the QA folks) must do their job in testing. It's easy to run through a test and see that the program works fine when only one user is accessing the software; it's also easy for you, as the manager, to see that it's working wonderfully and to feel good about it. But it's not so easy to run a real stress test where hundreds or even thousands of threads are running simultaneously, all trying to access and manipulate the data. That's when you'll discover the real problems, the kind that can bring a system to its knees.
To run these kinds of tests requires that you have a QA team of testers who know their tools and know how to simulate such conditions. And further, it's important that the coders are aware of the issues so that by the time their code gets to the QA team, it's already set up to handle high-load situations.
That brings me to the second point: The developers must be trained in how to write code that handles such situations correctly so the system doesn't crash. I said that some bugs will creep in, and as much as I don't want to live with that situation, I suppose I accept it as fact. (And your programmers, by the way, should have a similar attitude, rather than just shrugging and saying bugs are normal. Bugs are unacceptable, and we must stop as many as possible, but occasionally we have to accept that a couple might slip through.)
Thus, at a minimum the programmers must be aware of what can go wrong, and must know how to write code that handles those situations correctly. And that means writing code that is "thread-safe" and is scalable (meaning it can run not only on a single-user basis, but easily and efficiently when hundreds or thousands of people are using it simultaneously, and even when divided up onto multiple servers).
So how do you help the good programmers grow into superior programmers that can write such code?
Early on I somehow stumbled upon something that saved my career many times. I realized that I couldn't possibly know everything. Instead, I realized that a good programmer knows where to quickly find the answers.
Often programmers would come to me for help. And more times than not, I'd say, "Give me 10 minutes and I'll have the answer." Then I'd go back to my cube, quickly look up the answer, and then return. What was I doing? I was going through the same references (Web sites, books, online help) that I'd been through so many times before and finding the answer quickly. So rather than just give up and call someone else for help, I would find the answer myself. Of course, each time I learned the answer, I'd try to remember it, at least in general, so that if it came up again I would either know it or find the answer even more quickly.
Consider the earlier threading example. I mentioned it's on an ASP.NET platform. Off the top of my head, from experience, I know there's a class that allows file locking for read and writes. I can't remember the exact name of the class, but I know that it involves locking and reads and writes. And I know where the standard docs are: the MSDN online documentation or, better yet, the local copy that ships with Visual Studio, the Combined Help Collection. Or, better still, if I remember when I wrote the code before, I could just look at how I did it before. And that means I can immediately locate the name of the class when I need it.
Of course, some really confident programmers want to "roll their own" and build their own locking mechanism, for example, and skip the built-in classes. This could happen for a couple of different reasons. First, the programmers might not even know that there's an alternative to rolling their own. How could they know that there's a handy class built right into the .NET framework that handles the read and write locks? The key is using what I learned so long ago, and knowing the resources and taking a few moments to look through them before rolling your own solution. And that's where you, the manager, can help: You can require that your programmers go through the online docs and find whether the solution already exists.
But the other reason a programmer might want to roll his or her own is because he or she might think the pre-built one isn't good enough. Now remember, I'm not talking about entire systems here that are already built. I'm talking about small, individual functions and classes, the nuts and bolts of your system, such as the file locking mechanism. Remember, programmers like to build things. It's their nature. And they feel especially good if they can build something that was better than the previous one.
But also remember: The class in this case is already built, and takes just a couple of lines of code to use. And it's already been through testing at Microsoft and has been used by thousands of other programmers successfully. You know it works.
Also, programmers have a tendency (myself included) to want to add all sorts of extra features to really make something cool. For example, a file locking mechanism would be even more useful if it included built-in file caching and a queue to manage the locks, and went far and beyond the little one in the library.
But that's overkill. And the last thing you want is for your programmers to spend two weeks, a week or two days writing code when all they need to do is write the one or two lines to make use of the class Microsoft gave us (or whoever built the library you're using for your particular platform). Besides, remember that even though the programmer might be able to roll out his or her own version in a day, your testers will have to now test that code in addition, and what was a day of work could turn into a week or two weeks. Compare that with using one or two lines of code that call a pre-existing, tested class. Which, then, I ask is better? Which is the right way to do it?
Of course, there may be times where the built-in class doesn't do everything you need. In that case, you need to carefully weigh your options and tradeoffs. Is there a way to make use of the class, just without all the extra features you were hoping for? Or is there a way to build a new class that expands on the existing class? (That's usually your best option.) Only if not should you consider having your team writing their own class. But you'll want to make sure you've exhausted your options before going that route. The last thing you want is to find out six months down the road that the thousand lines of code somebody wrote are barely functioning right, and it turns out there was a pre-existing class that did exactly what you needed and would have required three lines of code on the programmer's part.
Conclusion
The moral here, then, is to make sure your programmers are familiar with the information resources, especially the online documents, as well as any existing libraries and frameworks they might have access to that have been tested many times over. Then you need to make sure that they're not rolling their own classes and components when one already exists that does the job. Finally, they need to be aware of the real issues that come up in a multiuser, high-performance system such as a Web server handling thousands or even millions of sessions a day.
During the past two decades, I've worked with some really great programmers and software developers. And, unfortunately, I've worked with more than a few who probably should have chosen a different field. But the vast majority of the programmers fell somewhere in the middle. They were good. Not amazing, but definitely not bad either.
For managers and executives who have programmers and software developers reporting to them, the variation in skill can present quite a problem when you're trying to build a great product. How can you transform the good programmers into fantastic, amazing, awesome programmers?
Believe it or not, you can. Let's see how to do it.
First, you need to make sure your programmers have the essential skills, the fundamentals. Some do; some don't. (Just because they survived an undergrad program in computer science doesn't meant they do.)
Now this is going to sound obvious, but at the very least, every software developer must be a master of writing good lines of code. You've seen those who aren't, the programmers who sit there for hours, staring at 10 lines of code, trying to figure out what's wrong and can't. This kind of thing can happen to all of us programmers occasionally. But the problem is the programmer who does that on a regular basis.
I've worked with these programmers and you've probably had some working for you. They would come to me all the time, interrupting my work, and drag me to their cube to debug their code.
And this is going to sound rough, but the reality is some people just aren't cut out for programming. I'm talking about a very small percentage of people here, fortunately. But they're out there. If you have such a programmer on your staff, it might be time for a meeting with HR and a talk about other opportunities, perhaps in sales, customer support, testing (QA) or some other area of the company. He or she may excel in these areas. But you probably don't want him or her dragging the whole team down.
Fortunately, that's just a small percentage. Let's talk about the huge population that are in the middle, those who are good but not amazing. These are the ones you can help.
In fact, many of them are future experts but are, right now, just younger and less experienced. Such people don't always know about all the issues that can arise in software development. This isn't a problem with their ability; it's really just a problem of inexperience, something they'll overcome with time.
Probably the single biggest issue that younger programmers overlook is the hidden complexity in today's software systems. This is true especially for today's Web-based systems that can serve multiple Web users simultaneously.
In the old days, we would run what was called "stress testing" on our desktop applications. This involved running a program that would put our computer into a low-memory, low-disk-space state, allowing us to see whether our software could function. But with today's multiuser Web sites, the biggest problems aren't so much stress on memory and disk space, since typically the software will be running on large servers with a team of IT people making sure there's plenty of both. Instead, today the problems come more from multiple users trying to do the same thing simultaneously. And that's where the less experienced programmers might fall short in their coding.
Here's an example: Suppose your team is developing an ASP.NET application that will be storing data in an XML file. Ask your team what it takes to write data to the file. If they’re inexperienced, they might express the answer very simply, as in:
· You open the file.
· You write to it.
· You close the file.
Or, you ask them how to read a file:
· You open the file.
· You read the data you need.
· You close the file.
Seems simple and straightforward enough. But it's not. There are actually far more complex issues that can come up, issues that experienced programmers are well aware of but less experienced programmers might overlook, causing major problems when the software is running in a production environment. For example, what if two people are visiting the site simultaneously? Both are entering data into a Web form that needs to be saved. Your server is handling both people at the same time. Remember, the servers can run multiple "threads" at once (that is, the program is running the same parts of the code simultaneously). A separate thread is used to handle each user.
And that's where things get messy. The programmers might have written the code to open the file, read the whole thing into memory and close the file. Then the program would add on the user's new data to the data in memory, and write the whole thing back to the file, effectively replacing the entire file. This is common practice and it works well.
The problem is that if there are two users accessing the system, both threads might open the file, read the data in and close it at roughly the same time. Then simultaneously each thread might modify its own private version of the data. The first thread will write the data to the file and close it. Then the second thread will do the same, perhaps a tiny moment later, overwriting the first thread's version, losing the first user's data.
Or, one thread might open the file for writing, and then the second thread might try to do the same but not be able to (because the operating system locked the file when the first thread opened it), and this thread might not handle the situation appropriately and could crash the whole site, causing error messages to show up in the browsers of all the people visiting the site.
I've seen this kind of thing happen many times. And that's when we programmers get a phone call at 3 in the morning because the operations team couldn't get the software up and running again. And then we have to either connect remotely or drag our butts into the office in the middle of the night, load up on caffeine and track down the problem.
And then we find exactly what the problem is and how to fix it. In our example in particular, it turns out the programmer would have been better off using a set of classes built into the .NET framework that allow for read and write locks on files. These classes are easy to use and take only a couple lines of code. Had the programmer used these, the problem wouldn't have occurred.
As a programmer, I remember seeing such mess-ups in code and complaining to others in the company about it. One tech writer friend of mine laughed and said, "Oh, you guys each have your own way of doing things, and neither is better than the other."
Oh, really? Well there's a good litmus test for determining if the code is right: Does it crash?
Good software doesn't crash. Good software doesn't cause phone calls in the middle of the night where panicked people have to try and figure out why the software crashed.
I've expressed this litmus test before to others, but was met with severe resistance from other programmers. People don't like criticism. But the fact is, perfect software doesn't crash. The reality is that with today's massive systems it's nearly impossible to get every single bug out. But it's certainly within reason to get as many as bugs as possible out, minimizing crashes as much as possible and not using the excuse that "Bugs are inevitable and we should live with them."
And writing code for a Web server that crashes when two users connect to it simultaneously is unacceptable.
Handling things correctly, a manager can teach his or her team to not allow such bugs in the first place, and can oversee the process to prevent such bugs. How can this be done?
First, the team (and the QA folks) must do their job in testing. It's easy to run through a test and see that the program works fine when only one user is accessing the software; it's also easy for you, as the manager, to see that it's working wonderfully and to feel good about it. But it's not so easy to run a real stress test where hundreds or even thousands of threads are running simultaneously, all trying to access and manipulate the data. That's when you'll discover the real problems, the kind that can bring a system to its knees.
To run these kinds of tests requires that you have a QA team of testers who know their tools and know how to simulate such conditions. And further, it's important that the coders are aware of the issues so that by the time their code gets to the QA team, it's already set up to handle high-load situations.
That brings me to the second point: The developers must be trained in how to write code that handles such situations correctly so the system doesn't crash. I said that some bugs will creep in, and as much as I don't want to live with that situation, I suppose I accept it as fact. (And your programmers, by the way, should have a similar attitude, rather than just shrugging and saying bugs are normal. Bugs are unacceptable, and we must stop as many as possible, but occasionally we have to accept that a couple might slip through.)
Thus, at a minimum the programmers must be aware of what can go wrong, and must know how to write code that handles those situations correctly. And that means writing code that is "thread-safe" and is scalable (meaning it can run not only on a single-user basis, but easily and efficiently when hundreds or thousands of people are using it simultaneously, and even when divided up onto multiple servers).
So how do you help the good programmers grow into superior programmers that can write such code?
Early on I somehow stumbled upon something that saved my career many times. I realized that I couldn't possibly know everything. Instead, I realized that a good programmer knows where to quickly find the answers.
Often programmers would come to me for help. And more times than not, I'd say, "Give me 10 minutes and I'll have the answer." Then I'd go back to my cube, quickly look up the answer, and then return. What was I doing? I was going through the same references (Web sites, books, online help) that I'd been through so many times before and finding the answer quickly. So rather than just give up and call someone else for help, I would find the answer myself. Of course, each time I learned the answer, I'd try to remember it, at least in general, so that if it came up again I would either know it or find the answer even more quickly.
Consider the earlier threading example. I mentioned it's on an ASP.NET platform. Off the top of my head, from experience, I know there's a class that allows file locking for read and writes. I can't remember the exact name of the class, but I know that it involves locking and reads and writes. And I know where the standard docs are: the MSDN online documentation or, better yet, the local copy that ships with Visual Studio, the Combined Help Collection. Or, better still, if I remember when I wrote the code before, I could just look at how I did it before. And that means I can immediately locate the name of the class when I need it.
Of course, some really confident programmers want to "roll their own" and build their own locking mechanism, for example, and skip the built-in classes. This could happen for a couple of different reasons. First, the programmers might not even know that there's an alternative to rolling their own. How could they know that there's a handy class built right into the .NET framework that handles the read and write locks? The key is using what I learned so long ago, and knowing the resources and taking a few moments to look through them before rolling your own solution. And that's where you, the manager, can help: You can require that your programmers go through the online docs and find whether the solution already exists.
But the other reason a programmer might want to roll his or her own is because he or she might think the pre-built one isn't good enough. Now remember, I'm not talking about entire systems here that are already built. I'm talking about small, individual functions and classes, the nuts and bolts of your system, such as the file locking mechanism. Remember, programmers like to build things. It's their nature. And they feel especially good if they can build something that was better than the previous one.
But also remember: The class in this case is already built, and takes just a couple of lines of code to use. And it's already been through testing at Microsoft and has been used by thousands of other programmers successfully. You know it works.
Also, programmers have a tendency (myself included) to want to add all sorts of extra features to really make something cool. For example, a file locking mechanism would be even more useful if it included built-in file caching and a queue to manage the locks, and went far and beyond the little one in the library.
But that's overkill. And the last thing you want is for your programmers to spend two weeks, a week or two days writing code when all they need to do is write the one or two lines to make use of the class Microsoft gave us (or whoever built the library you're using for your particular platform). Besides, remember that even though the programmer might be able to roll out his or her own version in a day, your testers will have to now test that code in addition, and what was a day of work could turn into a week or two weeks. Compare that with using one or two lines of code that call a pre-existing, tested class. Which, then, I ask is better? Which is the right way to do it?
Of course, there may be times where the built-in class doesn't do everything you need. In that case, you need to carefully weigh your options and tradeoffs. Is there a way to make use of the class, just without all the extra features you were hoping for? Or is there a way to build a new class that expands on the existing class? (That's usually your best option.) Only if not should you consider having your team writing their own class. But you'll want to make sure you've exhausted your options before going that route. The last thing you want is to find out six months down the road that the thousand lines of code somebody wrote are barely functioning right, and it turns out there was a pre-existing class that did exactly what you needed and would have required three lines of code on the programmer's part.
Conclusion
The moral here, then, is to make sure your programmers are familiar with the information resources, especially the online documents, as well as any existing libraries and frameworks they might have access to that have been tested many times over. Then you need to make sure that they're not rolling their own classes and components when one already exists that does the job. Finally, they need to be aware of the real issues that come up in a multiuser, high-performance system such as a Web server handling thousands or even millions of sessions a day.
19th Sep, 2008
19th Sep, 2008:
A bad day... in my life.
There is a bad story associated to it and I will write that some other time... I just wanted to make a note of it so that I dont forget it...
A bad day... in my life.
There is a bad story associated to it and I will write that some other time... I just wanted to make a note of it so that I dont forget it...
Sunday, September 21, 2008
Building Effective Corporate Cultures One Decency at a Time
Building Effective Corporate Cultures One Decency at a Time
By making decency a habit, leaders can surreptitiously and effectively protect a corporate culture—not just the experience of work, but also the company's moral underpinning.
By Steve Harrison
June 11, 2007 — CIO —
The most basic decencies are those that demonstrate respect and consideration. A simple "hello" at the start of the day and "goodbye" at the end of the day are obvious but sometimes overlooked forms of consideration. Remembering the names of the people you work with regularly is equally as important as saying hello. Beyond these basics, here are some other ways to demonstrate respect and consideration.
Protect the Dignity of OthersWe choose whether we are going to build people up or diminish them. This choice is very poignant especially during a downsizing. It's up to those of us at the top to protect the dignity of each and every person who has to be separated. Sometimes, the choices are much less public, but no less telling. Think about how much information you have about people in your organization. Resist the temptation to gossip or break confidences.
Don't Keep People WaitingEarly in my career, I thought that letting the salespeople calling on me "cool their heels" was acceptable. I was the customer, after all. A thoughtful supervisor set me straight. Since that correction, I have never consciously kept a visitor, including a salesperson, waiting. Receiving people promptly is a decency that counts because it is courteous and respectful.
Make Meetings DecentFor meetings you call, be the first to arrive and the last to leave. Leave the Blackberry behind. Rearrange seating to assure that everyone is included and groups are not set in opposition. Take time for introductions. Make space for quiet colleagues to offer their opinions. Finish on time or, for greatest effect, finish early.
Recognition DecenciesThe Golden Rule, "Do unto others as you would have others do unto you," is a valuable guideline in life, but when it comes to recognizing employees, I suggest applying the Platinum Rule: Do unto others as they would have you do unto them. Outside of formal recognition and reward programs, here are some well-received ways to recognize people day after day.
· Say "thank you." Hardly anyone will dispute the value of saying thank you, but in many work places, the rush of deadlines crowds out appreciation. It's best to offer thanks personally and in front of peers. "Thank you" means even more when the thought is delivered in writing. While it's tempting to send off an e-mail instead of taking the time to find a note card and address an envelope, it will mean a lot more on paper.
· Little things mean a lot. Bring in coffee, donuts and snacks to share on an unpredictable basis. Or order a pizza or a huge submarine sandwich for a communal lunch. Don't make a big deal of it, but just say it's a token of how much you appreciate how hard everyone is working.
· Appoint a proxy. Invite a subordinate to represent you at conferences or meetings. If you select carefully, the associate will get a psychic kick out of representing you. He or she will feel your trust. Later, the employee can share insights gained with team members, giving a second boost of recognition.
Listening DecenciesNext to physical survival, the greatest need of a human being is to be acknowledged. "Attention must be paid!" says Willy Loman in Death of a Salesman. Everyone yearns to be understood, to be affirmed, to be validated and to be appreciated. Being listened to is the prerequisite for all of these. Most of us pay little attention to the quality of our listening. Especially in business situations, we are too busy thinking about what we call "the big picture" to notice that big pictures are the sum of personal moments of truth. Here are some ways you can practice listening decencies.
· Talk less. It's really that easy . . . and that hard. Listening starts when we stop talking. Some tricks to change the balance are:
· Stop talking after 60 seconds and give the other person a chance to chime in;
· Resist the temptation to interrupt—even if it's to agree with the person talking. When you do, you are inadvertently making the conversation about you;
· Value silence as a chance for the other person to gather their thoughts.
· Voice questions, not opinions or decisions. As a leader, stating your opinion can immediately shut down the conversation. To get the most of your diverse team, ask open-ended questions, or say, "I wonder what would happen if . . ." Then be quiet, and listen. Hold back from judgment, from expressing objections and from giving advice.
· Don't multitask. We all need to be efficient. But you can't truly listen to someone and do anything else at the same time. Try focusing on listening for just 10 minutes. You'll learn more and make the other person feel more valued.
Executive Humility DecenciesI first heard the term executive pomposity decades ago, and I have come to believe that a sense of entitlement bred from authority is by far the most corrosive agent in organizations. All this attitude does is distance executives from their colleagues and customers, and, ultimately, from their business. As much as it might inflate executive egos, pomposity deflates others around them. You'll do both yourself and your organization a favor by avoiding anything that smacks of RHIP, or "rank has its privileges," like exclusive dining rooms or parking places. Some other decencies you can practice are:
· Share the credit, hoard the blame. When things go well, share the credit. When things go badly, be known as someone who is accountable. There will be time to sort out the problem and learn from it later. Be known as someone whose first instinct is to fix the problem rather than affix the blame.
· If you make a mistake, apologize. Far from diminishing your importance, an apology demonstrates humility, respect for others and a desire to learn, all of which are traits of strong leaders. Refusing to apologize after having made a mistake demonstrates pomposity of the worst kind. Saying "I'm sorry" effectively is one of the most powerful small decencies available to any leader. Good apologies deliver the "4 Rs:"
· Recognition of the mistake
· Responsibility for the error
· Remorse expressed
· Restitution offered
· Make yourself accessible. In his book The Transparent Leader, former Dial Corporation CEO Herb Baum says, "The road to transparency is itself an open one. . . I stress actual physical accessibility as a tool to develop our culture." One way he became accessible was through a program called "Hotdogs with Herb." He describes this as "a fun, casual lunch where I get to spend quality time with a small group of employees . . . It allows them to get to know me, and gives me a chance to get to know them and listen to their concerns or feedback . . . We always have hotdogs—my favorite dish." Former New York City mayor Ed Koch was known for asking city employees, "How am I doing?" and really being open to the answer. In the end, accessibility is not just about being available, it's about being open to input as well.
· Ripples in a PondPeople will perk up when you offer a decency. Employees like to work in a place where consideration and respect are palpable and leaders listen with humility. And I think they like to use a leader's example as permission to make the extra effort to act with decency themselves. That's how one leader's commitment to decency emanates throughout a company like ripples in a pond. It's quiet. It may take a little while. But it will bring about a change that is deeply rooted within individual behavior, and that's the best foundation of all.
· Steve Harrison is chairman of Lee Hecht Harrison, a global leader in career management solutions based in Woodcliff Lake, NJ. This article is drawn from his new book, The Manager's Book of Decencies: How Small Gestures Build Great Companies (McGraw-Hill, 2007). Harrison welcomes examples of decencies and gives a free book each month to the person submitting the most powerful example of a business decency. For more on the book or to submit your decencies, visit http://www.bookofdecencies.com.
· © 2008 CXO Media Inc.
By making decency a habit, leaders can surreptitiously and effectively protect a corporate culture—not just the experience of work, but also the company's moral underpinning.
By Steve Harrison
June 11, 2007 — CIO —
The most basic decencies are those that demonstrate respect and consideration. A simple "hello" at the start of the day and "goodbye" at the end of the day are obvious but sometimes overlooked forms of consideration. Remembering the names of the people you work with regularly is equally as important as saying hello. Beyond these basics, here are some other ways to demonstrate respect and consideration.
Protect the Dignity of OthersWe choose whether we are going to build people up or diminish them. This choice is very poignant especially during a downsizing. It's up to those of us at the top to protect the dignity of each and every person who has to be separated. Sometimes, the choices are much less public, but no less telling. Think about how much information you have about people in your organization. Resist the temptation to gossip or break confidences.
Don't Keep People WaitingEarly in my career, I thought that letting the salespeople calling on me "cool their heels" was acceptable. I was the customer, after all. A thoughtful supervisor set me straight. Since that correction, I have never consciously kept a visitor, including a salesperson, waiting. Receiving people promptly is a decency that counts because it is courteous and respectful.
Make Meetings DecentFor meetings you call, be the first to arrive and the last to leave. Leave the Blackberry behind. Rearrange seating to assure that everyone is included and groups are not set in opposition. Take time for introductions. Make space for quiet colleagues to offer their opinions. Finish on time or, for greatest effect, finish early.
Recognition DecenciesThe Golden Rule, "Do unto others as you would have others do unto you," is a valuable guideline in life, but when it comes to recognizing employees, I suggest applying the Platinum Rule: Do unto others as they would have you do unto them. Outside of formal recognition and reward programs, here are some well-received ways to recognize people day after day.
· Say "thank you." Hardly anyone will dispute the value of saying thank you, but in many work places, the rush of deadlines crowds out appreciation. It's best to offer thanks personally and in front of peers. "Thank you" means even more when the thought is delivered in writing. While it's tempting to send off an e-mail instead of taking the time to find a note card and address an envelope, it will mean a lot more on paper.
· Little things mean a lot. Bring in coffee, donuts and snacks to share on an unpredictable basis. Or order a pizza or a huge submarine sandwich for a communal lunch. Don't make a big deal of it, but just say it's a token of how much you appreciate how hard everyone is working.
· Appoint a proxy. Invite a subordinate to represent you at conferences or meetings. If you select carefully, the associate will get a psychic kick out of representing you. He or she will feel your trust. Later, the employee can share insights gained with team members, giving a second boost of recognition.
Listening DecenciesNext to physical survival, the greatest need of a human being is to be acknowledged. "Attention must be paid!" says Willy Loman in Death of a Salesman. Everyone yearns to be understood, to be affirmed, to be validated and to be appreciated. Being listened to is the prerequisite for all of these. Most of us pay little attention to the quality of our listening. Especially in business situations, we are too busy thinking about what we call "the big picture" to notice that big pictures are the sum of personal moments of truth. Here are some ways you can practice listening decencies.
· Talk less. It's really that easy . . . and that hard. Listening starts when we stop talking. Some tricks to change the balance are:
· Stop talking after 60 seconds and give the other person a chance to chime in;
· Resist the temptation to interrupt—even if it's to agree with the person talking. When you do, you are inadvertently making the conversation about you;
· Value silence as a chance for the other person to gather their thoughts.
· Voice questions, not opinions or decisions. As a leader, stating your opinion can immediately shut down the conversation. To get the most of your diverse team, ask open-ended questions, or say, "I wonder what would happen if . . ." Then be quiet, and listen. Hold back from judgment, from expressing objections and from giving advice.
· Don't multitask. We all need to be efficient. But you can't truly listen to someone and do anything else at the same time. Try focusing on listening for just 10 minutes. You'll learn more and make the other person feel more valued.
Executive Humility DecenciesI first heard the term executive pomposity decades ago, and I have come to believe that a sense of entitlement bred from authority is by far the most corrosive agent in organizations. All this attitude does is distance executives from their colleagues and customers, and, ultimately, from their business. As much as it might inflate executive egos, pomposity deflates others around them. You'll do both yourself and your organization a favor by avoiding anything that smacks of RHIP, or "rank has its privileges," like exclusive dining rooms or parking places. Some other decencies you can practice are:
· Share the credit, hoard the blame. When things go well, share the credit. When things go badly, be known as someone who is accountable. There will be time to sort out the problem and learn from it later. Be known as someone whose first instinct is to fix the problem rather than affix the blame.
· If you make a mistake, apologize. Far from diminishing your importance, an apology demonstrates humility, respect for others and a desire to learn, all of which are traits of strong leaders. Refusing to apologize after having made a mistake demonstrates pomposity of the worst kind. Saying "I'm sorry" effectively is one of the most powerful small decencies available to any leader. Good apologies deliver the "4 Rs:"
· Recognition of the mistake
· Responsibility for the error
· Remorse expressed
· Restitution offered
· Make yourself accessible. In his book The Transparent Leader, former Dial Corporation CEO Herb Baum says, "The road to transparency is itself an open one. . . I stress actual physical accessibility as a tool to develop our culture." One way he became accessible was through a program called "Hotdogs with Herb." He describes this as "a fun, casual lunch where I get to spend quality time with a small group of employees . . . It allows them to get to know me, and gives me a chance to get to know them and listen to their concerns or feedback . . . We always have hotdogs—my favorite dish." Former New York City mayor Ed Koch was known for asking city employees, "How am I doing?" and really being open to the answer. In the end, accessibility is not just about being available, it's about being open to input as well.
· Ripples in a PondPeople will perk up when you offer a decency. Employees like to work in a place where consideration and respect are palpable and leaders listen with humility. And I think they like to use a leader's example as permission to make the extra effort to act with decency themselves. That's how one leader's commitment to decency emanates throughout a company like ripples in a pond. It's quiet. It may take a little while. But it will bring about a change that is deeply rooted within individual behavior, and that's the best foundation of all.
· Steve Harrison is chairman of Lee Hecht Harrison, a global leader in career management solutions based in Woodcliff Lake, NJ. This article is drawn from his new book, The Manager's Book of Decencies: How Small Gestures Build Great Companies (McGraw-Hill, 2007). Harrison welcomes examples of decencies and gives a free book each month to the person submitting the most powerful example of a business decency. For more on the book or to submit your decencies, visit http://www.bookofdecencies.com.
· © 2008 CXO Media Inc.
read it... only....If you're a nice person
From: www.cio.com
The Danger of Being Too Nice at Work – Meridith Levinson, CIO
September 18, 2008
If you're a nice person, you probably think that being nice works to your advantage in the office. After all, how could it be any other way? Genuinely nice people are well liked. They're generally easy to work with. They care about others and tend to have good values. In a fair and just world, that sort of behavior should be rewarded. Right?
Not necessarily. Too often, nice, competent people get passed up for promotions. Instead, the plum job goes to the prima donna or the person who plays politics. The bonus is bestowed upon the squeaky wheel or the obnoxious go-getter. In this environment, the nice guy really does finish last. It's frustrating because it goes against everything we were taught as a children about the Golden Rule.
RELATED STORIESHow to Make Nice Playing Nice in the IT Sandbox CIOs Need to be Tough Yet Empathetic How to Make a Tough Decision What nice people may not realize is that they're too nice, and that being too nice can seriously stymie their career growth and success, says Russ Edelman, a SharePoint consultant and co-author of the book, Nice Guys Can Get the Corner Office: Eight Strategies for Winning in Business Without Being a Jerk (Portfolio, 2008.) "The people in business who suffer from nice guy syndrome are not achieving their true potential," he says.
The problem with being too nice, according to Edelman—who comes off as a very nice guy—is that you're a doormat and people take advantage of you. Nice people are too concerned about pleasing others and not making waves that they don't stand up for themselves.
Edelman cites a nice man he interviewed for his book, who was vying for an executive position. The nice man was well-respected and well-liked in his company, and had a very good shot at the job. Of course, someone else was competing for the position. When the nice man was asked in an interview about his competitor, according to Edelman the nice guy said he thought his competitor would do a fantastic job. The nice contender wound up writing a letter of recommendation for his competitor because he didn't want to cause a stir by vying for the executive-level job, says Edelman. End result: The competitor got the job, and the nice guy remained in his spot on the corporate ladder.
"The nice guy is forever putting the oxygen mask on someone else before putting it on himself," says Edelman.
The Cost of Nice in BusinessBeing too nice is not just a problem for individuals. It's a problem for businesses, too. Employees who are too nice cost businesses time and money.
In a survey of 50 CEOs, Edelman asked about the impact of "being too nice" on their businesses. The CEOs responded by saying that being too nice cost them eight percent of their gross revenues. In other words, if the CEOs' companies had been more aggressive, they believed they could have earned more money.
Edelman notes that managers who are too nice are reluctant to make decisions on their own. They fear hurting the feelings of anyone whom they don't ask for feedback, so they include everyone in their decision-making. That wastes time and can lead to missed opportunities.
"The overly nice guy usually defers to others. They're reluctant to create losers," says Edelman. The irony is that in the process of trying to make everyone a winner, the nice guy ends up the loser.
Managers who are too nice also avoid confrontation, says Edelman. They'd rather ignore problems than address them head on. Of course, ignoring problems only makes them worse, and burying one's head in the sand does not inspire the confidence of the manager's team or of his superiors, adds Edelman. It only inspires their ire.
"If you appease everyone, if you fear hurting people's feelings, you do a disserve to whatever project you're working on, to yourself and your business," says Edelman. "That's where being too nice is not nice at all."
Advice for People Who Are Too NiceSofties need to toughen up, says Edelman. "I'm not advocating that people become jerks or SOBs," he says, "But they need to find a balance to stay true to their nice nature while also being appropriately assertive and protecting their interests."
The challenge, then, for nice people is to redefine what it means to be nice, says Edelman, and to understand that being nice doesn't have to mean being a doormat. You can be nice and be assertive and deal with confrontation and set boundaries, he adds.
Here are three concepts nice people need to understand to succeed at work:
1. Business is competitive. Deal with it. Edelman interviewed Sam DiPiazza Jr., the CEO of PricewaterhouseCoopers, for his book. DiPiazza had this to say about business, according to Edelman: "Business, whether we like it or not, includes competition. It's challenging, aggressive and very demanding. Despite the perception of many, it can also be performed nicely."
2. Sometimes being nice isn't very nice at all.Edelman also spoke with the CEO of the American Cancer Society, John Seffrin, who believes that when mangers are too nice and are incapable of having honest discussions with others (such as during a performance review) for fear of hurting feelings, they're in fact not being nice at all and they're doing a disservice to the people they manage.
3. Confrontation is not necessarily a bad thing. Nice people avoid confrontation because it's uncomfortable, says Edelman. If nice people are to be more assertive, they need to understand the business value of confrontation: it allows them to solve problems. Edelman points to a strategy employed by 1-800-GOT-JUNK CEO Brian Scudamore, which Scudamore calls "race to the conflict." The idea is, if a conflict or issue comes up, employees should race to it to get it resolved as quickly as possible. If they don't, they're wasting time.
© 2008 CXO Media Inc.
The Danger of Being Too Nice at Work – Meridith Levinson, CIO
September 18, 2008
If you're a nice person, you probably think that being nice works to your advantage in the office. After all, how could it be any other way? Genuinely nice people are well liked. They're generally easy to work with. They care about others and tend to have good values. In a fair and just world, that sort of behavior should be rewarded. Right?
Not necessarily. Too often, nice, competent people get passed up for promotions. Instead, the plum job goes to the prima donna or the person who plays politics. The bonus is bestowed upon the squeaky wheel or the obnoxious go-getter. In this environment, the nice guy really does finish last. It's frustrating because it goes against everything we were taught as a children about the Golden Rule.
RELATED STORIESHow to Make Nice Playing Nice in the IT Sandbox CIOs Need to be Tough Yet Empathetic How to Make a Tough Decision What nice people may not realize is that they're too nice, and that being too nice can seriously stymie their career growth and success, says Russ Edelman, a SharePoint consultant and co-author of the book, Nice Guys Can Get the Corner Office: Eight Strategies for Winning in Business Without Being a Jerk (Portfolio, 2008.) "The people in business who suffer from nice guy syndrome are not achieving their true potential," he says.
The problem with being too nice, according to Edelman—who comes off as a very nice guy—is that you're a doormat and people take advantage of you. Nice people are too concerned about pleasing others and not making waves that they don't stand up for themselves.
Edelman cites a nice man he interviewed for his book, who was vying for an executive position. The nice man was well-respected and well-liked in his company, and had a very good shot at the job. Of course, someone else was competing for the position. When the nice man was asked in an interview about his competitor, according to Edelman the nice guy said he thought his competitor would do a fantastic job. The nice contender wound up writing a letter of recommendation for his competitor because he didn't want to cause a stir by vying for the executive-level job, says Edelman. End result: The competitor got the job, and the nice guy remained in his spot on the corporate ladder.
"The nice guy is forever putting the oxygen mask on someone else before putting it on himself," says Edelman.
The Cost of Nice in BusinessBeing too nice is not just a problem for individuals. It's a problem for businesses, too. Employees who are too nice cost businesses time and money.
In a survey of 50 CEOs, Edelman asked about the impact of "being too nice" on their businesses. The CEOs responded by saying that being too nice cost them eight percent of their gross revenues. In other words, if the CEOs' companies had been more aggressive, they believed they could have earned more money.
Edelman notes that managers who are too nice are reluctant to make decisions on their own. They fear hurting the feelings of anyone whom they don't ask for feedback, so they include everyone in their decision-making. That wastes time and can lead to missed opportunities.
"The overly nice guy usually defers to others. They're reluctant to create losers," says Edelman. The irony is that in the process of trying to make everyone a winner, the nice guy ends up the loser.
Managers who are too nice also avoid confrontation, says Edelman. They'd rather ignore problems than address them head on. Of course, ignoring problems only makes them worse, and burying one's head in the sand does not inspire the confidence of the manager's team or of his superiors, adds Edelman. It only inspires their ire.
"If you appease everyone, if you fear hurting people's feelings, you do a disserve to whatever project you're working on, to yourself and your business," says Edelman. "That's where being too nice is not nice at all."
Advice for People Who Are Too NiceSofties need to toughen up, says Edelman. "I'm not advocating that people become jerks or SOBs," he says, "But they need to find a balance to stay true to their nice nature while also being appropriately assertive and protecting their interests."
The challenge, then, for nice people is to redefine what it means to be nice, says Edelman, and to understand that being nice doesn't have to mean being a doormat. You can be nice and be assertive and deal with confrontation and set boundaries, he adds.
Here are three concepts nice people need to understand to succeed at work:
1. Business is competitive. Deal with it. Edelman interviewed Sam DiPiazza Jr., the CEO of PricewaterhouseCoopers, for his book. DiPiazza had this to say about business, according to Edelman: "Business, whether we like it or not, includes competition. It's challenging, aggressive and very demanding. Despite the perception of many, it can also be performed nicely."
2. Sometimes being nice isn't very nice at all.Edelman also spoke with the CEO of the American Cancer Society, John Seffrin, who believes that when mangers are too nice and are incapable of having honest discussions with others (such as during a performance review) for fear of hurting feelings, they're in fact not being nice at all and they're doing a disservice to the people they manage.
3. Confrontation is not necessarily a bad thing. Nice people avoid confrontation because it's uncomfortable, says Edelman. If nice people are to be more assertive, they need to understand the business value of confrontation: it allows them to solve problems. Edelman points to a strategy employed by 1-800-GOT-JUNK CEO Brian Scudamore, which Scudamore calls "race to the conflict." The idea is, if a conflict or issue comes up, employees should race to it to get it resolved as quickly as possible. If they don't, they're wasting time.
© 2008 CXO Media Inc.
Wednesday, September 10, 2008
Microsoft joins OMG
Company pushes software modeling initiatives and plans to assist with the evolution of standards
By Paul Krill, IDG News Service
September 10, 2008
As part of its strategy for model-driven software development, Microsoft on Wednesday announced it has joined the Object Management Group (OMG).
OMG standards have included UML (Unified Modeling Language) and BPMN (Business Process Modeling Notation). Microsoft plans to take an active role in OMG working groups and contribute to an industry dialogue and assist with the evolution of standards, the company said. Microsoft is now working with the OMG finance working group on information models for insurance business functions related to the property and casualty industry.
"We think OMG is important to help contribute to the open industry dialogue. Modeling has been something that has really been viewed as sort of a niche," said Burley Kawaski, director of product management for the Microsoft Connected Systems Division.
Microsoft, meanwhile, has been developing its own modeling initiatives, including Oslo, for model-driven software development, and its Visual Studio Rosario release.
The company has not been a supporter of UML, instead deferring to third parties to provide plug-ins offering UML support to developers. But with Rosario, the company will add support for UML 2.1.1. "For certain communities, the UML support is very important," Kawasaki said. Microsoft currently has no target release date for Rosario but previously has offered up late-2008 as an estimate.
Modeling has been viewed as a means to break down technology and role silos in application development and assist IT departments with offering more effective business strategies, Microsoft said. But modeling has failed to have a mainstream impact on how organizations develop and manage core applications, the company said.
"Many people have tried modeling many times and failed," said Kawasaki. "We think there is a much broader use of modeling that has much greater potential."
The company believes models must evolve to be more than static diagrams defining a software system. Implementing models as part of the design, deployment and management process would give organizations a deeper way to define and communicate aspects involved in the application lifecycle.
Putting model-driven development into Microsoft's .Net platform will provide organizations with visibility and control over applications, according to Microsoft.
Microsoft views model-driven technologies as a main pillar of its "Dynamic IT" vision for aligning business and IT. Other pillars include service enablement, virtualization, and the user experience.
In addition to UML backing, Microsoft plans to support BPMN in Oslo and its Visio drawing and modeling tool.
Wednesday, February 20, 2008
Internal Coding Guidelines
Table of Contents
1. Introduction 1
2. Style Guidelines 2
2.1 Tabs &
Indenting 2
2.2 Bracing 2
2.3 Commenting 2
2.3.1 Documentation Comments... 2
2.3.2 Comment Style............ 3
2.4 Spacing 3
2.5 Naming 4
2.6 Naming
Conventions 4
2.6.1 Interop Classes........ 4
2.7 File
Organization 5
1. Introduction
First, read the .NET Framework Design
Guidelines. Almost all naming conventions, casing rules, etc., are spelled out
in this document. Unlike the Design Guidelines document, you should treat this
document as a set of suggested guidelines. These generally do not effect the customer
view so they are not required.
2. Style Guidelines
2.1 Tabs & Indenting
Tab characters (\0x09) should not be used
in code. All indentation should be done with 4 space characters.
2.2 Bracing
Open braces should always be at the
beginning of the line after the statement that begins the block. Contents of
the brace should be indented by 4 spaces. For example:
if (someExpression)
{
DoSomething();
}
else
{
DoSomethingElse();
}
“case” statements should be indented from
the switch statement like this:
switch
(someExpression)
{
case 0:
DoSomething();
break;
case 1:
DoSomethingElse();
break;
case 2:
{
int n = 1;
DoAnotherThing(n);
}
break;
}
Braces should never be considered
optional. Even for single statement blocks, you should always use braces. This
increases code readability and maintainability.
for (int i=0;
i<100; i++) { DoSomething(i); }
2.3 Single line statements
Single line statements can have braces
that begin and end on the same line.
public class Foo
{
int bar;
public int Bar
{
get { return bar; }
set { bar = value; }
}
}
It is suggested
that all control structures (if, while, for, etc.) use braces, but it is not
required.
2.4 Commenting
Comments should be used to describe
intention, algorithmic overview, and/or logical flow. It would be ideal, if from reading the comments alone, someone
other than the author could understand a function’s intended behavior and
general operation. While there are no minimum comment requirements and
certainly some very small routines need no commenting at all, it is hoped that
most routines will have comments reflecting the programmer’s intent and
approach.
2.4.1 Copyright notice
Each file should start with a copyright
notice. To avoid errors in doc comment builds, you don’t want to use
triple-slash doc comments, but using XML makes the comments easy to replace in
the future. Final text will vary by product (you should contact legal for the
exact text), but should be similar to:
//-----------------------------------------------------------------------
// <copyright file="ContainerControl.cs"
company="Microsoft">
// Copyright (c) Microsoft
Corporation. All rights reserved.
// </copyright>
//-----------------------------------------------------------------------
2.4.2 Documentation Comments
All methods should use XML doc comments.
For internal dev comments, the <devdoc> tag should be used.
public class Foo
{
/// <summary>Public stuff about the method</summary>
/// <param name=”bar”>What a neat parameter!</param>
/// <devdoc>Cool internal stuff!</devdoc>
///
public void MyMethod(int bar) { … }
}
However, it is common that you would want
to move the XML documentation to an external file – for that, use the
<include> tag.
public class Foo
{
/// <include file='doc\Foo.uex'
path='docs/doc[@for="Foo.MyMethod"]/*' />
///
public void MyMethod(int bar)
{ … }
}
UNDONE§ there is a big doc with all the
comment tags we should be using… where is that?
2.4.3 Comment Style
The // (two slashes)
style of comment tags should be used in most situations. Where ever possible, place comments above the code
instead of beside it. Here are some examples:
// This is required for WebClient to work through the proxy
GlobalProxySelection.Select = new
WebProxy("http://itgproxy");
// Create object to access Internet resources
//
WebClient myClient = new WebClient();
Comments can be placed at the end of a
line when space allows:
public class SomethingUseful
{
private
int itemHash; // instance member
private
static bool hasDoneSomething; // static member
}
2.5 Spacing
Spaces improve readability by decreasing
code density. Here are some guidelines for the use of space characters within
code:
- Do use a single space after a comma between function arguments.
Right: Console.In.Read(myChar, 0, 1);
Wrong: Console.In.Read(myChar,0,1); - Do not use a space after the parenthesis and
function arguments
Right: CreateFoo(myChar, 0, 1)
Wrong: CreateFoo( myChar, 0, 1 ) - Do not use spaces between a function name and
parenthesis.
Right: CreateFoo()
Wrong: CreateFoo () - Do not use spaces inside brackets.
Right: x = dataArray[index];
Wrong: x = dataArray[ index ]; - Do use a single space before flow control statements
Right: while (x == y)
Wrong: while(x==y) - Do use a single space before and after comparison operators
Right: if (x == y)
Wrong: if (x==y)
2.6 Naming
Follow all .NET Framework Design
Guidelines for both internal and external members. Highlights of these include:
- Do not use Hungarian notation
- Do not use a prefix for member variables
(_, m_, s_, etc.). If you want to distinguish between local and member
variables you should use “this.” in C# and “
in VB.NET. - Do use camelCasing for member variables
- Do use camelCasing for parameters
- Do use camelCasing for local variables
- Do use PascalCasing for function,
property, event, and class names - Do prefix interfaces names with “I”
- Do not prefix enums, classes, or delegates
with any letter
The reasons to extend the public rules (no
Hungarian, no prefix for member variables, etc.) is to produce a consistent
source code appearance. In addition a goal is to have clean readable source.
Code legibility should be a primary goal.
2.7 Naming Conventions
2.7.1 Interop Classes
Classes that are there for interop
wrappers (DllImport statements) should follow the naming convention below:
- NativeMethods – No suppress unmanaged code
attribute, these are methods that can be used anywhere because a stack
walk will be performed. - UnsafeNativeMethods – Has suppress unmanaged code
attribute. These methods are potentially dangerous and any caller of these methods must do a
full security review to ensure that the usage is safe and protected as no
stack walk will be performed. - SafeNativeMethods – Has suppress unmanaged code
attribute. These methods are safe and can be used fairly safely and the
caller isn’t needed to do full security reviews even though no stack walk
will be performed.
class NativeMethods
{
private NativeMethods() {}
[DllImport(“user32”)]
internal static extern void
FormatHardDrive(string driveName);
}
[SuppressUnmanagedCode]
class UnsafeNativeMethods
{
private UnsafeNativeMethods()
{}
[DllImport(“user32”)]
internal static extern void
CreateFile(string fileName);
}
[SuppressUnmanagedCode]
class SafeNativeMethods
{
private SafeNativeMethods() {}
[DllImport(“user32”)]
internal static extern void
MessageBox(string text);
}
All interop classes must be private, and all methods must be internal. In addition a private constructor should be provided to
prevent instantiation.
2.8 File Organization
- Source files should contain only one public
type, although multiple internal classes are allowed - Source files should be given the name of the
public class in the file - Directory names should follow the namespace
for the class
For example, I would expect to find the
public class “System.Windows.Forms.Control” in
“System\Windows\Forms\Control.cs”…
- Classes member should be alphabetized, and grouped into sections (Fields, Constructors,
Properties, Events, Methods, Private interface implementations, Nested
types) - Using statements should be inside the
namespace declaration.
namespace MyNamespace
{
using System;
public class MyClass : IFoo
{
//
fields
int foo;
//
constructors
public MyClass() { … }
//
properties
public int Foo { get { … } set { … } }
//
events
public event EventHandler FooChanged { add { … } remove {
… } }
//
methods
void DoSomething() { … }
void FindSomethind() { … }
//private interface implementations
void IFoo.DoSomething() {
DoSomething(); }
// nested types
class NestedType { … }
}
}
Subscribe to:
Comments (Atom)
