RailsConf and 10% Time

Whoa! Has it been 6 months since I last posted? So much for that resolution of blogging more. A couple of factors fed into that. I've been working a lot on some projects that don't really feed my interest enough to write about in my spare time. Also, I've just been a little lazy about it in general.

However, that's about to change! I am starting to do some things that I find very interesting, and I'm excited to explore it on this blog. First, I'm headed to RailsConf this week. I can't wait, it's been a dream of mine to go to RailsConf. I'll try to report daily from the conference, to run down the things I've learned and what I want to explore further. Unfortunately, I'm a little behind on my Rails work, so I wish I was a little more of a polished Ruby programmer heading into this. It will definitely be like jumping into the deep end of the pool. I'm very excited.

Also on the horizon. My employer, Dominion Digital, is starting to offer 10% time to employees. I am leading up this effort, so I am very excited to get this started. I'll write more about this later, but basically we have to ability to spend 10% of our workweek on projects of our choosing. Granted 10% is not a lot of time, but I hope to help make this a successful endeavor. Maybe with success, even increase the amount of time spent on these projects. We'll have to see.

It's Resolution Time

Let me start by saying this: I hate New Year's resolutions. I work out in the early morning hours at a gym year round, and I dread the January rush of New Year's resolutions. I just keep reminding myself that I only need to bear through about 3 weeks before people give it up.

However, I've been doing a lot of reflection over the past year. I'm not sure if these are really resolutions, but it is a summary of some things I want to document for myself. Some things are mistakes I don't want to repeat, others are things I would like to tackle or improve in the coming year.

Estimating work - I got burned multiple times by underestimating work this year. Additionally, I got REALLY burned by other peoples' underestimations. There are some things I can do about dealing with other peoples' estimations, but I am a believer in taking charge of what you can control. This is a tricky proposition because estimating software is a very difficult endeavor. I plan on dedicating time to researching the estimation of software projects.

Being a jerk - I have decided I am way too nice around the workplace. I was looking back at my biggest project of this past year, and overall, it's a mess. And the things that are the biggest mess could have been prevented. The team was really crammed for time to meet a deadline, so corners were cut. There were some things that I was not comfortable with at the time, but I went along with it or turned a blind eye. I am through with going with the flow. I plan on being more difficult to work with when it comes to compromising quality.

Automate everything - I am generally very good at automating processes. However, there were cases this past year where I got too wrapped up with the task at hand and dropped the ball on this. I need to take a step back more often during the course of projects.

Post to this blog regularly - I've enjoyed writing posts for this blog, but I completely failed to keep it up in the second half of 2009. I plan on getting back in the saddle for 2010.

How to Review Presentations Effectively

One of the perks of my job with Dominion Digital is that I get to see a decent number of presentations before they are performed at a user group or conference.  I sat in so many of Ryan Shriver's Agile Engineering talks last year, that I probably could have been deputized to give some of them myself.  This is a great thing, I get to learn new things while the speakers are still working out the ideas themselves.  However, this is a very selfish approach to reviewing a speaker's presentation.  I guess it does not really matter when the presenter feels like the end product is a success.  But it's a bad thing when the presenter comes back feeling like the talk was a failure.

This past week, my co-worker Justin Etheredge, had such an experience.  He has well documented his experience on his blog.  I have to say that when he came back to work on Wednesday, I felt like I had let him down.  I had previewed this presentation, given feedback, then re-previewed his revisions.  I really felt like he had a good product to deliver.

Ok, so the first step to my recovery as a selfish presentation reviewer is to admit that I have a problem.  I recognize that if the presenter feels like he had some level of failure, I should feel like I failed too (and I do feel that way).  

Here was part of the problem with my review of Justin's material:  he was preaching to the choir.  Everything in his presentation, I agreed with.  He and I talk about this material on a daily basis.  We look at system design in very similar ways and are influenced by the same books and thought leaders.  So when he does a presentation on simplicity in system design, I am going to be nodding my head in agreement the whole time.  In fact, I am probably going to be excited that these ideas are being presented to new audiences.

This is no way to approach reviewing a presentation before someone goes before a user group or conference attendees.  Reviewers should not attend a preview of a presentation as themselves, they should be putting themselves in the shoes of the intended audience.  This is a fundamental principle of creating a presentation.  In fact, I'm reading a chapter on this topic right now in Advanced Presentations by Design.

This seems like common sense as a third party.  Of course you should consider the audience when you are creating a presentation.  But this is not nearly as easy as it sounds.  Removing yourself even further, it is very difficult to think in those terms when you are reviewing presentations.

So, going forward, I am really going to try to be more objective when I review presentations.  Also, I am going to try to understand who the audience of the presentation is going to be.  I should be content with learning from my co-workers while we are talking and working together.  When I am reviewing their presentations I should be reviewing their presentations. 

Review of Presentation Zen

When I read books, I often take notes.  Sometimes I take notes in the books themselves, other times I put notes down in notecards, I will also put notes in a personal wiki.  You could say that I don’t really have a system.  One thing is fairly consistent, I normally don’t go back and look at the notes (whether I can’t find them because of my “system” or I just don’t think about it).  So with my most recent read, I’m going to try something new… I’m writing about it in my blog.

Presentation Zen is an extremely good read.  I wouldn’t be doing it justice by putting my notes in a personal file.  This book should be shared.  I know I’m not the first reader or reviewer of this book, but I think word needs to spread about its virtues.  I have put off reading this book because I really haven’t done many presentations in the past.  When I signed up to speak at the Richmond Code Camp, I finally had a good reason to pick it up.

Presentation Zen is definitely tied in specifically about giving presentations; however, its lessons transcend this single topic.  The approach to presentations given here deal with design, storytelling, and simplicity.  These are valuable lessons for people of all walks of life, especially software developers.  Be warned, you will not look at presentations the same way again.  In fact, some presentations that you previously tolerated will become nearly intolerable.

One of the reasons I think this book was enjoyable and timely for me is that it shares elements with some other great books I’ve read in the last year.  I strongly recommend all of the following:  Pragmatic Thinking and Learning: Refactor your Wetware by Andy Hunt, A Whole New Mind by Dan Pink, Outliers by Malcolm Gladwell and Zen and the Art of Motorcycle Maintenance by Robert Pirsig.

All of these books challenge the reader to approach things with a different mindset.  There are consistencies through all of these books that seem surprising, since all of the authors are from different fields.  Also, every one of them is extremely relevant to software development.  That’s interesting because only one of the books was written by a software developer.

Back to Presenation Zen, I hope to improve my presentation style and maybe achieve the level of design and the naturalness of delivery that Garr Reynolds describes in its pages.  As I am not there yet, I am hooked on his blog where he posts videos of masterful presentations that capture this style.

Richmond Code Camp Recap

Ok, so this can’t be a full blown recap of the Code Camp.  I wasn’t able to stick around the whole day.  My wife and I celebrated our 6th anniversary this weekend.  So there was no way I could get by with spending the whole Saturday at a technical conference.  However, I really enjoyed the time I spent there.  It was a great environment, and I thought the organizers did a great job.

I presented a talk titled “Continuous Integration or:  How I Learned to Stop Worrying and Love the Build”.  I felt like it was fairly well attended and well received by those that were there.  I’m pretty new to presenting, so I think it went about as well as I could have expected.  The main glitch was the resolution of my screen vs. the resolution of the projector.  I didn’t realize the projector was cutting off my slides until about halfway in.  Instead of fixing it, I tried to keep driving forward.  I think it would have gone better if I had taken the minute or two to fix the discrepancy.

Anyway, I felt like I had a great audience and really enjoyed their participation.  Also, I felt like I did get the point across that Hudson rocks.  Hudson is a great tool to present Continuous Integration as an accessible practice.  I mean, I can spin it up from scratch and have new projects running in a matter of a few minutes.  I wouldn’t even dream of doing that with other CI tools in a live demo in front of a crowd.

So, with the success of this weekend, I’m going to take this talk to some other venues.  Next up, I’m penciled in to present this at May’s Richmond Java User’s Group.  I’ll have to rework some of the demo to translate the .NET project and tools to the Java platform.  I love the fact that I’m able to use the same talk for audiences from different platforms and languages.

This is really exciting for me.  For the last year and a half, I have had two major career goals.  First, to be equally proficient between the .NET and Java platforms.  Second, start presenting at user groups and conferences.  This is great because I am knocking both out at the same time.