"Not everyone who understands something can explain it" - Buck Woody
"Your UI is how you communicate with others"- Buck Woody
Communication is a top 10 required skill in most careers, including IT and software engineering. That makes sense to me. I have a harder time working with engineers, customers, and managers who don’t communicate well, or at all. Working with them is far more difficult than going to someone who can tell me the information I need.
The corollary to this idea is: people who have a hard time communicating also have a hard time understanding. That makes sense as well; I often ask clarifying questions to make sure I understand someone’s intent and message. Communication skills are just as important when learning as they are when teaching.
Buck's first key lesson: each of us has a style. That struck a chord in me. Our style is many things. It is our cadence, our word choice, the common phrases we use, and when we use humor. His argument is that we should each seek to refine our personal style, instead of adopting somebody else’s. We should take the best parts of our own style and tweak them to be more effective.
Another key lesson? We already communicate, every day. It is unavoidable. So instead of learning to communicate, the lesson is to improve what you already do.
I don’t know what my personal style is, exactly. So I have been asking around. I found out that when I speak, I have a distinctive style. I am sometimes wordy, and I add nuance to avoid being too forceful. I also like to make my ideas a little abstract, because I want them to be broadly useful. I like my ideas to be seen like software patterns: useful in lots of situations.
If you don’t know your own personal style, ask. Your friends and colleagues know it very well.
Lastly, and most importantly, people have a natural preference to stories. A dry recitation of facts will be less well understood than if it feels like part of a story, or narrative.
The #1 Skill: Learn to tell stories.Permalink
"The best way to predict the future is to implement it" - Alan Kay
A year ago, several colleagues and friends including Kendra Little (b / t), Crys Manson (b / t), John Halunen (t), Mike Decuir (b / t), and Argenis Fernandez (b / t), went on SQL Cruise. They came back with fire in their eyes, new skills, and a lot of new contacts. This time, I decided to go as well.
Why Should I Go?
At first, my reason for going to SQL Cruise was "This will be fun!" I knew the organizers by reputation, and knew I would learn. A lot. I had never been on a cruise before and was curious what it would be like.
Later, I found I had different reasons for going:
What Did I Do?
I dislike the unknown. I learn what I can to avoid risk. Here's what I did to learn about SQL Cruise, and cruising.
And so it begins...
Boarding was very easy. I had read that earlier is better, so I arrived at 11am and was on board in 15 minutes. Our cabins weren't ready yet, so I went up to the outdoor dining area to chat with the other arrivals.
The first four hours of the cruise were spent in the sunshine, eating soft-serve ice cream and getting to know the other cruisers.
Some of my fellow cruisers, like Neil Hambly (b / t), were social and easygoing. Others, like Klaus Aschenbrenner (b / t), are more reserved, but have a wealth of experience. The others, like Ryan Malcom (t), are brilliant up-and-comers. It was clearly a great group of people to be with.
The Team-Building Exercise
Confio had sponsored a search-the-ship team building exercise. We split up into teams of 4 or 5, some of us merrily inebriated, and were told to find 25 different things on the ship. The winning team would win fabulous prizes.
45 minutes (and 500 calories) later, we finished. Sadly my team did not win. Still, it was an amazing experience, and worked brilliantly to break the ice to all of us.
Exhausted, content, and ready for the next day, I went to bed. The training was about to begin...Permalink