Pragmatic Geek

TL;DR

• Google offers two libraries for accessing their services, the gdata-api and google api
• The older one looks more complete, and with a promise to maintain it, it’s tempting
• Don’t give in – take the time to deal with the newer API

A current project of mine involves using Google Docs and automating a workflow using Google App Engine (GAE) with Java. There are two libraries provided by Google for accessing their services, an older library called “gdata“, and a newer, called “google api.” The older comes with the warning:

We have stopped actively developing this client library, except critical bug fixes and support for some Google API’s. However, this client library is not deprecated, and is considered the “stable” choice, unless you have a specific requirement that is only supported by the new client library below.

The newer comes with a nice migration message, but also with the caveat regarding the generic Data APIs (and the specific Document List service I wanted)

We do not provide service-specific libraries for the Google Data APIs because they are built on an older infrastructure that does not have a Discovery Service. Nevertheless, the base Google API Client Library for Java fully supports Google Data APIs as long as you write your own Atom XML data model

The last emphasis is mine, and it scared me away from using it, reasoning, “why should I write my own data model when a complete one exists?”

Here’s a stack of reasons why:

• gdata does not come with any maven support. I did find a script to add the jars to my maven repository, though.
• gdata has manual hoops to get working with OAuth. Although they have the recipe fully documented, they still have this zinger, “you need some way to persist the token secret in order to create an OAuth token object coming back from the approval page.” They vaguely suggest, “set a session variable or cookie,” but they don’t provide any sample code that closes the loop.
• gdata has archaic dependencies. Its latest release is completely incompatible with the newer API, since the newer depends on a recent release of guava, but gdata still depends on google-collections-rc1. See Issue 244 for an example. You can’t accuse of the guava folks of premature deprecation – they kept the old methods in for 2 years before removing the deprecated calls.
• Despite promises of “gdata-java-client is not deprecated. We are keeping it in maintenance mode, fixing critical bugs, and adding a few minimal features,” the code doesn’t support this. Again, see issue 244 where a patch has been submitted and its still sitting there.
• I really wanted to use the “changes” feed from the Document List API. Although there are ExtensionPoint classes such as Changestamp and LargestChangestamp in the library, no samples referenced them, and questions in the forums about why they weren’t working go unanswered. I couldn’t get changestamp data out of the old classes, which is what eventually caused me to change course
• Writing custom Atom XML beans isn’t that bad. @Key is your friend, and there are plenty of samples.

I’m still at a loss for why a Google Data API is not fully fleshed out. The calls are well defined, there’s just some effort involved in doing all the mapping. Perhaps there’s a measurable performance penalty of mapping all the XML into beans that is offset by the effort required to write all the ones you need.

Hopefully this post will save someone else the same missteps. It’s not about reinventing the wheel, but learning from other peoples experiences.

As a followup to an earlier post on focus, I want to share some of my initial conclusions. Hopefully my experience will encourage others to take the leap towards focus, and I can only hope some managers will read this and ponder what the lack of focus is doing to the productivity of their staff.

My new role is to prototype and research upcoming technologies or products, enabling our business to become more proactive about disruptive technology. Each project is designed to run for 2-3 weeks before wrapping up with a presentation, and then moving on to the next opportunity. (If the business likes what they see, other groups will be responsible for taking the prototype to the next phase.)

In short, I get to work on one thing, all day, every day, for 2-3 weeks, and then it’s done. What has that meant for me?

• I’ve gotten so much done. I’ve written about 3500 lines of new code in 3 weeks, with an equal amount of testing code in order to achieve 100% unit test coverage. I’ve modernized the build environment, runtime frameworks, and sped up testing cycles.
• I’ve gotten hard stuff done. This project was dealing with a legacy code base and ways to modernize it in an incremental fashion. As an application architect, I’ve always visualized my job as a chess game, lining up moves in the far future, defending against surprises, and preserving the integrity of the current position. Jumping into a older code base, it’s even more important to tread lightly, which takes a higher level of concentration.
• I finish the day accomplished and tired from mental exertion, rather than frustrated from lack of significant forward motion. There used to be days where a stiff drink was the only closure to a joyless day, but now I actually understand the origin of “happy hour.”
• Focus can snowball. In the old days, when juggling lots of projects, it was too easy to fill the cracks between meetings with wasteful activities like Facebook and surfing. “Hey, I’ve only got 10 minutes before the next meeting, can’t get anything meaningful done, I’ll just check Twitter.” Now, legitimate breaks come at the end a burst of activity.
• I still get up about 5am, but now I’m anxious to pick up progress from where I left off the the day before, rather than spend the prime 1.5 hours of the day plowing through email.
• Inbox Zero? Who cares? There have been multiple days where I haven’t gotten a legitimate email until almost lunch time. Rather than all this talk about how to tame the email beast, what if we arranged our projects such that volumes of email were unecessary?

Through all of this, I’ve been conscious of how much the telecommuting situation has helped. I don’t have external events interrupting my focus, and when I need a break, I do it on my time, and in my own way. In the office, I’d be embarrassed by the happy dance I do when something goes well.

Please friends, consider ways you can create focus in your workday – it’s completely transformative to productivity and happiness.

TL;DR

• Our lives can be divided into 3 major activities: Consuming, Communicating, and Creating.
• Only Creating adds value to the world
• Find ways to do more creating

I frequently cite a blog post that describes our lives divided into 3 distinct buckets of activity: consuming, communicating, or creating.[1] Around the same time I read that, I read Leo Babauta’s free ebook about “Focus: a simplicity manifesto in the age of distraction.” The book used similar words, and reinforced this separation with the assertion that creativity can’t happen with all the distractions of consuming and communicating.[2]

Think through your daily activities, and most everything you do can be put in one of following 3 buckets:

• Consuming: All the time we spend reading email, books, social media, watching TV. Eating and driving are forms of consumption too!
• Communicating: At work, it’s meetings, water cooler chat, email, time tracking, etc. At home, it’s time spent talking with loved ones, writing emails to friends, sharing our status and life events, etc.
• Creating: Any activity that reduces entropy in the world, whether our creations are made of words, computer code, sound, paint, wood, etc. This includes any form of teaching.

It’s not just that those activities are distinct, but they also match up to a spectrum of the value we add to the world. Consumption adds nothing, Communication is often necessary to help others with their creation process, and Creation is where we really distinguish ourselves as members of society. It’s not that the first two are inherently wasteful or bad, it’s just that creation is the only way to truly add value.

Another key realization is that same sequence corresponds to required level of energy: Consumption requires no energy (put another way, inertia keeps us on the couch), Communication takes some, but Creating takes “real” energy.

It should be a goal for all of us to increase the amount of time we spending creating, rather than simply consuming.

Some ways I’ve found to move towards that goal:

• Be mindful of which bucket your current activity is in. Knowing that reading Twitter and RSS feeds  is “consumption” is often enough to guilt me into a different activity. [3]
• Use blocks of time for focus, and the longer the interval, pick a more energy-intense task that will create something
• Sometimes consumption is a reward for creation well done. After a good day of creating, it’s OK to surf. On a smaller scale, this is the Pomodoro Technique
• Exercise consumes energy, but (paradoxically?) it also generates energy that can be tapped for more creation.

What do you do to increase time you spend creating?

[1] The point of the post was really as a prediction of why the iPad would be a hit, since it filled a new niche not covered by our desktop computers or mobile phones.

[2] The key for increasing time for creating is focus. The book continues with practical advice for achieving focus with multiple chapters on clearing distractions, simplifying, and focus rituals.

[3] To be honest, I distinguish 2 forms of consumption: 1) mindless reading twitter or Facebook feeds, following rumor blogs, playing solitaire, or watching TV and 2) active reading/watching content that affects my career or project obligations. I can fight the inertia of mindless hyperlink clicking by tell myself I at least I’m consuming something will allow me to create something in the future.

Today is a transition point for me: I officially start a new role tomorrow (same company, different division). What’s key about this  new role is how it fits into my growing awareness of the importance of focus, and how the lack of focus has been a source of stress and unhappiness.

I used to describe myself as a vicious multitasker. I was proud of how many threads I could juggle, with its corresponding appearance of throughput. “Hey, I’ve got 3 instant message conversations going, a voice call, and an active code debug session running.” Those days are gone.

Time and attention are finite resources for all of us, and while time marches on, the only thing we have ultimate control of is what gets our attention. There are constant forces seeking to fragment our attention:

• Multiple projects. When you’ve got multiple active projects assigned by management, you need to keep up appearances that you’re working on all of them. You push each project forward a bit, never sitting down down and making major progress on a single one. In computer terms, it’s called “thrashing”
• Lack of priorities. Multiple projects are made worse when they are all equally important. Many folks won’t admit that there’s a difference between projects being critical and the fact that one of them has to take precedence. The individual is forced to set their own priorities, and 2 individuals may choose differently, which creates conflict.
• Meetings. Since people have different schedules, the “necessary” coordination meetings get scheduled throughout the day. Given multiple projects, you can’t find uninterrupted blocks of time to focus on the doing of the project.

If I were a better note keeper, I’d have a ton of links and quotes on the subject. Here are a few:

• David Allen, author of “Getting Things Done.” Get beyond the surface stuff of efficiency and time management, and he’s really talking about focus and the trust that whatever you are doing at a given moment is the best thing you can be doing.
• Merlin Mann gained fame as a productivity blogger, and has since evolved into a huge advocate for focus and getting to work on the creative process.
• Paul Graham’s classic Maker’s Schedule, Manager’s Schedule sums up the tension between the corporate world and passionate developers.
• The Modern Meeting Standard, a way to bring a form of focus to bad meetings

For kicks, I’ll throw in a picture that made me chuckle. It may not look it, but I was totally having fun, in part because I was focused. This was taken the Minnesota Orchestra Fantasy Camp, where amateur musicians got to perform along side the professionals. I was obviously just counting rests at this point, but, wow, I was in the zone.

I’ve seen various posts that describe what it means to be “on rails” but none that actually address actual physics of it, and why it’s such a perfect metaphor for what Ruby on Rails is.

Why do trains stay on their tracks? Contrary to popular opinion, it’s not the flanges. If it were the flanges, there’d be lots of wear and noise by passing trains. Instead, it’s because treads of the wheels are tapered, and this taper causes the wheel pair to naturally “hunt” for the center of the rails. Richard Feyman explains it quite well on YouTube. Or for even more detail, read about rail adhesion on Wikipedia.

I like to think of the Ruby on Rails framework as the software equivalent of the taper. The conventions that are built into RoR continually drive us back towards making a maintainable application, with good separation of model, view, and controller, test driven development and rich testing frameworks, and the rich ecosystem of gems to avoid reinventing the wheel (pun intended) in common features of applications. Add in some DRY (Don’t Repeat Yourself), and the bevels increase, and the result is like having the two rails turn into a V-groove that your application just rolls smoothly down.

I’ll go even further (and abuse the metaphor) to compare other platforms to the rails. Java is like a railroad without any taper, and it depends on the flanges to stay on track. Java’s flanges include the static typing and the multitude of frameworks that try and help make a better flange (Spring, Struts, Hibernate, J2EE, etc). And oh, does it make a lot of grinding noises!

But thank goodness for the open source community creating all those flanges faster than the Java train can derail, because the .NET world is like a a railroad with the bevels getting wider toward the outside, which is a terribly unstable configuration. (I wish I could find the video I have such a vivid memory seeing as a child (PBS?) showing the comparison of the conical configurations). Sure, really good engineers can create a workable train route, but it’s just too easy for an inexperienced developer to create a train wreck from all the wizards.

RoR is the first framework in my 18+ years of server-side web development that makes me regret all the flanges I had to make in the other frameworks. Thank goodness for those tapers!

All Aboard!

I’ve been trying to pin down some thoughts around the frustration, drama, and friction that seems to arise on workplace projects, and I think almost all of it comes down to the character of the people in the project. We’re often tempted to pin it on impersonal attributes of the project’s context, but it really comes down to the people. Put another way, if the project itself were so terrible, then everyone would think it sucks, but in fact, some people thrive on the project.

Think of a case at work where there’s drama or friction, and then think of some of the key people in the drama, and list 5 adjectives or phrases that best describe each of them. (Google some if good words are escaping you.) Next, list 5 adjectives or phrases about the project or context of the drama.

I bet between those lists, you’ll find incompatibilities in (at least) one of the following ways.

1. 2 opposing traits in 2 key people
2. A person assigned to do tasks incompatible with their own traits
3. The project traits are incompatible with a person’s traits.

For instance, you’ll get friction with an intuitive person working with a metrics-based analyst, a perfectionist on prototype project, or an impatient person on a highly regimented project.

What can be done about it?

First, a tiger can’t change its stripes. It is foolish to try and change the person to fit the situation, and if you do, you’re going to end up with friction from #2. A good manager will naturally assign a detail-oriented person to tie up a multi-faceted project implementation, and not try to pull the details out of the laid-back, wing-it guy. Don’t try to fix the trait with “coaching,” you’re only fooling yourself.

Second, stop looking at character types as being right or wrong. All character types just are, and only get labelled as good or bad when viewed in a particular context. If we look at traits as inherently good or bad, we miss out on assigning people to projects where those traits might be beneficial. For example, even laziness is a virtue, in context.

Finally, work to match projects and people to the traits are compatible.

This may all seem like a big “duh,” but instead of just blaming project problems on the situation or the people in isolation, doesn’t it all come down to putting the wrong people in the wrong situation? On the flip side, when you match up the perfect person with the project, isn’t success nearly guaranteed?

I am motivated by efficiently building quality solutions in a positive team environment. 13 words to sum it all up. If all that happens, it’s like a perpetual motion machine of success.

There are several required elements of a tactical environment to make that happen:

• Work from home. Without commute times, you don’t have to sacrifice the rest of your personal life with the best hours of the day away from the things you love. Also, without distractions of water cooler chat, you can get (and stay) in a productive zone
• Focus. It’s impossible to build quality if you’re fragmented over multiple projects. Get on board with one major project and finish it before going to the next one
• Ruby on Rails. I’ve been developing server-side web solutions for 18 years, and RoR is the first framework that makes me regret the time spent on plumbing. Java allows good separation of responsibilities and quality code, but it seems so verbose compared to the strategy of convention over configuration.
• Mac OSX. A work environment that stays out of your way, with all the power of unix and awesome software.

This week, I’m a happy geek: I was able to persuade my boss to buy me a Mac as my new workstation. And although Apple freshened the notebook line in interval between the order being placed and it actually arriving at my house, I’m very happy with the 17″ MacBook Pro as-is. But the point of this is not to get into the specs or version envy, it’s about why I’m so passionate about it being a Mac.

High end, portable power. 32-bit windows has an upper limit on usable RAM at ~3G. Our development environment isn’t that fat yet, but it’s only getting bigger. Running Eclipse, Tomcat, MS Office, InDesign, MySQL, a couple web browsers, and it’s quickly approaching the point where you start taking a huge performance hit for paging your apps on/off disk.

The only answer is to get into a 64-bit OS to address more memory. I don’t want to fight with 64-bit windows, since I’m not confident in all the compatibility stuff (notably our VPN software). Apple has successfully made the switch between CPU architectures and OS architectures multiple times, so I’m confident there won’t be 64-bit issues with the software. The 17″ MPB can hold 8G, and I plan on using it.

The alternative is Linux, with the windows-specific stuff running in a virtual machine. That environment, however, would be even more “out there” in our company – at least the Mac has some core use the publishing areas.

Better productivity software. Your computer workstation is your main line to getting things done, and it should support you in that by getting out of your way. I haven’t seen anything in the Windows world that can rival the ecosystem around AppleScript and application interoperability that is designed into OS X. Specifically, I plan on becoming a Quicksilver ninja. Quicksilver is to computer productivity as J.S. Bach is to music: every time you sit down with it, you can find a new nuance that makes you appreciate it more. The best resource I’ve found, even though it’s completely dense,  is a PDF enumeration of all the features and plugins.

The other huge productivity win is Spotlight. Built-in full text and file search across the entire machine is like having a private Google. I admit, I never tried Google Desktop,but I’m more confident in Spotlight, since it’s built-in to the OS, and developers are encouraged to make their files compatible with its indexer. Entourage (aka Outlook for Mac) by default extracts copies of all attachments to a cache in your Documents folder, enabling Spotlight to pick them up. I’ve been able find attached file content in single-digit seconds this week, a task I’d often downgrade to a manual filename search, taking at least a minute.

And then there’s OmniFocus, with its rich iPhone integration. I’m just getting started there, so I’ll have to save that for a future post.

I’m also banking on OmniGraffle, an alternative to Visio. A picture is worth a thousand words, and the better looking your picture, the more it’s taken seriously. The defaults in Visio are just ugly, reminiscent of a 80′s flowchart stencil barfing on your paper. OmniGraffle, on the other hand, has gorgeous defaults, tasteful shadows and curves that let you create a picture worthy of your ideas. If the defaults aren’t enough, check out the user contributions at Graffletopia.

Honorable mention:

• UNIX. The power to drop down into a command line and stitch together a series of commands for a complex search or file manipulation is unrivaled. Among geeks, this counts as productivity tools
• Time Machine. How many people backup their laptop regularly, or go to the trouble of buying decent backup software? Now, I just plug in an external disk and forget about it.
• Battery life. How much time is wasted in meetings crawling under the table to a power strip? I’m consciously going to leave power supplies back at the desk: walk in and flip open the lid, ready to start.

I’m not even going to try and debunk the “macs are more expensive” myth. Given all of the above, even if you thought there was a premium for the Apple brand and hardware sexiness, the delta can still be justified by all the other gains.

According to Larry Wall, the first virtue of a programmer is laziness:

The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don’t have to answer so many questions about it

I attribute this virtue to Jeff Hertzberg and Zoë François, authors of Artisan Bread and Five Minutes a Day.  They went through all the tradition and legend of artisan bread baking, questioning everything, and reduced it to its essence, and then documented it for the rest of the world.  

Unlike all those Dummy books that promise to let you learn X in 24 hours, this book lives up to its title.  It really is 5 minutes a day, and you’ll always have amazing bread to go with your meals.

Amy and I are mere beginners in this endeavor, but nothing has come out less than excellent in our tries.  The folks we share with are all suitably impressed, too.  If you don’t have the book, we highly recommend it, and giving it a try.  

As disclosure, a co-worker of mine, Graham, is married to Zoë.  Other folks on the team have tried this and give equal reviews.  It’s fun to hear his stories of the runaway success of the book.  She also has a blog, covering more details and other delectable edibles.

Abstract: A primary disconnect of GTD systems is that they are more interested in the data than the actions.  

As an analogy, let’s pretend you are are tasked with starting a new rocking chair manufacturing company. Would you rather have

1. A pre-designed assembly line that had all the jigs and supplies for the steps involved in building your product, or
2. A Norm Abrams-style workshop (à la New Yankee Workshop) where you have every imaginable high-end tool needed to craft anything out of wood?