Hash

Entries tagged as ‘Working’

13 Most Annoying People to Work with

March 30, 2009 · Leave a Comment

 

Most of us have had colleagues over the years who turned annoying into an art form. Well, now it’s a classifiable art form. Career experts Christine Lambden and Casey Connor, authors of the new book, "Everyday Practices of Extraordinary Consultants, " have compiled a list of "The 13 Most Annoying People to Work With." How many of these does your company still have on its payroll?

• Pontification Person. This person goes on and on, telling you what he or she is going to say, saying it, and then telling you what he or she said.
• Um Person.To avoid losing control of the conversation, this co-worker fills every pause with "Um," not realizing he or she might be able to think better when not talking.
• Too Much Detail Person. The authors could elaborate on this one, but then, of course, that would be contributing to the problem.
• 50,000-Foot- Only Person. He or she is eloquent when you talk about the big picture, but refuses to allow anyone to get into the details, which we all know is where the real work gets done. "Unless you’re the CEO of a multinational corporation, " say Lambden and Connor, "you have to be willing to work at any altitude." CM8ShowAd("Middle" );

• Hypnotized-by- E-mail Person. Wireless technology can be a lifesaver, but there’s something defeating about presenting to the tops of people’s heads because everyone at the conference table is hunched over his or her laptop.
• Buzzword Person. "This employee is annoying in meetings, team rooms, and in cubicles," say Lambden and Connor. "In fact, this person is just plain annoying all the time."
• Foul Language Person. Much like Buzzword Person, this co-worker is too lazy to think of the right words to express what he or she is thinking, if, indeed, he or she is thinking at all. This person isn’t trying to impress you with his or her knowledge. "They aren’t trying to impress you at all," Lambden and Connor note. "They don’t care what you think of them." Refreshing on some level, but probably not a person you’d want on your team.
• Reiteration Person. The only contribution this person makes is to restate what already was said. So, basically, he or she actually has no contribution to make.
• Too Busy to Be Prompt Person. He or she always is late to work and every meeting, clearly lacking time management skills. Nobody can be working on something important all the time, after all.
• Can’t Control the Meeting Person and arch-nemesis Wants to Take Over the Meeting Person. There has to be some balance between the out-of-control ditherer and the maniacal meetings dictator, doesn’t there?
• Secondary Conversation People. Your best material often isn’t riveting, but staffers at least could pretend to care. But Lambert and Connor point out these workers "only are annoying if their conversation is less interesting than the meeting."
• Disagrees With Everything Person. "This co-worker honestly believes he is just being practical, or serving as the voice of reason, or playing devil’s advocate," the authors point out. "This may be true sometimes, and even helpful occasionally, but when it becomes a habit, everyone else just tunes them out."
• Obscure Metaphor Person. This employee is as annoying as "the fool in a troupe of Morris dancers," say Lambden and Connor. "See? Wasn’t that annoying?"

By Margery Weinstein

 

 


Share this post : digg it! Facebook it! live it! reddit! technorati! yahoo!

Categories: LifeFactor
Tagged: , , , , , , ,

Working in a Software Company

March 27, 2009 · 1 Comment

 

There is life outside projects….your life and your family. Love your work but not your project or the company. Many developers after a certain amount of time become possessive about the project and the company. Do a professional job but don’t end up marrying the project or the company. Try to come on time and go on time. So that you do not get saturated and work on the project for a longer time and effectively. Don’t become a zombie – nobody said on his death bed that he would have liked to spend more time in the office.

Try to freeze your requirements before the start of the project. In practical scenarios it is very difficult to control the end customer. But if you can at least control the changes that will make the project more comfortable. (But if you can at least control the changes it will help you manage the project comfortably).
The best way to control changes is by taking official sign offs from the end Customer. As the saying goes, building quality software and skating on ice are both easy to do provided requirements are frozen.

Do not try to be a hero in the project. Because heroes also have to go through all the hardships. So believe in distributing the load equally which is not only good for the project but also for you in the long run. Do not try to be an octopus -  unfortunately you were born with only two hands.

Every project has parasite developers. In short every project has developers who constantly take help from others thus bringing down their productivity. Yes it is possible that they are your friends, but think for a moment – what’s smarter, giving a person one fish everyday from your catch or teaching him how to fish.  Step in to help others when they are stuck but you should know when to step out as well. There’s a thin line between helping somebody cross a tough hurdle and
carrying him on your shoulders – always be aware of this.

If you are a developer avoid doing their work from start to finish. Yes, give them hints but do not do complete coding for them.If you are a project manager you should analyze such kind of developers and take effective action at the very beginning which may even mean removing the resource from the project. Remember, your team is only as strong as its weakest link.

Do not make projects your learning ground. Customer’s pay heavily for making software so do not make it a learning ground. In many projects developers try to implement new technologies in mid of the project just by hearing jargons.

Test, Test and Test. That’s the key to success for any software project.

Do not hide your defects. Developers are the best guys who know where the code will crash. Do not hide it, analyze and fix it. Do not cheat and leave the same till it goes to the end client. Avoid ego issues during the project. Many times in a project developers and managers get stuck up with ego issues.  Sometimes stepping back makes the project move further Tackle bigger problems of the project first. The best way to complete any project is to start those screens which are used by the customer more often. For instance every project has non-frequent masters code them later and start the transaction screens first. Many time developers end up doing nitty gritty work and forget the bigger part of the project.

Do not talk about stars. Every project starts with talking about stars but later ends up somewhere else. Developers talk about concepts of OOP, full database normalization, design patterns etc etc. These fundamentals are important but it should end up with only jargons. Some times practical deadlines make it impossible to implement these features. Keep yourself flexible and compromise with quality when you have deadlines…..believe me it’s not a sin if a customer is giving you unreasonable deadlines.

Maintaining a right project hierarchy is very important i.e. the A model. In a model you have one senior person at the top, project manager, team leader, senior developers and then juniors. The right proportion of people from each grade is important. On any level if you have too much concentration you will have ego issue and promotion issues. Do not treat your project people as a resource. Project managers have this jargon of thinking of every one as a resource. That’s bookish thinking; any one working in a project is finally a human being with emotions. The moment you consider them as a resource they will also consider you as a resource. Moreover the word resource reminds you of water resources, mineral resources, oil & natural gas resources, etc which become empty some day – you get the point. In your own interests wipe off the word from your vocabulary.

Make yourself visible. If you think you have done something good show it, advertise it, make it visible. It will help you during your assessment.
Avoid getting into project politics. Peace of mind is the most important thing. Getting into egos and politics will only complicate things.

If you are working in a maintenance project upgrade yourself time to time. Change is the only constant in life – this is painfully true in the software industry more than anywhere else.

In case you are maintaining some other developers’ code do not criticize the code. Who knows in what circumstances the project was made .If you are a project manager in the project do not make it a compulsory rule that you will never touch coding. Remember juniors respect their seniors only if they sit with them for development and understand their difficulties. This is a time  tested rule – people only respect leaders who lead from the front rather than issue orders from the rear – don’t be a preacher, let your actions do the talking.

If any resource is working on a project for more than a year his performance comes down. Prepare a proper KT plan and bring in new resources and roll the old resources off for some better prospects. Avoid unnecessary meetings.

 

 

 


Share this post : digg it! Facebook it! live it! reddit! technorati! yahoo!

Categories: LifeFactor · TechFactor
Tagged: , , , , , , , , ,