My edit was really minor, but seeing this still makes me happy:
My edit was really minor, but seeing this still makes me happy:
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."
Amen.
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
A case study of the physical world bleeding into the technical . . . and a case study in idiotic StackExchange questions.
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 smartBy 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:
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.
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.
. . . so much for Javascript fallback.
This functionality is included in some ruby gems (Utility Belt seems to be the most popular), but I'm more of a "roll-your-own" kinda guy. Not to mention that the gem is a little overkill for printing out command history.
Here's what I came up with:
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:
Asking for all permissions at once would be a little intimidating for users . . .
Confirming the email alert I recently received, Google appears to be strategerizing in social with a renewed push for Orkut: it's listed on page 1 of their new products page (despite launching in 2004).