Modern testing for modern stacks

"I liked the way he has given examples to make point clear. I myself am not a big talker. I still try to find the right balance in making my point clear and don't be repetitive. When I started my career I tried to keep my points short as many engineers around did the same. But when I started noticing that people couldn't get some points easily I ended up adding more stuff to make it clearer. I feel giving right examples wherever possible helps to clarify stuff. I like the point the author makes about injecting energy. It's required when you are leading and need to motivate your team. Also being verbose gives people time to think. I still think a right balance is required or people would lose interest listening to you in case they find you too repetitive.

I like this article very much. He has explained the way of communicate effectively with so many examples. Either conducting meeting or talking to client the way we convey the message should be interesting,make them to ask questions to us and not too boring also. Explanation may be depends on the person to whom we are talking.Some may need to elaborate and some may not. So we have to think twice before we talk. To whom we are talking,should we elaborate more or less. But same time we have to be careful there should not be more redundancy also.

It's a great article talking about effective communication. He gives a classic example of quiet meetings. Yes, sometimes ignition is required, the manager needs to probe each individual. His example is good on engineer manager to the product manager. I agree that you need to be more clear, more verbose, also think about the other person who doesn't know a word about the topic. More than just giving a regular update, make sure you think before you talk, like write down what the accomplishments are and then you would get into a habit to be verbose.

As Engineers we tend to communicate with little verbose and try to be brief and to the point while communicating just like we code. This post articulates the reason why we may have to some times be more verbose. It is important to bring the audience into a discussion before a meeting to make it more interactive. I agree that it takes time to get good at this. But it should be one of the attributes that an engineer should work on because it how to communicate something is as important as what you communicate. I also agree that it may not be a bad thing to speak slow while tryinng to communicate as it gives you time to think.

A good post for engineers who want to improve the way they communicate with others. I agree with the author that being a bit more verbose can increase clarity and creates creative atmosphere.The best way is to first understand your audience and what kind of communication they need from you. The better you know the audience the more effectively you'll be able to communicate. Your thoughts must be organised and your understanding of what you want to convey must be absolutely clear. One technique is to start the conversation with a statement that has the important information and then continue with a longer explanation and expanding that conversation if needed. You need think about what is necessary and useful for them to know and the level of understanding they have and and communicate accordingly.

Nice article to read with different sets of communication among Engineering manager, product manager and other engineers depicting the facts. I don't know much of running the meetings but can talk about talking to non engineers. Sometimes the non engineers as the author speak about how product manager doesn't understand the efforts technical team took when the engineering manager tells him that technical team has reduced performance issues by 40%. But when the engineering manager tells him that view updates feature works faster then the product manager understands it. This is a fact which I have experienced. When you are an engineer, you always speak technically but when you are talking to a non technical person you need to be more verbose communicating to him in such a way that he would be able to intercept it.One example which I have seen is Release notes which are shared with non technical members explaining each of the release items more briefly, with less technical descriptions.