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.

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.

Phone screening junior candidates is hard. With 20+ years of experience I find it hard to evaluate someone who’s new to the field or worked less than 6 months. What I’m looking for is potential, but I can’t fall back on traditional measures where I ask for evidence of a skill. Sure they might have a beginning grasp of some language or the ability to put together a bare bones web site or iPhone app, but I really can’t drill them on OO, Domain Driven Design, or functional programming.

My approach has been to touch on some real basics to determine they’ve at least been exposed to subjects they claim on a recipe. Then I dig for stories of how they picked things up, what they learned from mistakes

Step one, is read the resume. They tend to actually be one page! Note anything I should ask them about such as basic language syntax or their explanation of TDD. Second, is take a look at any open source code you can find, often github. Ignore that it’s sloppy or untested and just take a good look at it. Then if you have time you can do some Googling and see what kind of data you can find about their participation in the community or even just questions on forums or Stack Overflow.

Next comes the actual phone screen itself. I have a stable of questions I use, a few I always use and many that I sample based on the interviewee’s experience:

• What have you done in 2 minutes or less? (I’ll let this go over 2 minutes if I’m getting good information, but sometimes you just have to tell people you need to move onto the next question.)
• I usually warm up with a question about the disadvantages of inheritance. This often throws junior candidates, but you can get a pretty good sense of how much OO they really understand this early in a career.
• As I’m a die-hard TDD/BDD type I always ask them to describe how they’d write a test in their current unit test framework. A surprising number of resumes that claim to practice TDD can’t explain the syntax behind writing a rspec or Junit test.
• I’ll often ask a question about a situation where they didn’t have enough information to complete an assignment and how they handled that. Sometimes this sort of behavioral question throws junior developers and I have to reiterate that I’m not looking for a theoretical answer.
• Then I’ll jump around from behavioral questions to technical questions. I might ask about what an index is or what they find most challenging about their current project.

• Almost always I include a question on how they come up to speed on new technologies. I’m looking here for anything they learned that wasn’t just presented to them in a class or at their job. Finally I wrap up with a few standard questions: </ul>

• Why do you want to work for us?
• Is there anything else I should ask you?
• What questions do you have for me?

Every few months I come through the questions and usually add a few and remove the ones I never ask. I still wish I had a better process, but the most common theme to come out of junior phone screens is that they’re enthusiastic and they know at least what they claim on the resume.

Developing on the Mac has generally been an awesome experience over the years especially with OS X and the UNIX underpinnings. The long pain point in this area is the lack of a solid supported package manager. It’s not in Apple’s DNA to worry about power users who actually use the terminal, and they’re unlikely to ever consider it important enough to delegate resources too. MacPorts and its hipster cousin Homebrew have been around for a while, but they’re always a bit rough around the edges, missing packages here and there, old versions, and sometimes they need extra tinkering just to install. In all it’s a most un-Mac like experience.

I don’t know that it will ever happen, but I know I’d support a Kickstarter that promised to maintain a Mac package manager like rpm or apt for OS X. I don’t care if they use Homebrew or Macports and just make it more robust, or build a new one from scratch. I’d just like a simple install of all those open source libraries. Yehuda Katz did a simple installer for Ruby and Rails on OS X a few years back via a Kickstarter, so I know there’s precedent and this would impact a lot more developers. Saving hassle is certainly worth some bucks for a kickstarter.

I just chuckled when the I got the following email from a recruiter:

Are You Down With ATG???

Brilliant targeting as ATG barely survived the dotcom implosion and limped along before finally being sold off to Oracle. Given that almost any ATG developer would have been working in the late 90s, a reference to Naughty by Nature’s OPP was a great hook. Sadly I have zero interest in returning to work on a failed app server product, but I love the effort.