In life we are free to define the same thing in many ways. I recently of read two separate definitions for Routed Events and presumably written by the same author. It his / her preface the author remarked that you could define Routed Events in two ways, a functional definition and an implementation definition. I cant imagine a world where the implementation definition is really that useful can you? Here they are:
Functional definition: A routed event is a type of event that can invoke handlers on multiple listeners in an element tree, rather than just on the object that raised the event.
Implementation definition: A routed event is a CLR event that is backed by an instance of the RoutedEvent class and is processed by the Windows Presentation Foundation (WPF) event system.
I read the functional definition and I say to myself, wow that’s cool, I can see myself using that…..very useful…..etc, etc. I read the implementation definition and begin to think it’s time for a coffee and a cookie. I have put together quite a few NDoc, SandCastle, JavaDoc API library and help documents over the years and when I strike one myself that exclusively uses “Implementation” definitions like the one discussed here, my head wants’ to explode. So please, do your colleagues a favour, if your going to document things, then only include implementation definitions if you have a functional one to go with it. In the case of API styled documents such as those produced by tools such as NDoc and SandCastle, often it’s the API signatures and examples that adequately describe the implementation definition at any rate.
How important do developers think that being a good communicator is in advancing their careers and being solid citizens in their workplace? Not enough of them in my opinion and too many rely on technical skills to drag them over the line. 
Communicating effectively with peers, business analysts, subject matter experts, departmental heads etc, is more than 50% of the job in many instances and when a developer cant do at least 50% of their job effectively, then the question needs to be asked, how valuable are you really to your employer and fellow team members?
It doesn’t really matter where your from or who you work for, its vastly important to speak clearly and demonstrate understanding of what’s expected from and by every one who contributes to a team effort. Now from time to time I have worked with people who were not the most effective communicators and it’s always been my advice to spend every bit as much of your time and effort in developing your communication skills as your technical ones - absolutely no excuses.
The best ideas will never be accepted without understanding and with poor 
communication comes poor understanding, so any developer who thinks they should tidy up their communication skills or wants to move into a leadership or management position within IT / Software development, then for heavens sake work on your communication skills and spend some time developing your ability to articulate your ideas and understanding. So how do communication problems exhibit themselves to begin with and how does one know that there is an issue to deal with?
Some of the Signs
- Does your manager, CIO, CTO (your boss) often relieve you of duty when it comes to presenting an idea to others? This assumes that your boss is still giving you the credit, but not allowing you to present.
- Are you having to repeat or rephrase your ideas constantly when expressing them? This assumes that the other parties are not limited in their abilities to understand.
- Do people interject before your finished explaining your point of view? This assumes that the other parties are not selfish enough to bulldoze over you with their own ideas.
What Can I do?
Find your weaknesses and work on them. If you don’t feel able to articulate well enough then read more and study the style of expression and increase your vocabulary. If your presentation suffers from lack of confidence and does not ‘throw to the back of theatre’, practice speaking with your partner or friends or in front of a mirror and work on projection. It’s even valuable to seek professional help if your language skills need improvement. When you hear or read new words that you don’t understand or know, look them up in a dictionary and learn them. Join a public speaking group or a debating team. There are many things you could do and this is not an exhaustive list, but if this shoe fits and you do nothing, well then nothing will happen and nothing will change! John Bennett also has some interesting ideas on the subject as do many others - so seek and ye shall find.
I read the functional definition and I say to myself, wow that’s cool, I can see myself using that…..very useful…..etc, etc. I read the implementation definition and begin to think it’s time for a coffee and a cookie. I have put together quite a few NDoc, SandCastle, JavaDoc API library and help documents over the years and when I strike one myself that exclusively uses “Implementation” definitions like the one discussed here, my head wants’ to explode. So please, do your colleagues a favour, if your going to document things, then only include implementation definitions if you have a functional one to go with it. In the case of API styled documents such as those produced by tools such as NDoc and SandCastle, often it’s the API signatures and examples that adequately describe the implementation definition at any rate.
