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 you 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.

Local Tmux Usage

My team finally convinced me the efficacy of using tmux locally even without doing remote pairing. I run quite a few sessions to organize my work at different times:

  • work (generally main vim window for the day job)
  • web (It’s web development so always running a web server)
  • login (A trick to keep the lame Cisco VPN client from kicking you off every 15 minutes)
  • qa (for running capybara tests primarily)
  • elixir (messing with elixir)
  • clojure (messing with Clojure)

During the work day I generally have web and work up and login and qa detached unless I need them. Then at home I detach everything and just use elixir or clojure. I don’t use a lot of windows for each session or panes, unless it makes sense say auto testing and code or code and REPL session. Generally I leave these sessions in place unless I have a rare reboot. Nothing world changing, but it’s just a bit better than my old way of keeping up a terminal with a bunch of tabs.

Evolution of a User Group

My favorite current user group is the Coder Consortium in Sacramento. It covers generally new languages or less popular older languages. The evolution happened over the course of several years. Originally the core of the group was a bunch of Java devs who were a bit disgruntled with the language and the frameworks and the whole Enterprisiness of it. A few of us started messing around with Groovy and Grails, especially given we couldn’t find paying jobs doing Ruby yet. Eventually we decided to start up a Groovy User Group.

The Groovy User Group ran for a few years overlapping with a large number of JUG regulars. We were able to try out some new tools and experience things like Spock or Griffon. Gradually though we noticed members experimenting with new JVM languages like Scala and Clojure. As that trend became more prevalent, we jokingly referred to the group as the Alternative JVM Languages Group.

Finally, about a year ago we morphed into the Coder Consortium. While the name may leave something to be desired we fully embraced newer and unusual languages both on and off the JVM. We tried to do an into to 10 languages in 2 hours, but I think we made it through 7 or so. And next week we’re lining up a talk based on this paper comparing a number of languages in Github.