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.

Deleting Unit Tests

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.

Lunch for Integrating Teams

Lunch is a funny thing for many developers. With a tendency towards introverts often people get into habits of eating alone either with food from home or just running out to pick something up and bring it back. Lunch as a social outing is a bit unusual and unexpected.

I’ve viewed eating with others as one of my favorite parts of the working day for a long time. Even when I work remote I often schedule lunches with former colleagues or friends to keep up with them. At my present gig I work in the office Mondays, Tuesdays, and Thursdays. Tuesdays are a company sponsored team lunch which has been a great way to get everyone out eating together. Mondays and Thursdays I typically get a bite with another one of our developer teams. I enjoy the conversations and it’s a free way to keep up with another team and explain what’s going on with our project. I know there’s a small cost involved in eating out, but it’s only two days a week and far outweighed by sharing knowledge across the organization. And I do like to get out of the office.

So if as a developer you tend towards the lunch from home and eating at your desk, try out lunch out with some co-workers at least once a week. It’s a cheap experiment and a great way keep up with your organization.