Joyful Coding

From the redis manifesto:

"We optimize for joy. We believe writing code is a lot of hard work, and the only way it can be worth is by enjoying it. When there is no longer joy in writing code, the best thing to do is stop. To prevent this, we'll avoid taking paths that will make Redis less of a joy to develop."


A developer is only as good as his commits

As a developer I've found new appreciation for the adage "a man* is only as good as his word."  In business and in life, you can't depend on people who don't follow through on promises, especially when stakes are high.

Amongst programmers, our code is our word.   If collaborators can't trust that our code is of high quality, we are effectively a time and energy sink for those around us, forcing on others the task of testing and validating our work.  The analogue in the non-tech world would be someone whose promises require second guessing, backup plans, and a non-trivial dose of anxiety.

A developer that pushes high-quality commits, like someone who follows through on his or her word, is a refreshing person to interact with, because the cost of interaction is negligible, making the net value of all contributions significantly higher.

Push good code.

*note:  excuse the gender bias in the quote - fortunately women are better with promises and code commits

Canned interview problems are fundamentally flawed

I always hated "programming problems" when I was interviewing for jobs. I now also hate them as someone who is trying to hire programmers.

As a candidate, I felt like these kinds of problems had little relationship to real work. How often do I really need to find the number of ways that one could walk down a set of stairs (a classic recursion interview question) or what floor an egg breaks on? (nice one, google)  And what am I supposed to do if I already know the answer? (which was often)  There are multiple levels of weirdness at play -- not exactly what I call enjoyable.

As an employer, I hate them for an entirely different reason. My objective during an interview is to find out two things:

a) is this person smart
b) can this person work well with our team

Canned interview problems may given you the answer to (a), but they do so at the cost of having any chance of knowing (b).

By giving them a contrived problem that I know the answer to (and they know I know the answer), I've immediately forced an artificial interrogation-style power dynamic between us and likely amplified their anxiety by a couple orders of magnitude. My goal is to get as far away from that dynamic as possible.

To the best of my ability, I want to simulate an hour or two of work and see whether we can collaborate effectively.  Here's the rough approach I've worked out so far, comments are appreciated as I'm pretty new at this myself:

  • Have them share a personal project with you, it doesn't have to be of epic proportion, just something they're working on.
  • Talk through some of their code during the interview if possible. This can give you both an idea of what a code review will look like.
  • Have them explain any problems they are having, and see if you can help. This informs whether you will be able to collaborate on projects they own. 
  • Walk through some of your own code and explain some of the problems you've been having. See if they have any insight and whether you can brainstorm together.

In both cases of reviewing your respective work, you are admitting that you don't know the answer to the problem. In the case of your own problem, you're also admitting that it's something you could use help with.  You have now mitigated the power dynamic somewhat, which means the candidate can feel comfortable in throwing out ideas. You've moved from waiting for the "right" solution to asking for ideas on a real problem.

You come away with a good indication of their ability, as well as a decent indication for how well you would work together. And a possible side benefit may be new insight into the problems that you're struggling with.  It takes a little extra courage to fly without a net, but that's the whole point - leveling the field so you can actually talk.

If this sounds sane to you and you're looking for dev work in San Francisco, please get in touch.

Safe Access for Temporary ActiveRecord Fields in Rails

I run into a fairly common problem in rails views when I'm pulling data from multiple tables.  To optmize on db access, I use :select to pre-load the data from the joined tables.  For example, let's say I want to list all users with their respective cities:

Then I don't have to load the Address model to display a user's city:

The problem is that my user partial is now coupled with my named scope:  if I render the partial without using the scope, I'll throw an exception.  To avoid the problem, I add an accessor method to the User model that will pull the pre-loaded data if available, and revert to using the Address model:

The partial will be inefficient, but I'd prefer to find the error when profiling view times rather than through exceptions.

Prompting for Facebook Permissions

When authenticating users via facebook, you have a laundry list of possible permissions to ask for.  If you ask for no permissions, the user gets the following login window:

Any requested permissions get displayed in the login window, but some of them get grouped into the same permission category. For example, many of the user_foo privileges get grouped into "Access my profile information", and similarly, friends_foo permissions get grouped into "Access my friends' information".

Below is a screenshot of what it looks like when asking for the full suite of permissions (I used the helpful Rell application to test). From this you can get an idea of what it looks like to the user based on which permissions you're asking for.

Asking for all permissions at once would be a little intimidating for users . . .