Sunday, February 20, 2011

Course Review: Crucial Conversations

So recently I found myself in my performance review.  Everything I do is great.  My work is done on time, and meets requirements.  I constantly think ahead, incorporate new technologies to solve old problems, and think about the long term while building software.  What I don't do very well is communicate with others.  Hence my taking the crucial conversations course.

I found crucial conversations to be a great course/book.  What I loved about it is how the techniques described in the book promote candid responses.  They don't want you to flower things up.  They want you to be direct, and to "know what you want".  For example, say you rely on another member to get some work done.  The work that they produced is either incomplete, or insufficient.  You could go on a flame streak.  You could insult them, degrade them.  You could talk bad about them behind their back.  You could do all of that.  Or, you could step back, analyze what you really want, and approach the problem that way.  You could say to yourself, I really want to get this work done (more than insulting), how can I have a conversation that will lead to the real goal?

Like most courses of this kind, the real focus is on you.  You have to change the way you think.  You have to know what you want, and keep that paramount in your mind while conversing.  You have to master your stories.  Everyone sees the "truth" through the lens of their experience.  In your own mind, take the story you have created about an event and try to separate out fact from fiction.  For example:
"The supervisor hired the recruit.  The young man poured sand in the copier.  The boss found out that the copier was broken and fired the new recruit."

Even just examine the above story.  Did you think that the young man was the recruit?  Did the story actually say that, or did you just assume that to be true?  Is the boss the same person as the supervisor? Are you sure?

The one element that I really liked about the course was the tools they developed for actually having a crucial conversation.  You have to follow the STATE rule.
S ==> Share your facts
T ==> tell your story
A ==> Ask for others' path
T ==> talk tentatively
E ==> encourage testing

I really suggest that you read the book (or take the course) as it does go into a lot of depth about how to deal with people.  The tools provided will probably help you solve a lot of issues you may be dealing with in both the work and the personal life.

Sunday, February 6, 2011

Book Review: Joel on Software

I think that this book can clearly be labeled as an "oldie but a goodie".  Published in 2004, this book provides a neat perspective on software development.  This book was a great read providing good tips and thoughts on a large variety of topics.  I particularly liked his articles on the microeconomics of software development.  If you want to become good a designing products, then you have to understand what "designs" sell.  I know that some software developers out there would say that that is more of a job for BA's or project managers. I  disagree.  Life is all about the value you can add to your job.  Let me break into a story.

I was on the way to Toronto over Christmas, and was looking for a place to park in the Calgary international economy parking lot.  There were none.  I quickly hopped over to the park and jet.  I got on the shuttle to the airport to find just myself and the bus driver.  He was complaining about how the park and jet that he worked for never gave raises at all.  He said that he had been working there for a few years and never once received a raise at all.  At the time, I politely said that that was an unfortunate circumstance, and went on my way.  But it really got me thinking. Why do people automatically assume that they should get raises?  In my mind, everyone should get a cost of living increase.  I don't think that you should get paid less the next year for doing the same job (unless of course you have been demoted).  But why do people automatically think they deserve raises?  What value have you added to your organization to deem such a raise necessary?  Have you taken courses to increase your technology profile?  Have you contributed above and beyond your job description?

How this relates back to the book is that a lot of what he talks about in the book has nothing to do with traditional software development.  But keeping the topics in mind will help you add value to your job, and thus (hopefully) get you that raise.  I think that good managers can spot the difference between good and bad programmers.  I really feel that when you do your job properly, when you keep the big picture in mind, you do produce better programs, a better product, and a better customer experience.

If I had to summarize his book, I'd probably give the following points.

1)  The Joel Test
http://joelonsoftware.com/articles/fog0000000043.html
     - Do you use source control?
     - Can you make a build in one step?
     - Do you make daily builds?
     - Do you have a bug database?
     - Do you fix bugs before writing new code?
     - Do you have an up-to-date schedule?
     - Do you have a spec?
     - Do programmers have quite working conditions?
     - Do you use the best tools money can buy?
     - Do you have testers?
     - Do new candidates write code during their interview?
     - Do you do hallway usability testing?

The Joel test (as mentioned in the article) can be a quick guide to see where your software development practices are.  You can also use it to rate places to work.  You won't believe how many "15 year experience developers" who have never used source control.  Even myself, I have only really used subversion up until this point and have not really gotten into the world of DVCS (mostly because my employer uses subversion.,. could be worse.. could be the visual source-safe).

2) Specs
This is a disease that you need to get.  If you don't have it, infect yourself today!
http://www.joelonsoftware.com/articles/fog0000000036.html

3) Strategy letters
Basically interesting articles on how to build software that will sell, and a little insight into why some big companies do what they do.

All in all, this book was a really good read.  It was good to read a book on software that wasn't exactly about the software that we write, but more about why we write it. (And a little about how to write it too!)