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

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.