That's my immediate reaction watching these programmers argue about what color their comments should be when reading code. It seems those who write sparse comments want them to pop out of the screen, and those who comment more heavily like to provide a background hum of human commentary that's useful to read in certain contexts and otherwise easy to filter out.
Now that I think about it, this matches my experience. I've experienced good codebases commented both sparsely and heavily. The longer I spend with a sparsely-commented codebase, the more I cling to the comments it does have. They act as landmarks, concise reminders of invariants. However, as I grow familiar with a heavily-commented codebase I tend to skip past the comments. Code is non-linear and can be read in lots of ways, with lots of different questions in mind. Inevitably, narrative comments only answer some of those questions and are a drag the rest of the time.
Comments are versatile. Perhaps we need two kinds of comments that can be colored differently. Are there still other uses for them?
Every few days I'm on IM with some coworker from a different building. The conversation goes something like this:
Them: Lunch? (6 minutes) Me: Sounds good! Meet downstairs? (1 minute) Me: Now? (2 minutes) Them: Yes! (1 minute) Them: You there? (3 minutes) Me: Oops, sorry. Heading down now.
Now I never know whether to wait for a response, or to run down because I'm already late. But today I finally figured out the answer:
Me: New rule. Head down when both of us say 'ready' within 1 minute of each other.
That's it. No more ambiguity. It's kind of a silly example, but the general idea feels deep, complementary somehow to exponential backoff. Exponential backoff is the ideal game-theoretic strategy for competitive situations where two people need to contend for a common resource, like trying to call someone back after a dropped call and getting a busy signal. Both try to diverge away from a network-defined window of conflict by waiting longer and longer. Here both parties are trying to converge into an agreed window of agreement. Defining the size of the window by diktat should be handy anytime two parties (people, computers, ..) need to cooperate synchronously atop an asynchronous channel.
Idiomatic rails action for registering a user if he doesn't exist:
After a year of programming in lisp, I find it most natural to write:
Is this overly concise/obfuscated? I like it because it concisely expresses the error case as an early exit; most of the space is devoted to the successful save, which is straight-line code without distracting branches. It's clearer that we either pick an existing user or create a new one. Form follows function.
Two of us have been building hackerstream, a real-time UI for Hacker News that a dozen addicts have been using since March. This won't matter to you if you don't frequent HN, or even if you swing by just once a day. But try it out if you go to HN every couple of hours like I do. You'll see comments on all the stories on the entire HN frontpage as they stream in. You can slice and dice the stream by story or by author. You can even set it up to highlight, say, all comments by security guy Thomas Ptacek and all comments about today's silicon valley brouhaha. If you use Twitter the UI will seem familiar.
Is such a firehose useful? Is it too much of a good thing? I find I see more of HN for the same time investment, and I waste less time scanning stories I've already read. What's more, when I started using it I found my comments getting more votes and more responses. It turns out the biggest factor affecting responses is not how good my comment is but just how early it shows up on a story. By biasing my reading to be more timely I was giving my few comments improved odds of a response.
You run a startup. Your company has been given data by users, data that it would be embarrassing to lose. You make backups. You're aware of the best-practices:
This paranoia is useful, but it's intended for personal data. For business data it's incomplete. Businesses have automation. Lots of automation. Dumb automation that can do stupid things, like corrupting data. Businesses also develop nooks and crannies where important data may go unread for periods of time. The combination of automation and dusty corners can cause insidious data loss: some obscure-yet-critical corner of your data gets deleted or corrupted, and you don't notice until the corruption has infected the backup copy.
Stale is good
You can guard against catastrophic data loss with just a regular backup at a remote location. Insidious loss is harder to guard against. Insidious data loss is the reason companies have more than one backup, the reason journalled file systems have multiple .snapshot directories, the reason slicehost and linode provide a daily and a weekly backup. Daily/weekly is perhaps the simplest backup cascade. It gives you a week to detect corrupted data in your server. As operations get complex you'll want longer cascades with more levels. The lower levels backup frequently to capture recent changes, and higher levels backup less frequently as a cushion to detect data corruption.
Whatever your backup strategy, ask yourself what it can't handle. I can think of two scenarios cascades can't handle: extremely insidious corruption that doesn't get detected in time, and short-lived data. If many records in your database get deleted everyday, most of them may never make it into a weekly backup.
As a teenager it drove me crazy that my father would never apologize to me. Ever. Even when something was obviously his fault. I swore to myself that I would be more intellectually honesti, that I would admit when I was wrong. That emphasis on intellectual honesty gave me a scientific bent and took me to engineering college, and to grad school. For 12 years I unquestioningly assumed the virtue — and importance — of intellectual honesty. Coincidentally, I also spent most of those years working alone.
Now that I've worked in teams for a while I'm starting to change my mind. In many social situations being apologetic sucks. It makes others around you feel awkward. If you're leading a team it makes you seem weak. If you're the rookie you sound like you're making excuses. If others aren't intimately familiar with the details it can magnify your screwups and make things seem worse than they are. And always it's a distraction, diluting your focus and that of your team. I'm learning to not apologize until it's clearly expected. Better to err on that side.
All this may seem crazy obvious to you. Apologizing isn't really part of western culture. I can remember others telling me dozens of times, "don't apologize." Somehow it never sunk in. Perhaps it's not even an eastern thing, just a personal fetish.
Looking back, I have a different perspective on my father. I realize he was an army officer who spent much of his day telling subordinates what to do. You can't be apologizing in that situation. You just don't think about whose fault it was, because the entire focus is on adjusting to a constantly-changing situation, and on what needs to be done next. I want that mindset.
Q: Most people find it morbid for someone young and healthy to think about their death.
me: I can never understand that. I am accomplishment-oriented rather than experience-oriented. I derive daily motivation much more from having a sense of accomplishment and impact on the world than from experiential pleasures, or even from having learned something. If you feel the same, it behooves you to think about the impact you will have on the world after you're gone, and how to best channel it. It's only experience that ends when you die.
A lot of 'getting better at TDD' is just getting better at listening to yourself. When I started programming the little anxieties would pile up until I'd painted myself into a corner. With experience I pay more attention to the little anxieties.
The secondary effect: after some time doing TDD I feel less anxious just knowing that I can write a test if I want. The benefit of the tests as an artifact is secondary to me; what they primarily do is keep me from getting stressed and giving up to go play poker.
Writing tests becomes more important when you're part of a team. Your
choices affect not just your anxiety but that of your teammates. That's why
it's reasonable to be more dogmatic about TDD in a team.
I've been increasingly using friendfeed, and the number of my subscriptions has trended steadily down. The reason: ordering by time forces me to be strict in who I let in.
Every new watering hole for conversation — facebook, google reader, twitter, friendfeed — orders my reading by time to provide immediacy. Ordering by time renders it susceptible to frequent posters. The minute I subscribe to one, the diversity of my reading goes down. Other voices become hard to find. My response to this: never subscribe to frequent posters.
But this is a blunt heuristic. High-volume sources often have great posts. As the need for other views grows, I find coping mechanisms. Sometimes I give up and leave. Sometimes I build a replacement, and sometimes I find others have done so. Once I can get around pure time ordering, I heave a sigh of relief and subscribe to the people I want to without feeling constrained by volume.
So, friendfeed, please help me navigate this stage of my reading. Find ways to keep my reading diverse, even if I subscribe to Robert Scoble.
Lu Liu: How can we use serendipity to get out of homophily traps? I have a serendipity friend list. But if I can define my serendipity friends, then I guess they are not really serendipity friends by my expectation. In reality, I seldom read articles from that list.
Me: Yes, a serendipity list can't come from yourself. It must be an external recommendation. Automated since that's my bias :)
Time is key. What is serendipitous today is not so tomorrow. That makes it harder to 'define'. In practice, I suspect we must evaluate it like we evaluate porn: not by defining it but by categorizing examples.
Perhaps it can't be a list either, just one recommendation, with pride of place. I find I require time to appreciate something outside of my comfort zone.
Since it must take prime real estate it must be high-confidence. If nothing is good enough today, show me nothing.
Finally, it mustn't nag. Make it easy to dismiss, use the dismissal as a signal to learn from.