Timely Pull Request Responses

I contributed some pull requests this year to several projects including the classic Jenkins Chuck Norris Plugin. Some of them were accepted quickly, others had a bit of back and forth and a few sat for months. My pull request for the Chuck Norris Plugin attempted to fix an issue where the large Chuck images no longer showed up because Jenkins had changed its’ layout design. It took diving back into some Java and brushing up on Jelly templates to figure out what was going on with the bug. After some testing I submitted a pull request and hoped to be able to integrate the fix soon after.

That was December of 2014. The fix was finally merged in November of 2015. I don’t have any negative feelings about it. People get busy. It’s open source.

At some point people get bored with projects, move on, don’t have time, or they don’t work in the language anymore. I think there’s two reasonable ways to handle this:

  • Hand off maintainer duties. It’s the best option if you have someone interested in taking over the project.
  • Post your explanation for not updating the project on the README to let them know pull requests and issues probably won’t get any attention. Then someone who cares enough can fork it or at least it’s use will slowly dwindle down.

In the Chuck Norris case they got a new maintainer, and my little fix is finally merged in and released.

RailsBridge Sacramento

I volunteered to help out as a TA for RailsBridge Sacramento this past weekend at Hackerlab Sacramento. We had 60 people show up to build some Rails in one day. Many of them were brand new to programming or Rails. My section had a lot of people with some development experience in other languages like Java, C#, C, or Scala.

The energy level and overall interest was great. I taught Oracle Java classes years ago and sometimes the majority of the class was only there because their managers made them attend. Teaching disinterested people is stressful and not fun. Even though they were giving up a Saturday almost everyone stayed and coded through the entire day.

As a TA I rotated among people nudging them in the right direction, troubleshooting errors, explaining Rails and Ruby idioms, and discussing the local job market. My only break turned out to be the pizza lunch but I was working off the energy of all these motivated people. Everyone in our group got through the main exercise and built a simple Rails app and got the chance to add extra features like a login with Devise. And even if most of them never build another Rails app they can carry the paradigms that are common in many web frameworks like migrations, integrated REPLs, generators, templates, and ORMs.

The diversity of the group exceeded by assumptions. It’s refreshing to see that the next generation of developers won’t look like the current white male majority. It was rewarding to explain to many people how they could approach breaking in or breaking back into a development job by just showing some motivation and the ability to learn. Hopefully some of the attendees will some day bootstrap more underrepresented groups into software.

Why Isn’t Remote Work Common in the Bay Area?

As working remotely especially as a developer has become easier over time, I still see a lack of any real remote work in the Bay area. Despite a very expensive living expenses, office space, and almost zero unemployment among developers, companies rarely seem to consider remote work. I assumed as the demand for developers intensified we’d see a corresponding interest in adding remote workers to teams or even going fully remote, especially with companies like 37 Signals and others paving the way.

The typical Bay area company is looking for on-site talent despite the cost and difficulty of recruiting. With over 20 years of experience now I acknowledge it’s nice to have a team co-located, but certainly not at the expense of having a good team. There are some incidental communication and collaboration benefits of working side by side in a room with a team, but many of these same benefits can be mimicked using technology. Some of the tools that are commonplace, cheap, or free are:

  • Remote Pairing Tools (ScreenHero, tmux, VNC, Skype in a pinch)
  • Hosted Project Trackers (Pivotal, Trello)
  • Source Control with built in Code Reviews (github, gutbucket)
  • Issue Trackers (ZenDesk, Redline)
  • Video Calls (Skype)
  • Shared chat platforms (Slack, HipChat, Campfire)

So why are we still largely living in the working experiences of the 1990s?

AgileZen Limping Towards the Drain

I’ve used plenty of project tracking tools over the years many of which I detested and a few I was OK with. AgileZen was a pleasant surprise when I came across it and I wrote a review and lobbied for using it at my current company as a Kanban style lightweight tool. It worked fine for us for a year or so, but gradually we noticed it was getting no love. The UI in tools like Pivotal Tracker were getting more responsive and event driven and AgileZen was stuck in the old request response cycle with a smattering of AJAX. Eventually it was obvious to us that it was dead software walking.

Rally Software promised that the beta would improve everything, but in the end they never released it. I’m sure it was a business decision where they didn’t see enough upside in improving it and decided to just eke out a profit with the current dwindling subscribers.

We ended up back in Pivotal Tracker which has served us well, but I still wish there was a nice Kanban style replacement for AgileZen.

Hiring In 2015 Is Hard

More than a year ago we lost a good engineer to a new opportunity. I knew that engineer would be hard to replace, but I did not expect to still be trying to hire a replacement a year later. I haven’t seen this sort of tight market for developers since the height of the dotcom boom more than 15 years ago.

We’ve had trouble at multiple stages in the recruiting process. We’ve had trouble getting a good funnel, we simply don’t have many candidates. We have a robust interviewing process for Sacramento, but probably simpler than the process many Bay area startups use. And more and more we’ve had people decide to turn us down before and even after offers. One person simply emailed us to let us know just before an interview that “it wouldn’t be in either of our best interests” to conduct the final interview. Others have let us know that our business just doesn’t have enough of world changing mission.

I’ve also seen more candidates describing themselves as architects. Almost all of them have turned out to be more in the range of mid-level developers. There was a similar overstating of skills when the last dotcom started sucking up anyone who could spell HTML.

I don’t have any solutions to our year long hiring failure, but it’s time for us to try something different.