• Sometimes when I reflect back on all the ciggarettes I smoked, I feel ashamed. Then I look into the ciggarette & think about the workers in the ciggarette factory & all of their hopes & dreams. If I don't smoke this ciggarette, they might be out of work & their dreams would be shattered, Then I say to myself, it's better that I smoke this ciggarette & let their dreams come true then be selfish & worry about my LUNGS.
------
• Several women appeared in court, each accusing the other of the trouble in the flat where they lived. The judge called for orderly testimony. "I'll hear the oldest first," he decreed. The case was closed for lack of evidence.
------
• My wife thinks "freedom of the press" means no-iron clothes.
------
• When the best actors are chosen by other actors, it's called the Oscars. When the best actors are chosen by the people, it's called an election.
------
• A husband, the owner of a new car, was somewhat reluctant to allow his wife to drove his prize possession.. .even to the grocery store which was a few blocks from the house.
After she insisted, he finally relented, cautioning her as she departed, "Remember, if you have an accident, the newspaper will print your age!"
------
• "Take a pencil and paper," the teacher said, "and write an essay with the title 'If I Were a Millionaire'"
Everyone but Philip, who leaned back with arms folded, began to write furiously.
"What's the matter," the teacher asked. "Why don't you begin?"
"I'm waiting for my secretary," he replied.
------
• Q: What's the difference between a good lawyer and a great lawyer?
A: A good lawyer knows the law. A great lawyer knows the judge.
------
• Nurse: A beautiful woman who holds your hand for one full minute and then expects your pulse to be normal
------
• A French in a hotel in NY, phoned room service for some pepper.
Attendant: Black pepper or white pepper?
French: Toilette pepper!
Friday, November 07, 2008
DO MEN REMEMBER ANNIVERSARIES?
DO MEN REMEMBER ANNIVERSARIES?
DO MEN REMEMBER ANNIVERSARIES?
A woman awakes during the night to find that her husband was not in their bed.
She puts on her dressing gown and goes downstairs to look for him.
She finds him sitting at the kitchen table with a hot cup of coffee in front of him. He appears to be in deep thought, just staring at the wall.
She watches as he wipes a tear from his eye and takes a sip of his coffee.
'What's the matter, dear?' she whispers as she steps into the room, 'Why are you down here at this time of night?'
The husband looks up from his coffee, 'I am just remembering when we first met 20 years ago and started dating. You were only 16. Do you remember back then?' he says solemnly.
The wife is touched to tears thinking that her husband is so caring, so sensitive.
'Yes, I do' she replies.
The husband pauses. The words were not coming easily.
'Do you remember when your father caught us in the back seat of my car?'
'Yes, I remember!' said the wife, lowering herself into a chair beside him.
The husband continues. 'Do you remember when he shoved the shotgun in my face and said, 'Either you marry my daughter, or I will send you to jail for 20 years?'
'I remember that too' she replies softly.
He wipes another tear from his cheek and says...
'I would have been released today.'
A woman awakes during the night to find that her husband was not in their bed.
She puts on her dressing gown and goes downstairs to look for him.
She finds him sitting at the kitchen table with a hot cup of coffee in front of him. He appears to be in deep thought, just staring at the wall.
She watches as he wipes a tear from his eye and takes a sip of his coffee.
'What's the matter, dear?' she whispers as she steps into the room, 'Why are you down here at this time of night?'
The husband looks up from his coffee, 'I am just remembering when we first met 20 years ago and started dating. You were only 16. Do you remember back then?' he says solemnly.
The wife is touched to tears thinking that her husband is so caring, so sensitive.
'Yes, I do' she replies.
The husband pauses. The words were not coming easily.
'Do you remember when your father caught us in the back seat of my car?'
'Yes, I remember!' said the wife, lowering herself into a chair beside him.
The husband continues. 'Do you remember when he shoved the shotgun in my face and said, 'Either you marry my daughter, or I will send you to jail for 20 years?'
'I remember that too' she replies softly.
He wipes another tear from his cheek and says...
'I would have been released today.'
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.
Tuesday, September 02, 2008
Good Communication Starts With Good English
Good Communication Starts With Good English
By Edward J. Correia
September 2, 2008 — Any guide to leadership puts communication at the top of the list of good management skills. And good written communication skills start with a command of the language. Whether or not English is your first language, we all might have something to gain by brushing up on grammar and sentence construction.
To assist in that endeavor is Hannah Kirk, senior technical writer at Writing Assistance, a consultancy specializing in contract technical writing and training developers. "To write for all audiences is difficult. It would be nice if there was a way to write documents and e-mails for clients that were easy to understand and reduced confusion," she says. When writing user manuals, she explains, technical documentation teams use Simplified English, a form of English writing that is uncomplicated and easy for any audience to understand.
Kirk says that when writing for a lay audience, it's helpful to think of them as eighth-graders with little or no technical experience, the definition used by many organizations. "If this is the typical audience, writing instructional documents heavy with jargon and technical language will not help them. Many users are above this level of understanding, yet this type of writing does not over-simplify, but rather gives the important information in a straightforward manner that eliminates confusion and communicates the message in the most concise method possible."
Simplified English is not just for instructional manuals; it has applications throughout the business world. "A manager who writes letters or a support staff member who must communicate messages clearly and effectively can benefit from using this style of writing. This method of writing helps readers understand concepts clearly." Simplified English is understandable to readers of most ages and education levels, and can also aid communication with non-native English speakers.
Another benefit of simplified writing is the potential for reuse by other departments. Paragraphs written in Simplified English should be able to stand alone. "For example, documents written for instruction can be used in training...and reused in marketing materials. Writing this way can save businesses time spent recreating the same documents by different organizations. This inevitably saves the company money and frees up time for those employees to do other things," says Kirk.
The principles of Simplified English are these: It uses short phrases while avoiding metaphors, multi-syllabic words and words that have multiple meanings. "If a 3- or 4-year-old can understand a sentence without asking questions about the syntax or what a word or metaphor means, the sentence is probably in [Simplified] English."
Simplified English employs the following concepts:
Concept #1: Write as concisely as possible. When writing a sentence, re-read it and think about how it can be written more concisely. For example, here is a sentence that can be written in a more succinct way:
“When you plan ahead, you are able to think more clearly when you are busy.”
On first glance, this sentence might seem simple enough. It's clearly written and uses common words that have no double meanings. But it could have been written even more concisely:
“You can think more clearly when you are busy if you plan ahead.”
Three words were cut out and the syntax was restructured for a clearer understanding. Yet, this sentence can be cut down even more:
“You can think clearly when you plan ahead.”
The part about being busy was left out. Was it essential to the sentence? It depends on the context. If being busy was a core part of the subject, then it should be left in, Kirk says. "If not, this sentence has just been reduced from 15 words to eight! How short would e-mails be if their writers took the time to do this with every e-mail?"
Concept #2: Use active tense. High school and college students are typically taught to use passive wording, and journalists and academics also typically write that way (for example, this article is written in the passive voice). However, according to Kirk, this is not always the most clear way of writing.
"Even though many people will understand passive tense, new English speakers and translators appreciate the use of the active voice. For example, instead of writing, 'The sign was created for your information,' write, 'The company created the sign for your information.' A good rule of thumb for writing in the active voice is putting a clear doer of the action in front of each verb."
A good start would be to stop using the words is, be and are, she says. "For example, instead of, 'It is appreciated when you pick up your trash,' write, 'The company appreciates when you pick up your trash.' " Thinking about the subject of the sentence, who performs the verb, helps you write in as simple a manner as possible and will almost always keep you writing in the active voice, she adds.
Concept #3: When writing a verb, include the subject of that verb. Beyond the rule for writing in the active voice, this concept eliminates confusion about using pronouns, and helps new English speakers and translators determine the clear subject for each verb. "For example, 'Every time I drive my car to the store, it breaks down!' In this sentence, it could refer to the car or to the store, but there is no way to know for sure just by reading this sentence." The sentence could do without the extra pronoun and be more precise by specifying what it refers to: “Every time I drive my car to the store, my car breaks down!”
Kirk offers these additional tips for writing in Simplified English:
These principles can help you communicate more effectively with any audience, even those who translate your words to another language. And according to Kirk, "Your readers will thank you for making their lives easier!"
By Edward J. Correia
September 2, 2008 — Any guide to leadership puts communication at the top of the list of good management skills. And good written communication skills start with a command of the language. Whether or not English is your first language, we all might have something to gain by brushing up on grammar and sentence construction.
To assist in that endeavor is Hannah Kirk, senior technical writer at Writing Assistance, a consultancy specializing in contract technical writing and training developers. "To write for all audiences is difficult. It would be nice if there was a way to write documents and e-mails for clients that were easy to understand and reduced confusion," she says. When writing user manuals, she explains, technical documentation teams use Simplified English, a form of English writing that is uncomplicated and easy for any audience to understand.
Kirk says that when writing for a lay audience, it's helpful to think of them as eighth-graders with little or no technical experience, the definition used by many organizations. "If this is the typical audience, writing instructional documents heavy with jargon and technical language will not help them. Many users are above this level of understanding, yet this type of writing does not over-simplify, but rather gives the important information in a straightforward manner that eliminates confusion and communicates the message in the most concise method possible."
Simplified English is not just for instructional manuals; it has applications throughout the business world. "A manager who writes letters or a support staff member who must communicate messages clearly and effectively can benefit from using this style of writing. This method of writing helps readers understand concepts clearly." Simplified English is understandable to readers of most ages and education levels, and can also aid communication with non-native English speakers.
Another benefit of simplified writing is the potential for reuse by other departments. Paragraphs written in Simplified English should be able to stand alone. "For example, documents written for instruction can be used in training...and reused in marketing materials. Writing this way can save businesses time spent recreating the same documents by different organizations. This inevitably saves the company money and frees up time for those employees to do other things," says Kirk.
The principles of Simplified English are these: It uses short phrases while avoiding metaphors, multi-syllabic words and words that have multiple meanings. "If a 3- or 4-year-old can understand a sentence without asking questions about the syntax or what a word or metaphor means, the sentence is probably in [Simplified] English."
Simplified English employs the following concepts:
Concept #1: Write as concisely as possible. When writing a sentence, re-read it and think about how it can be written more concisely. For example, here is a sentence that can be written in a more succinct way:
“When you plan ahead, you are able to think more clearly when you are busy.”
On first glance, this sentence might seem simple enough. It's clearly written and uses common words that have no double meanings. But it could have been written even more concisely:
“You can think more clearly when you are busy if you plan ahead.”
Three words were cut out and the syntax was restructured for a clearer understanding. Yet, this sentence can be cut down even more:
“You can think clearly when you plan ahead.”
The part about being busy was left out. Was it essential to the sentence? It depends on the context. If being busy was a core part of the subject, then it should be left in, Kirk says. "If not, this sentence has just been reduced from 15 words to eight! How short would e-mails be if their writers took the time to do this with every e-mail?"
Concept #2: Use active tense. High school and college students are typically taught to use passive wording, and journalists and academics also typically write that way (for example, this article is written in the passive voice). However, according to Kirk, this is not always the most clear way of writing.
"Even though many people will understand passive tense, new English speakers and translators appreciate the use of the active voice. For example, instead of writing, 'The sign was created for your information,' write, 'The company created the sign for your information.' A good rule of thumb for writing in the active voice is putting a clear doer of the action in front of each verb."
A good start would be to stop using the words is, be and are, she says. "For example, instead of, 'It is appreciated when you pick up your trash,' write, 'The company appreciates when you pick up your trash.' " Thinking about the subject of the sentence, who performs the verb, helps you write in as simple a manner as possible and will almost always keep you writing in the active voice, she adds.
Concept #3: When writing a verb, include the subject of that verb. Beyond the rule for writing in the active voice, this concept eliminates confusion about using pronouns, and helps new English speakers and translators determine the clear subject for each verb. "For example, 'Every time I drive my car to the store, it breaks down!' In this sentence, it could refer to the car or to the store, but there is no way to know for sure just by reading this sentence." The sentence could do without the extra pronoun and be more precise by specifying what it refers to: “Every time I drive my car to the store, my car breaks down!”
Kirk offers these additional tips for writing in Simplified English:
| » | Put phrases next to the words that they modify |
| » | Keep the language simple |
| » | Avoid slang and clichés |
| » | Avoid cultural references (for example, common myths or fictional references) |
| » | Avoid words that have more than one meaning (for example, account can be a verb or can refer to a bank account, etc.) |
| » | Avoid leaving out verbs (or nouns) to make your sentences shorter if leaving them out reduces clarity |
These principles can help you communicate more effectively with any audience, even those who translate your words to another language. And according to Kirk, "Your readers will thank you for making their lives easier!"
Subscribe to:
Posts (Atom)