Communication, what does that really mean? Conveying ideas, opinions, directions to another person. That sounds like a good starting point to me. Two people talking to each other, or is it? Communication has been possible in many forms throughout history. Cavemen writing on cave walls, lighting fires on watch towers to send a danger signal faster than any enemy could travel, music, and finally the written word. All of these serve a single purpose, to transfer a message to another person. Other differences can be identified between transfers that occur on a one to one format, and others that occur in a one to many format.
New forms of communication spring up every day, but none of them serve any kind of new purpose. They all fulfill the same function, just in a new way. Blogs are a one to many form of communication, just like newspapers or the pictures on a cave wall. They intend to take the thoughts of one person and make them available for others. New technology simply broadens the audience and shortens the delivery time. Email is a letter that you can send without the latency of the post office, and with the added ability of being able to send to multiple recipients.
So with all these advances in technology giving us newer and newer forms of communication, why is it still so hard? Why do people still so often misunderstand what we are trying to say? It would seem that as communication gets easier, understanding what is meant gets harder. Why is that?
Perhaps as the cost of communication approaches zero, so does our respect for it. For example sending a telegraph in the early 1900’s was not easy and probably not cheap. When somebody wanted to send one, I would presume they would put quite a lot of thought in to the words they used because they were doing something important. Specifically, they would not be taking what they were doing for granted.
Today, it’s quite easy to take communication for granted. If I want to send an email to another person, I don’t think twice about it. I just quickly type out what I want to say and fire it off at little or no cost to me personally. This blog post itself is being made at little cost to myself, although with more thought being put in than the average email would receive.
So why do we take easy forms of communication for granted? It could simply be a matter of quantity over quality. With the amount of communication we have to deal with every day, we simply don’t have time to give each individual communication event during our day as much attention as we’d like to. Imagine how much time it would take if you put enough thought in to each communication you had every day to carefully pick your words and do everything you could to ensure your message was transmitted clearly. My guess is you wouldn’t have time for anything else.
What can you do to help mitigate these issues? The first thing you need to realize is that “perception is reality”. It doesn’t matter what message you intend to convey, the only thing that matters is what message is received. If you realize that, you are well on your way to improving your communication skills. It is important to think about how others are going to interpret what you are saying. There are a few things you can do that aren’t very hard. Firstly try to focus on quality instead of quantity. Pick the most important communications to participate in and make sure you take the time to think about what you are saying with special attention paid to what the receiving parties will be likely to interpret it as. Second, prefer methods of expression that include multiple simultaneous messages. When you send an email, you are sending only a single message, the message contained in the words. When you talk to a person face to face, you are sending the message in the words as well as the message included in your tone, body language, volume, etc. The more streams you can send your message in, the less likely the message will be interpreted incorrectly.
The next time you are communicating with somebody, think about the message you’re sending, and do what you can to make sure it is received as you intended it. You might be surprised how big of a difference it will make.
I welcome any discussion on this topic as it’s of great interest to me, and one that doesn’t get nearly enough attention.
By: Chris Dagenais
Today our morning energy level was given a boost by our Customer Service Representative (CSR) team. Not only did they manage to organize “pyjama day” as part of this they also cooked breakfast for the whole company. Waffles, fruit, juice, chocolate milk, whipped cream, sausage and most importantly BACON was provided. Gluttony for all.
Gestures like these are always a benefit to the team as a whole. Many staff get right into the dress up aspect of the day and breakfast is always a good excuse to talk about the upcoming day.
We often do things up here; Hawaii day, crazy hair day, etc. I know it’s cheesy but mixing it up at work to me is always a motivator.
By: James Townley
Today Joel and I spent the day in Vancouver at the BCIT Career Fair.
“We don’t hire smart people so we can tell them how to do their job, we hire smart people so they can tell us what the best way is to get the job done .”
That was my catch line that I came up with this morning for describing Point2’s development philosophy relating to Agile. It seems like a punchy and yet very accurate way to describe how things work at Point2. It invariably was followed by some chuckling after the first half, and then a look of intense interest after the last half.
The BCIT career fair is a fairly large event with 115 companies participating from a wide variety of fields ranging everywhere from healthcare providers, RCMP, to IT and Software Development.
We got out booth set up this morning which was fairly considerable to many of the other larger companies that were attending the event.
The first half hour or so of the event was reasonable with a person coming by to talk to us every couple minutes. It turns out that there are a few fairly specific IT type courses at BCIT, and some of them matched up great with the requirements for our systems administrator positions we’re currently advertising for. By the time the career fair had been going for an hour we were flooded by a constant deluge of students from these programs asking us “hey are you the IT guys so and so told us about?!”. We literally had a line up of people waiting to talk to us for the entire day. Whenever we finished talking to one person, 2 more were in line waiting.
So what did we learn by attending this career fair? A few things stand out for me as quite obvious:
- Even in Vancouver competing with Vancouver IT companies, our company is set apart from the competition because of our development practices. Agile and XP practices are very attractive to young developers and the fun relaxed atmosphere of our company helps a lot as well.
- Even though Agile and XP are nothing new, most people in school still haven’t heard of them, however once explained to them, they love the concept and want to be part of a company that uses them.
- Most people still have not heard of pair programming or TDD.
Most people love the idea of pair programming, especially when combined with Scrum team practices.
- There are FAR more specific programs available with regards to systems administration and web development than there were when I went to school. There are courses that teach web development that cover java, C#, ajax, asp.net, css, webservices etc etc. Nothing like that existed 10 years ago. It’s great to see.
- The market for jobs in Vancouver is getting dry. We had many people talk to us who didn’t care where they had to move to find work, they just wanted work.
- There were way more women than I expected showing interest in both the systems administrator role and the software developer roles. I’m interviewing two women tomorrow for positions that both seem promising.
- Moving to Saskatoon is not as hard of a sell as we thought it would be. I would say that about 10% rejected the idea outright, 40% were open to it but not sure, and 50% said it was no problem and they would move to wherever they could find a good job at a good company. The guy running the booth across from us said that we should be on the City of Saskatoon payroll for all the recruiting we were doing for the city, are you listening Don Atchinson?
Those are just off the top of my head. There are other thoughts i’ll be able to put together later once i have more time to think about it.
So programs from BCIT, I can’t believe how many are available. CSIT seemed to be the most common one from the people we talked to. It turned out that our job description for a System Administrator pretty much matched line for line the curriculum for their course so most of those students were quite excited. You’ll have to look for yourself at the wide variety of things offered as the list is quite extensive. BCIT Computer Courses Offered
Tomorrow will be another exhausting day. I managed to line up 7 interviews for developers tomorrow that i’ll be conducting in our Vancouver office. Joel has 4 interviews for sysadmins as well. It’s obvious to both of us that there’s a lot of talent in Vancouver, we just need to move some of it east Opening a Vancouver development office is starting to look more and more attractive…. maybe some day.
By: Chris Dagenais
I’m at DevWeek 2009 this week. I’d hoped to Twitter in real time at the conference, but the wireless internet there is overloaded. I’ve stepped out to a local coffee shop to get online, so my updates will likely be in batches.
The keynote was about cloud computing, and it raised a lot of interesting questions for me. Probably enough material for a decent blog post which I’ll write up tonight in the hotel.
If you’re at the conference, comment here or on Twitter and I’ll try to hook up with you.
We all want to be better at what we do, right? But how do we go about improving our skills? I think the answer is the same, whether you’re an aspiring software developer, musician, martial artist, or whatever. The key is focused practice. You need to put time into developing your skill. You can’t just put time in either. It has to be focused time. This is time where you’re consciously thinking about your craft, critically analyzing your work, and looking for ways to improve it.
Some of this possible during your day-to-day life; but in my experience, you always get better results by setting aside a special block of time to work on a skill.
The best way I’ve found to apply this to software is through code katas. A code kata is a problem simple enough that developers of any skill-level should be able to solve them. A kata is also small enough to solve in a reasonable period of time. My learning process currently goes something like this.
- Pick a skill I want to improve at.
- Pick a kata to solve, and a language to solve it in.
- Solve the kata while focusing on how to apply that skill to the kata.
For example, let’s say I wanted to work on my TDD-fu. I would pick a kata that I knew reasonably well; in my case that’s the bowling problem. I would pick a language that I knew well, and had a good testing framework; that would be java and junit. I would then implement a solution while thinking about things like…
- How much code am I writing per test? Should I be writing more? Less?
- Is my test naming clear?
- Am I remembering to think about refactoring every time I see a green bar?
- Am I aware enough of what’s going on to know when I’ve made a mistake and chosen a bad test?
You can use code katas to improve your skills with just about any technique related to software development. Just to name a few, they work well for improving your pairing practices, new languages, writing good OO code, and learning new tools. You just have to pick a focus.
A Coding Dojo
There’s been lots of success stories recently about coding dojos. A dojo gives us a social context in which to work on our katas with other like-minded people. It’s a great mechanism to get feedback on your work, but the downside I’ve found is that a lot of people are intimidated by this. I think the best way to deal with it is just to work on a kata in your own time until you’re comfortable with it, and then bite the bullet and seek some feedback.
By: Kevin Baribeau
I ran into a hard problem today at work. Here it is:
Given two strings, check that the first does not contain a sequence of 3 consecutive letters that are also contained in the second.
Look easy? It should. I don’t know of very many easier problems. After implementing it though, I can’t truthfully say that it was easy for me. But, I don’t think the lessons I learned today are easy either. As far as I can tell, I made three mistakes:
Lesson #1: Be careful when picking your test cases
It’s easy to pick a test case that’s either too hard, or too easy to implement. If you pick a test case that’s too easy, you and your pair risk getting bored. Oddly enough, this is almost never a problem unless you’re actively trying to avoid picking a test case that’s too hard.
So, if you’re bored, then your tests are too easy… how do you tell when your tests are too hard? Well, that’s another hard problem. I don’t think I’ve nailed this down completely yet, but here are some clues I’ve learned to spot:
- It takes more than one try to get your newest test to pass
- When you do get your test to pass, another test fails
- Your pair doesn’t understand what you just did
- You find yourself wanting to refactor against a red bar
My advice when you run into any of these indicators is to stop. Stop writing code. Revert to a green bar. Now you have two options: Refactor, to make things easier; or pick a different test.
Sound easy? Try it. There’s two reason why it’s not.
First it’s hard to admit when you’ve picked a test case that’s too hard to implement. We’re programmers (craftsmen if you will), it’s our job to solve hard problems. We take pride in our ability to do so. We want to make that next test case work. Taking a step backward and reverting the code you just wrote (that doesn’t work) is an admission that you’ve made a mistake. Admitting this mistake is especially hard to do when you’re working on an “easy” problem.
Second, both of these options require you to THINK. It’s tempting to think that if you tweak a conditional here or extract a method there you’ll see a green bar soon. This rarely turns out to be the case. Even the easiest problem is going to require you to stop and think about the solution; probably more than you expected to.
If you run into this, Stop. Think about the problem. Discuss it with your pair. Then, take another crack at it.
Lesson #2: Commit Often
Today, my pair and I ran into all of the clues listed above, and failed to stop. It was at this point that we got burned by lesson #2. We realized what was going on, and wanted to revert to our last green bar. We hadn’t committed in 90 minutes. We were stuck with broken code. Oops.
I don’t have a strong opinion on when you should commit. Ideally, I would say you should commit on every green bar, or after every refactor step; whichever is easiest to remember for you. Of course, some teams are cursed with long running unit tests. Since you don’t want to commit without running your tests; this makes it difficult to commit so frequently. Do what you can to keep your tests running quickly, but in the meantime, find some balance between committing often and not letting your tests slow you down.
Lesson #3: Focus on your work — No Distractions
Today, during the “embarrassing pairing session”, I had an interesting email thread zipping through my phone, which dutifully beeped at me every few minutes. Every once in a while I’d try to keep up with it, meanwhile completely losing my focus on the problem and relying on my pair to get me back up to speed when I was done.
Please, be wary of checking your email or other distractions when pairing on a problem. If you’re not at the keybaord, your job is (among other things) to help figure out the next test, watch for warning signs like the ones I listed above, and maintain code quality. You probabaly can’t (I know I can’t) do any of these things while checking your email, or carrying on a casual conversation with a friend. Also, respect your pair. If they’re working, you should be too. They’re going to resent you if you don’t pull your weight.
By: Kevin Baribeau
At Point2 Technologies, we develop software following Agile principles. We are always interested in discovering, learning, and sharing new and better ways to embrace agile development practices. That is why we would like attend and possibly present at the upcoming Agile 2009 conference.
We have prepared a few presentation proposals which we have submitted to the conference’s official website:
*Please note that you do need to create an account or login to be able to view the links.
By: Jesse Webb