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.

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?

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.

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.

I regularly delete some of my unit tests, sometimes within minutes of writing them. Even as a TDD fanatic I’ve come to realize tests are just a means to an end. If I decide to write a constructor test when first designing a bit of code and delete it a few minutes later, nothing’s wrong. These sorts of initial tests can become redundant quickly since to you have to construct the object for all the later tests.

As you adjust to TDD there’s a tendency to see the tests as important code. Deleting them is the last thing you’d think of doing. It turns out just like with production code less tests are better easier to maintain and easier to refactor. And as an added benefit your test suite runs faster. Tests are path to good code and you get an added benefit of a regression suite. And besides everyone’s favorite checkins are ones where you remove more lines of code then you add.