Garbled

Whenever we interact with the world, we use cognitive shortcuts. It’s handy, you know. We make assumptions about our environment so that, if we’ve guessed right, we can respond appropriately to our environment more quickly as it changes. It’s a survival technique.

However, it can sometimes get us into trouble, especially socially. We see someone dressed a certain way or giving some other kind of social cue and we assume other things about them. Most of the time, this works brilliantly; they’re sending those cues on purpose and we’re supposed to interpret them the way that we do. Or they’re not sending those cues on purpose, but they’re identifying with a group and so our reaction is still appropriate.

I have a hard time, sometimes, in social situations. I have had to learn, via careful and intentional observation and memorization, many social conventions that it seems others picked up earlier, easier or more instinctively. So I’m somewhat sensitive, now, to the social cues that others send. Which is to say that I’m more consciously aware of the ones I notice, not that I notice all the little ones; the fact that I have to consciously process them slows me down and I miss many cues because of it.

I struggled, for a long time, with the fact that others often acted as if I understood some cue I’d missed (a reasonable assumption on their part, statistically speaking). And I realized that I was sending as many “normal” social cues as I could in order to fit in (my younger self was less comfortable being a huge nerd than my present self). But this meant that people were under the impression that I conformed to their expectations… I was basically lying to them.

So I set about trying to find some things I could do that would indicate to someone that they’d be best served (assuming their goal was to communicate effectively with me) being fully mentally engaged, rather than on auto-pilot. When i first had this idea, I also had the idea that I was special and different and so more deserving of people’s full attention. I’ve since become a bit more humble in that regard.

I don’t want to get into a whole ton of detail about my personal expectation breaking journey. I want to come to my point, which is this: I wanted to break people’s expectations so that they’d have a “What?” moment and hopefully clue in that something new or uncommon was going on. Instinctively, I knew I shouldn’t go _too_ far off, but it’s not something I realized until recently.

Whether it’s yourself or a product or brand, I think people often want to break expectations. And I feel like people hand out that advice a lot. It’s decent advice, too. However, it’s one thing to wear funny socks or something and another to dress in a gorilla suit every day. Funny socks are different enough that people will look at you oddly, but still feel like they can have a conversation with you. A gorilla suit is so radical that many people will assume they can’t cope to the difference, whether they’re right or wrong.

The analogy that popped into my head when I initially thought of this was a window. If you want people to see you (assuming you’re transparent, like, you know, a window), then you might think that cracks would help. I certainly notice a window with a crack more than one without. But if you apply too much force, you’ll shatter the glass and there will be gaps in the window and jaggey bits that people are afraid to some too near, etc. It’s a much more upsetting experience. I guess my advice on the topic (for those that want it) is this: Break expectations if you like, but apply light pressure so you don’t shatter them.

In light of my last post, I got to thinking some more about old school hackers. Also, at my job, we’ve got some people who’ve been here a long time. One in particular, we’ll call him Steve, is very smart, but… And, see, that’s sort of the thing: I can’t put my finger on it exactly. Steve is blazingly smart. But there’s clearly a difference between he and I that isn’t, I think, just accounted for by the 20 or so (I’m guessing) year difference in our ages.

If I see something I dislike—something that could be better—I really want to see it change. I want to be involved in that change if not driving it. Steve is often watching and present. He’s paying attention mostly and if you ask him a question he’ll have an insightful answer. If someone proposes a change that’s actually a good one and addresses a real problem, etc. etc. he’ll be glad the change is coming. But he never pushes for it. He never starts a conversation (in the wider sense, I mean; he will say hi to you in the hall or whatever) and hardly chimes in unless addressed directly.

And I think Steve fits a sort of archetype. He’s very interested in low-level details (well, actually in almost any kind of technical detail). He seems to be pretty much interested in being left alone and tinkering in his shop to see how things work (to use a light metaphor, here). If something is bad or less than optimal for other programmers around him (and including him), he’ll either ignore it or work around it on his own. His solution wont be general enough to apply to everyone, though and he wouldn’t publicize it. He’s very internally focused. And I associate this stereotype with older programmers or, more accurately, with old school programmers (how long have you been coding, not how long have you been alive).

On the other hand, I think think there’s a newer breed of programmer that’s becoming or has become very common. And I want to be very specific, here: I’m talking about hackers; folks who code because they enjoy it, not those who do it because its their job. People who would code to solve computer-related problems they have at home even if they were a news anchor or a trail guide. This new breed is more externally focused. We want our solutions to problems to be useful to other people. We want to have a conversation and (often) change the way things are done (for what we see as the better). We want powerful abstractions and like to live up away from the metal, generally.

I haven’t cataloged all the differences and, in particular, I’m having a hard time figuring out the attributes for my “new breed” of hacker are. Of course I’m talking about generalizations and stereotypes, here, but I don’t think that’s intrinsically bad. Basically, I get a sense of a certain amount of cohesion in personality type and behavior in these two groups and it struck me as interesting. What do you think, am I drawing a distinction where there is none? Is this distinction useful for anything? Is there some interesting point I’ve missed?

You frequently hear (or I do, anyway) the advice that if you’re unhappy in your coding job, you should scratch your own itch, work on what you love… Work on something you’d be a user for. Because then you don’t have to do a bunch of requirements gathering and get them inevitably wrong, etc. etc. The idea seems to be that if you love the business process, you’ll love working on the code that enacts it. And, well, that’s fine. It seems to make a lot of sense, on the surface. But then I thought about history.

As programmers, we don’t have a lot of it (compare auto workers or, say, masons). History, I mean. But there’s some and in the days of Mel and COBOL Cowboys, things were different from what they are now. Today we have all these powerful abstractions and high level languages. Folks (well, not all, but many) consider it to be ideal if you’re basically writing your code in a DSL specific to your business process. Which means your code is really tightly coupled to your business (on that layer, anyway). I don’t know that that’s a bad thing at all (in case I sounded critical). I just want to contrast it to what came before.

Those dudes were almost just writing ones and zeros. They were so far removed from the business processes they were enacting and the folks who were using their stuff that I wonder how much impact it had on them. Would Mel have been any more or less happy writing financial management apps for large companies than solitaire? I kind of think it wouldn’t have mattered to him; he was in it for the code and playing with numbers. He enjoyed all that low-level stuff.

So I wonder, is our (figurative us, here) unhappiness when dealing with business processes we aren’t personally invested in a symptom of all of our awesome high level languages and nice abstractions?

I have a lot of online identities. Who doesn’t these days? I’ve got a gmail account, which means I also have a gchat account and that account can also double as an OpenID. Because I got on the bandwagon before Google did, I have a different OpenID. I’ve got an AIM account (well, one active and a few that’ve atrophied over the years). I’ve got a Twitter account and an account at Hacker News and one over on the GURPS fora and an OtherInbox account and… a ton of other sites. Sometimes, it’s all a lot to keep track of.

However, sometimes they get conflated in ways that annoy me. For instance, especially since getting hooked into OtherInbox, I’ve protected my gmail account a lot. I route to it from several @benhamill.com addresses, for instance. And, really, it’s harder for other people to remember my picked-it-because-of-a-crowded-namespace-username at gmail.com than it is to remember my-first-name at my-full-name.com.

However, the circle of people I give my (or an) email address to is different from the circle of people I want to chat with over AIM (and is certainly different from the circle of sites I’d want to sign into with an OpenID). So I have warring desires: I like having an XMPP chat account now that I’ve used gchat and I wouldn’t have tried it if it hadn’t been handed to me, but now I wish it were a different account (so I could disclose my chat id, but not my email address). Problem is, now that I’ve got people used to that identity in that format, the overhead for switching is somewhat high. Also, there’s the convenient merging of contact lists that Google does for me (probably possible with different identities, but certainly not as easy).

So, if I didn’t have an OtherInbox account and I didn’t have a separate OpenID: just my gmail account… I’d be (tacitly) giving my email address to people I wanted to chat with and websites I signed into with OpenID, I’d be giving my OpenID and email address to people I chatted with, etc. That seems… bad to me. Am I being paranoid? There’s a balance, here, between lowering the bar of entry (“Want to try out New Thing X? Easily done: you already have an account.”) and separation of concerns. What’re your thoughts on the topic of identity management and separation thereof?

There’s been tons of hoopla about these slides that some guy showed at GoGaRuCo . Seriously, so much hoopla that I’ve been unable to absorb the guy’s name (note: I have a really, really hard time with names as it is, so…). Also so much hoopla that I don’t even really know what to link to so that people will have an idea of what I’m talking about if they don’t already. I guess _why did a decent job of explaining it by not explaining it. The short story is that there were some slides in a presentation with very scantily clad ladies doing very suggestive things. Everyone’s freakin’ blogging about it and I hate to me-too this thing, but I do want to express a thought I haven’t seen yet and I also neglected to make a post this month, which has been bugging me.

And Now, a Tangent

So in college, I played trombone in the marching band. It was good times and we had this principle that we called The Stupid. This may not make perfect sense to people who haven’t experienced band social dynamics first hand, but I’m going to try. Basically, the trombone section had a reputation amongst the rest of the band (360ish total members) for doing ridiculous, stupid things for no reason. It had been decided amongst ourselves that, rather than try to live this down, we’d just run with it. So we did Stupid things on purpose; frequently to humorous effect. I mean–we were always entertained, others were only sometimes entertained.

That was the big flashy visible part of the Stupid. We got elaborate, spending large percentages of our meager college student incomes on Stupid ideas that we planned for weeks. We went to great lengths. The part of the Stupid that wasn’t so visible was the great lengths we went to to ensure that we didn’t… inflict the Stupid on anyone who didn’t opt in. We had the goal of making so that if you missed some prank (or whatever you want to call it, not all of it was traditional pranks) of ours by a few hours, you’d never know it happened. We had varying levels of success with it, of course, but I think we did a pretty good job.

We also tried to go to Stupid lengths to be helpful to the band in general; we’d help clean up or take care of something that we saw needed doing rather than just waiting for someone else to do it or reporting it or whatever. I should point out that the directors found the Stupid highly unamusing in the way that I think is probably appropriate for teachers to find the antics of their students. Taking care of things and working hard was sort of our effort to come out net neutral in their minds and not get in hot water.

So the ‘bones weren’t nationwide (well, the Stupid did get on ESPN in the background a couple times and of course we were on TV performing at games, but not for our antics, generally), as Giles says, but we did have a reputation for being bad and (the key to being bad) getting away with it.

The Moral of Our Story

So, as things go in college, people get older and graduate and new folks come in, etc. Traditions shift and change. There came a day when some new kid was really jazzed up about the flashy, visible, bad part of The Stupid and didn’t have the working-hard, cleaning-up-after-yourself, help-others-out part of the Stupid down so good. Basically, he was seeing the bad and didn’t see what let us get away with it. And he (I’m actually talking about several people over a period of time and series of events) did something he thought was Stupid, but was just stupid. He got on people’s nerves, got in people’s way, maybe he broke something that cost money… and he didn’t do anything that would make people think, “Well, that’s alright, because… whatever.”

So I hope you see where I’m going by now. Amongst Railsers (as a broad generalization and as distinct from Rubyists) there’s a bit of a tradition of being bad. DHH is, arguably, the originator of that attitude and he’s certainly been an icon of it. I’m not even saying he’s wrong. I’m saying that whenever you have people like him (and he is, I should stress, not alone, here, Cf. Chad Fowler, Giles Bowkett and Zed Shaw) there will be others who look up to that way of being, who idolize it, who imitate it, but who, ultimately, don’t get it.

These freshman, as it were, will do the flashy, visible, bad part of the image (perhaps poorly, but perhaps not) but neglect to do the more subtle things that let their idols get away with it. I’m not sure what it is those idols are doing, specifically, that makes up for their behavior (they certainly aren’t practicing their music the most). I suspect that, really, everyone has to find their own way to make up for acting like a jerk.

What I’m driving at is that if you’re setting an example (as anyone highly visible in a community is) for being so awesome that no one minds when you’re a jerk, you have to take a bit of responsibility when others imitate you and screw it up. I think Matz chose (probably by nature, rather than consciously) an easier path: If you set an example of being humble and nice and people imitate you and fail, they’ll at least have the safety net of, “…well, his intentions were good.”

I’ve mentioned @carl_youngblood here before. Someone once was trying to buy him something with his name on it. I think it was a key chain. You know the kind, right? However, then didn’t have “Carl” only “Carlos”. So we joked that, one day, he needs to write an operating system and name it CarlOS. Aren’t we funny? I know. I’m sorry. Anyway, the other day, we actually got into some OS discussion that I thought had some interesting enough ideas to post here.

So how many computers do you own and use? I’ve got a desktop at home, a laptop and a machine at work. It’s sort of a bummer to have different stuff or different versions of stuff, or stuff with different preferences on different computers. At least, for me it can really jack up my work flow. Especially if there is some application I use a lot with non-default preferences. Man, that bugs me! Remembering it all, bleh.

One thing Carl’s fantasized about is having a computing environment the same everywhere you go. That’s sort of a mainframe or dumb-workstation idea, which is not new at all. However, what if your whole computer were version controlled? You could branch it (so you don’t have your work apps at home, etc.) and merge changes from one branch to another, if you wanted. You could check out a different branch on one machine and it would feel like you were on another.

Clearly an OS would have to be built from the ground up for this idea. You’d also have to have some kind of provision about storing the non-checked out branches locally. Also cloning the repo would be a hassle at current average (even high speed) connection speeds. But how cool would it be to install, say, Textmate at work and get all your settings right, etc. and then go home and merge that change in (You could merge it from work, I guess and then just pull from home. Whatever.)? You could get diff data (hard to implement, but with metadat not impossible):

$os diff gaming HEAD
+ Steam
+ Half-Life 2
+ X-Fire
- Textmate

Or whatever. You get the idea. Reverting would making backing up and creating, uh… what does Windows call them? Recovery Points? It would make all that easy and moot. Clearly Linus Torvalds needs to be in on this “project”; he has the experience in both OS design and version controlling that would be invaluable. Not that, you know, Carl or I are actually considering doing anything with this idea. It’s an interesting thought experiment, though.

I’ve recently started using git to version control my personal projects. I’ve also recently started using GitHub for hosting remote repos of that stuff. So I’m new to it all and I might be wrong, here. But, having read a few articles here and there and talked to some other people (most notably, another git newbie @carl_youngblood), aren’t cherry picking and rebasing really, really horrible things to do to a repo? Even if it’s just your local one? They destroy history, which is sort of the point of version control, no?

I’ve seen, in the last few days, two articles on GitHub that make me wonder which of us (me or GitHub) doesn’t get it. My inclination is to assume it’s me who’s missing something. If so, I’d love for someone to tell me exactly where I’ve missed a step.

The first article I want to talk about is the Fork Queue announcement. It’s basically a tool that makes it really easy to see which of the people that’ve forked your project have pushed commits you don’t have in your repo and then to cherry pick them in. You can pick your branch, etc. This is to keep you from having to create a lot of remotes, I guess. It’s supposed to “[allow] you to do a email patch style workflow without actually having to deal with patches over email”. I thought that part of the point was that that work-flow was a pain? I also feel like it’s missing the part where the person making the patch tells you about it, rather than you going and getting it from them. A pull-request is much more like that.

I don’t know… I sort of feel like we should be putting roadblocks in the way of cherry picking; make it harder for people to adopt work-flows where cherry-picking is common. My understanding (and again let me stress that this may be incorrect) is that the best work-flow is for the patcher to fetch your code (because it represents some kind of “core” or “official” release, yes?), merge it into a new branch, make his(her, etc.) changes, test them, fetch your code again to make sure he has the latest, perhaps retest, then issue a pull request. When you’re acting on the pull request, you fetch his stuff down to a new branch, test, possibly merge in any changes you’ve made to master since he issued the pull request, then _merge_ into master. This preserves all the history. It’s all fetches and merges.

So the other article is the Changing Git History article. This one is about going and messing with old commits. I’ll try not to rant as much on this one. I’m not as adamant, but I do find it kind of silly, this idea of making a commit a perfect little gem. I can see fixing a typo in the commit you just made, so git commit --amend doesn’t seem so bad. However, the git rebase -i portion after that… bleh. I realize this isn’t a GitHub feature like the above; it’s a part of Git, but I wonder why. If the commits were that horrible, revert them all and do it over. If they weren’t that bad, just live with the typo. No? Even if you haven’t pushed it, rebasing just seem icky and to be avoided, especially if it’s just to fix commit messages.

Okay… So, maybe I’m out of line or off base or insane. It’s entirely possible. Some would say probable. It wouldn’t surprise me if I’ve failed in some very basic way to understand the Git philosophy. It also might be that I’ve misunderstood what GitHub’s written and that the clash between these articles and Git philosophy is all imagined by me. I’m open to these possible realities. Correct me or soliloquize or slam me in the comments, if you like. I am all ears… or eyes. Whatever.

Update: Before anyone gets the wrong idea, here… I’ve been loving using git and GitHub. They’re both spectacular. Without them, I wouldn’t have found enki for use in powering this blog. This post is about trying to understand something confusing in something great; I’m not trying to imply that either should be done away with or that I could do better. I just wanted to head off the most major take-it-the-wrong-way that occurred to me on the way in this morning.