Skip to main content


Showing posts from 2012

Linking Google Drive Docs with Evernote

There is at least one service (CloudHQ) that will keep them in sync for a fee.  What if your requirements are very lightweight, though?

In my case, I just want to be able to link a Google doc to a note.  What I have been doing is:

Open the doc in Google drive.Click the share button.Copy the link.Paste it in Evernote with Cmd-K, Cmd-V. That's not a difficult workflow, but it isn't as light as it could be.  
As an alternative, try doing a one-time install of the Google Drive app (if you don't see a button to install it at the link, that probably means its already installed on your machine).  Then you can use Evernote's built-in "attach files" button or menu shortcut to put a Google Docs link right in your note.  Just navigate to the right place in your local Google Drive folder and and click 'open'.

A Good Code Editor Is Easy To Find

I've been playing around with Sublime Text, which is a code editor with a very active community.  I thought it was nice, but after years of using Eclipse, no big deal.  However, some people whom I respect (the guys at Bitovi have turned me and several of my Coworkers on to it) insisted that it was the best editor for programming that you can find.

To decide for yourself, I recommend the videos that Jeff Way at Nettuts put together to improve your workflow.  Watch the first one (it's only 2.5 minutes long) to get a feel for whether it's worth watching any of the rest.  If you watch just a couple more, I'll bet you'll be hooked, though.

What do I like about it?  I'll summarize in terms that are the most important to me:

Multi-platform (Linux, Windows and OSX - all platforms I use regularly).You can open a folder and use it like a project.  None of the long tedious "import" BS that you have to do in Eclipse.Quick file and symbol searching.  (Seriously, I…

Specializing Generalist: How Much of Each?

I just had a conversation with one of my teammates.  He's not happy with being seen as "The Javascript Guy", and prefers to be seen as a good all-around software developer.

He does make a very good point.  How much of our time should be as "generalists" and how much specializing in particular languages, libraries and toolkits?  How much time should we spend learning new things, vs time spent using the skills we have already built?

It isn't an idle question.  At the extremes, if you're constantly learning new things, you're always a newbie and not adding a lot of velocity to your project.  If you stick with the skills you have and apply only those skills, you will eventually be left behind by the march of technology, and obsolete as a developer.

My opinion is that the balance lies somewhere around 80/20, or even 90/10.  The majority of your time should be spent putting the skills you already have to good use.  I also think that the 10-20% time is s…

What is software craftsmanship?

In a conversation with Patrick Welsh today, and his take on it was that a craftsman is someone who:

Writes small methods.Uses excellent names.Keeps modules small.Test drives code. The context of this is that it is possible to do all of these things in Javascript.  Claiming that JS is fundamentally different from Java (or any other modern language) is a poor excuse for not being a craftsman.
I tend to agree with him, and disagree with John Marx's statement that you can be a software craftsman without doing the above things.  I think that John's point was that technique != mindset.  My disagreement is that at the current time, using these techniques is the way to be a craftsman.  As techniques and tools evolve, the definition of craftsmanship will evolve.
What do you think?

Death by Oversight: How much overhead is too much for an agile project?

I had a great discussion with one of my coworkers today.  He felt that we were adding a lot of noise to our current project due to the number of "fluff" people on our project.  In his opinion, anyone who wasn't spending most of their time on a keyboard (software developer, analysts creating stories, QA) is overhead.

Such people (which list includes me, BTW) have the following negative effects:

Communication overhead / Noise - people doing the actual work are often asked by multiple people how something works or why a particular choice was made.Meetings - we can be a source of meetings and other discussions apart from the "noise" above, if only to justify our time on the project.Duplication of effort - this has definitely happened to us.  More than one person steps up to get something done (analysis of a problem, breaking down & estimating a set of stories, etc.) and because we're not all communicating face-to-face, they don't work together on it.Cli…

It's More Fun With Two: Pair programming done right

A couple of months ago, I blogged about some of the mechanics of pair programming.  This post is more about the attitudes around it and supporting practices.

Pair programming is often held up as the one true path to good code, but there are some dissenters.  Many of these people aren't naysayers, but instead believe that while pair programming has it's place, so does writing code in blessed solitude.  Some (at least anecdotally) think that pairing is the root of all evil.
The truth isn't somewhere in between.  Pair programming really is coding nirvana, but only if you do it right.
Keys to Success
I have spent the last three years in a software development organization that has strong values around pair programming (after spending 20 years in 23 other organizations that didn't).  It is pretty consistent - most of the seven teams practice nearly 100% pair programming.  Most are pretty good at it.  Some are awesome at it.  In my experience, the following keys are what al…

Agile Transformation Defined

I'm currently leading an agile transformation, and it has been an incredible learning experience.
It has also been a frustrating experience that causes me to drink to wretched excess, and sometimes kick my dog.  But that's a whole different blog post. Some Background My company went "Agile" 3 years ago, and I was hired as part of that process.  We did it mainly by bringing a large amount of offshore software development back onshore, and hiring people who had the right skills to replace the offshore team.  This may be the easiest way to do it, and explains why we were successful where so many others have failed.
This Spring, one of our remote offices was having some trouble delivering a flagship product, so the suits decided that a leadership change was in order.  They moved a couple of people around to make room, then appointed my boss as the interim leader of the remote office.  Being a savvy businessman and a keen judge of character, he charged me with leading thi…

Pair Programming: How To Do It Right

Pair programming is an XP practice of putting two people in front of a computer, and having them program together. If you haven't seen it work before, it sounds wasteful. It is wasteful if you have one person writing code while the other passively watches, but there are some practices that make it a lot more valuable. When done right, I consider "paring" to be vastly superior to solo programming.

The way I have done pair programming goes hand-in-hand with test driven development. Here are the techniques I have used.

Ping-Pong PairingThis is a beginner technique. It can get you in the groove for a day of pairing, and it's also useful as an introductory technique to pair programming.

Here is how it works:
Developer A: write a failing testDeveloper B: make the test passRefactor together Developer B: write a failing testDeveloper A: make the test passRefactor togetherRinse and repeatThe idea is to make a game out of it. Write the simplest possible piece of code to make…

Team Accountability: Be Courageous, But Don't Be A Jerk

I have been helping to lead an agile transformation / continuous improvement effort for the past couple of months.  It has been a great experience, and I want to capture some of the things that I'm learning as I go.

In yesterday's stand-up, one of the coach/developers brought up a problem he saw.  One of the team members appeared to have waited too long to ask for help, working on the same story for several days.  It went something like this:
We need to spend more time listening to each other and ourselves in stand-up.  If you find yourself saying "I'm almost done" two or more days in a row, or if you hear someone else doing it, that's a red flag.  For instance, I was pairing on a story with Bob last Friday, and I heard him say today that he was almost done with it.  He and his pair need to say "we're blocked", and reach out for additional help on their story. I thought it was well put, but Bob (not his real name) was pretty upset about it, and …

Agile Performance Management: Why Performance Reviews Suck

Many thanks to Mary Poppendieck, who wrote about this topic in 2004, and proposed a comprehensive solution.  She is the inspiration for much of my thinking on this subject.  She is also a better writer than I am a cartoonist.

Performance reviews suck.  I don't know of anyone who goes into their appraisal without some trepidation.  Your boss is guaranteed spring some surprise criticism on you that is ill-informed or misses the point as you see it.  It's a real challenge not to get defensive about that.

The only thing that makes your own performance review suck less is having to give them.  As a manager, I have dished out quite a few, and some of them went pretty badly.  (To the people at my first management job: Thanks for helping me learn how to get better at them.  Your sacrifice was not in vain.)  Since then, receiving one isn't nearly as gut-wrenching, if only because I try to make it easier for the guy on the other side of the desk.  I've been there, and I know how …