Here are Pivotal we call our time between billable projects “the beach.” We spend most of this time working on projects which are internal or open source, sometimes both. One such project is Project Monitor and on my last go-round on the beach I got to work on it with my long-time colleague Mr. Saracco.

Project Monitor is a quick way for a team to see the status of their test suite. It’s basically a board of tiles, one for each test suite, colored either green or red depending on the current state of the build. It’s an interesting app to work on because it’s used in every Pivotal office and it’s part of our daily lives. It’s fun and it feels rewarding to work on something you see out of the corner of your eye every day. It’s also a little nerve-wracking. If you break something, every one of your co-workers knows!

Project Monitor has historically been a bit of a tangle. Frequently, a Pivot or two has a week or less on the beach and they’re tasked with implementing some new feature or fixing a bug and then they’re off on another project. Digging through the codebase, you can see there’s some baggage. Maybe there’s a beloved tool from a previous project, a half-used framework, or a–ahem–clever use of code. Not always, but sometimes, these things trip up the next developer.

A fundamental truth about code is that it has more than one audience. We often think of the compiler or the interpreter as the end consumer of our code, and of course that’s true. But it’s easy to downplay how important it is to think about the next set of eyes on your codebase. Even if you have no collaborators and develop your software in a sound-proof bunk, you have in the very least your future self to communicate with.

My biggest lesson from this go-round on the beach is that it is exceptionally important for open source software to code in such a way that optimizes for quick developer ramp up. This means writing code where intent is clear. It means minimizing dependencies so as to shrink the number of necessary technologies for a developer to additionally ramp up on. It means nice, clean commits with clear logs. In short, it means having a boatload of empathy for the next person reading the code.

On a private project with a small, tight team, there’s plenty of leeway. Someone with some history can just explain code that a new dev finds confusing. There is usually no such luxury on open source projects. Furthermore, the lifetime success of your project may be determined by willing members of the community standing up and pitching in. The next person to look at your code may not have any context at all. They will wake up, Memento style, and only see the code at hand. They do not have the history you do.

When you’re doing open source work, lease, please, please think of the next developer when you reach for that shiny new gem, that clever piece of meta-programming, that half-adopted convention.

Stand Up [NY] 02/08/13: Snowpocalypse Wow… or the Snowpocalypse That Wasn’t
Johnny Mukai & Daniel Grippi

Interestings

Rake::Task[:name].enhance

(from Dave Goddard)

If you wish to change the pre-requisites for rake tasks, or add functions to run after them, then you can use

Rake::Task[:name].enhance(PRE-REQS) do
STUFF AFTER
end

Window Function: lead and lag

(also from Dave Goddard)

If you have records with only start dates, and you want start and end dates, there is a great window function called "lead", which will give you the next value in the group. eg.

id | person | start |
1 | 1 | 123 |
2 | 1 | 456 |
3 | 2 | 234 |
4 | 2 | 567 |

then running

SELECT id, person, start, lead(start) OVER(partition by person ORDER BY start ASC) as ended;

will return

id | person | start | ended |
1 | 1 | 123 | 456 |
2 | 1 | 456 | NULL |
3 | 2 | 234 | 567 |
4 | 2 | 567 | NULL |

PS. using postgresql 9.2 ranges can make the answer even more fun.

Last week an article that touched on a popular stereotype of the nocturnal programmer was published at Business Insider. Articles like this are always popping up from time to time and they tend to cause some controversy among programming communities–probably because one programmer’s dream work environment is another’s distracting hell.

I wish I had some deep insight into why the internet is overrun with articles like this about what makes for a productive programmer. I think simply that the nature of writing software is not well understood. What we do is tough to categorize. It’s not like classical engineering, we’re not calculating the tensile properties of metals and then building a bridge or an airplane. It’s not art. Maybe programming is a craft.

Articles like this that chase after some enigmatic insight into the secret of programmer productivity remind me of a lot of specious advice for fighting writer’s block. Lock yourself in a room, naked, with nothing but a typewriter. Pay someone to slap you when you stop writing. Whenever I come across this kind of advice I’m reminded of this canonical Chuck Close quote:

“Inspiration is for amateurs; the rest of us just show up and get to work. If you wait around for the clouds to part and a bolt of lightning to strike you in the brain, you are not going to make an awful lot of work. All the best ideas come out of the process; they come out of the work itself. Things occur to you. If you’re sitting around trying to dream up a great art idea, you can sit there a long time before anything happens. But if you just get to work, something will occur to you and something else will occur to you and something else that you reject will push you in another direction. Inspiration is absolutely unnecessary and somehow deceptive. You feel like you need this great idea before you can get down to work, and I find that’s almost never the case.”

I imagine most anecdotal accounts of productivity tricks boil down to this: “this is what keeps me putting one foot in front of the other.”

What a convenient segue!

A bunch of us in the NYC office have a goal to get more blog posts under our belt this year. (Why, you ask?) To that end, we’ve begun an “iron blogger” group this month. The concept is simple: you buy in with twenty bucks and if you write a blog post by the deadline, you get it back. If you don’t, your cash goes to the group. There’s more than just a small financial incentive, though; there’s social pressure, but also the excuse to just ship whatever half formed ideas you have in your drafts folder (he laughed, nervously.) The point is to write–to write poorly, even!–to screw up and miss deadlines and live to write again. In other words, the purpose of iron blogger is to encourage us to keep putting one foot in front of the other.

Interestings

Extending Paul Irish’s comprehensive DOM-ready execution (from Nicholas Greenfield)

A cool pattern for including Javascript in your app based around controller_name/action

http://viget.com/inspire/extending-paul-irishs-comprehensive-dom-ready-execution

Teamcity Formatter (from Dave Goddard)

At some point in v7 (possibly 7.1) Teamcity created a formatter which is much nicer to use

http://confluence.jetbrains.net/display/TCD7/Build+Script+Interaction+with+TeamCity

an example is that there is now a FlowId which lets you output from multiple processess/threads and let Teamcity deal with the demuxing.

Interestings

Gem Licenses Exposed on rubygems.org

While working on LicenseFinder, Matt Parker, Ian Lesperance, and David Edwards contributed a patch to rubygems.org to show gem licenses on gem pages. That patch has now been merged. https://github.com/rubygems/rubygems.org/pull/458

If you browse to a gem version page on rubygems.org, you’ll see a new “Licenses” section. At the moment, this will show “N/A” for most gems, but as people begin to push up new versions of their gems, and as more gem authors set the licenses metadata in their gemspec, you’ll start to see gem licenses.

Gem::Specification.new do |s|
  #....
  s.licenses = ["MIT", "BSD-3"]
  #....
end