This is the end (of week two), beautiful friend, the end…
Sean and I got to spend a whole day going mad over the bug that we thought we squashed but, as it turns out, was not ready to die so easily. It was a heroic effort, full of sleuthing and more than a few leaps of logic. Most non-programmers see the job of a programmer as this almost mechanistic, yet wizardly manipulation of ones and zeros, where we understand absolutely everything that's going on under the hood, though how we do it is a mystery. Well, I love to ruin a good mystery, so I'll just come out and say that most of the time, we don't have a clue. The ones who really think they have it figured out are dangerous. As Socrates pointed out a while back, true wisdom is knowing that you know nothing. And I think if I was asked to pick one metaphor to describe a good programmer going on a bug hunt, it would not be that of the car mechanic who can hear a rattle and know the exact part in your engine that's malfunctioning. Rather, it would be that of a psychoanalyst taking intuitive guesses, based on the latest theories of the brain and several years of anecdotal evidence from previous patients as to what's wrong with the current one.
Would a bug really be a bug if you could tell exactly what's wrong by examining the visible symptoms? Sometimes it's that easy, but more often than not, these things are hidden under layer after layer of logic, often from hundreds of different brains, spanning several years of construction. If you were to go after it in a completely systematic fashion, it would take forever. You simply can't examine every bit of logic and understand it at a level where you can follow it like the machine does and still keep your sanity. So you make a hypothesis, check whether it seems to lead you in the right direction or takes you into a wasteland of despair, and if it's the latter, you do your best to come up with a new and better hypothesis to get you back on the path. In my mind, good programmers don't have easy answers as much as they have ever improving intuitions.
The bug here turned out to be an unforeseen side effect of spam prevention. Yep, that was it. It reminds me of reading about NASA losing a satellite for nine months because someone took a single, seemingly useless, flag out of the code. But we prevailed, and I got to see more system level automated tests in action, which was pretty interesting once we got into it. For some reason, as we dug further and further into the testing framework, dubbed "Cucumber", in order to figure out this particular bug, my brain kept making the connection to pickles (I don't really like pickles – I see them as "failed" cucumbers), and then I kept on thinking of the guy on YouTube who electrocutes a pickle in order to demonstrate what your life will be like as a true believer. The demonstration kind of freaks me out, but according to him, it's a good thing because it makes the pickle stand out from other pickles. Of course, this was probably all because it was Friday and strange things happen to one's mind on a Friday.
Nevertheless, we prevailed, the bug was slain, and the heroes entered their weekend victorious. That is, until someone finds another way to break the process and we're back to scratching our heads and trying to rehabilitate failed cucumbers.
This is probably the most paired programming I've done at a company, and although I often like to work alone, especially on anything creative, I find it's a great way to learn and a great way to focus. There are also pitfalls. I think you can sometimes lead each other astray via too much group-think, whereas you might think more critically on your own, but the advantage is that when you have no clue what to try next, usually the other person has an idea, and vice versa. And even a thousand miles away, after a whole day of wracking your brains out on something like this, it seems perfectly logical to give a high five for a job well done, even if it's a virtual one.
That's it! Have a good weekend. And may your dreams be free of menacing code.
Coffee, Diaspora, and Indulging in the Test-first Kool Aid
Today was a day to be thankful for caffeine. I truly don't know what I'd do without coffee. Even when I'm not tired, I need to have my cup. My favourite, when I'm not freezing (in other words, for about 3 months of the year in Edmonton) is the iced americano. It was one of the worst tasting drinks I've ever had when I first tried it, but it grew on me. A lot. When nothing else can get me out of bed in the morning, the thought of iced coffee will. Coffee, in general, functions as an energy booster, a social thing, and creativity enabler all at once for me. Some people instantly feel more creative with a cigarette hanging out of their hands. For me, it's coffee. My only real addiction. And you have to admit, there are worse things in the world than coffee to be addicted to.
But enough about coffee. Today was also the day we all heard about Diaspora, a "new" social network idea that will decentralize social networking and allow users to own their own data. They've raised a hundred and twenty-five thousand dollars the last time I checked, before any code has even been cracked. I found this amusing for a couple of reasons. One, it's certainly not a new idea. I wish I could find the article I read a couple of years ago on it. It was as intriguing then as it is now, but everyone was just so enamoured with Facebook at the time. I also remember a friend of mine who's like the canary in the mine shaft, talking feverishly about the need for people on social networks to be able to encrypt their data so that they are able to turn it off at any point. I'm not really sure how that would have worked, but as usual my friend was before his time in wanting to give users more control. Had he waited a bit for the world to suddenly have social networker's remorse, maybe he could have been collecting a bunch of startup seeding. If you happen to run into this friend of mine and you don't understand what he's saying, write it down somewhere and meditate on it every day for the next few years. And in 3-5 years, you'll be the only one who isn't surprised about the way things are. The other thing that I found amusing was the fact that people I'm pretty sure don't care much about privacy were suddenly cheering these guys on, and I'm sure I'll have to keep biting my lip a bit over the weeks to come. Don't get me wrong. I fully support what they're doing. It just bugs me when the success of an idea outshines the idea itself. Make no mistake, if these guys are successful (and there have been attempts before them to do the same thing), it won't be because they raised a bunch of capital. It'll be because (a) they truly believe in the right for people to be able to control their own data and (b) the world at large has recognized the disadvantages of entrusting its personal data to a handful of organizations.
It's funny because most of us in growing up have at some point "learned" that idealism is inherently wrong. It's a mark of maturity when you start to scoff at those silly idealists who think ideas alone can change the world. Ideas are nothing. Execution is everything. And yet right now is the perfect time to be an idealist. True, ideas are bountiful, but so are busy, busy people who don't really know what they're doing. While marketing companies scramble to concoct the next great viral sensation, a squirrel (Canadian, I might add), can pop out of nowhere and take the world by storm. Why? Partly because it's funny. And partly because of the idealism of remix culture, which has the audacity to think that you can just take a couple of pictures without asking and photoshop them together to create something interesting. It may very well be that to be a true pragmatist these days is to denounce the dogma of pragmatism.
Anyway, this has taken a sharp turn into philosophy land. I admit, my bias has always been towards looking up to the people who first bring ideas into the world, rather than towards the ones who figure out how to mass market them. That might also be why I like smaller companies. They don't have enough resources to coast on a bad idea for too long, nor to follow too far behind someone else's good idea. They don't have the inertia. The only way they're going to make it is if the idea's good and they genuinely believe in it. That actually creates inertia, and any time I see it, I want to be a part of it. I don't think you can ever truly fail unless you give up on the idea that lit the fire in the first place. Hmmm... sounds like good advice. Maybe I should follow it more often myself 
Seems we haven't left philosophy land just yet... wait... I think I see the exit somewhere up ahead.
I got to pair program with Sean from M7 (who is also a fellow musician) today. What is it about tech people and music? Anyway, I think that after we get the remote coding down to a science, we should try a remote jam fest. Sure the latency will be horrific, but it'll simply remind me of the good old days of digital recording. I've been pampered by this 10 millisecond stuff for too long. It's time to go back to the old neighbourhood like Rocky did in Rocky III.
The company is also starting to look at making user interface refinements, and although it can sometimes make for frustrating coding to tweak things at that level of detail (it tends to cause a lot of back and forth movement with any given feature), I think the result will be worth it. When you know all the ins and outs of a system at the code level, it can be easy to forget how confusing it can look to an end user, even a very technically proficient one. Sometimes changing a font or adding a bit more whitespace can make all the difference.
Lastly, I got to see the good side of test first development today as Sean and I solved a bug that at first seemed really strange, but became more and more obvious as we came up with the perfect test for it. And while making the fix, other tests that started failing kept us on the right path. In the end, everything passed again, and we were quite confident with the fix. I'm hoping to study up a lot more over the next few weeks on the philosophy behind when to write a test and what kind of test to write. I think it's going to be one of those things where the more I learn about it, the more I'll realize there's way more to learn.
There you go. Your second last regular stream of consciousness post before I start to slack off on my tech blogging duties.
IE, I bite my thumb at thee!
When you can broadcast to the entire world in a few clicks of the mouse, you sometimes forget what a strange and terrible power this is. And as it turns out, I seem to have the odd regular reader at M7, which was my intention of course, but it's also sort of odd to be in a meeting where people start making random references to something I wrote. Or making requests (sorry guys, I've decided, somewhat to my own disappointment, to keep this as professional as possible – besides, it's a big Internet out there and there are plenty of venues besides this blog for me to go past the PG rating).
Strange as it is, though, I'm glad to know that one of the goals I had in kicking this blog's posting into high gear has sort of been reached. I feel like my colleagues in San Francisco sort of feel like they know me a bit, after only one and a half weeks. And just think for a moment how strange this is. We've never actually met. The amount of actual conversation, IM'ing and initial interviews included, that I've had with everyone there combined is certainly less than 24 hours. But with the combination of these daily posts and M7's own prolific blog, which also allows a lot of personality to come out in addition to talking about the product, we're able to have an ambient awareness (read the article – it's great!) of each other that augments the more active communication.
Anyway, I've started to settle into this new definition of "normal" fairly well. And, at long last, my first few contributions to a feature on the site have made it to acceptance testing! How do you know that you've gotten back into the groove of a web development job? You start complaining about Internet Explorer and its ability to land developers in purgatory without warning. Did you know, for example, that it only allows you to load a total of 31 CSS files for a page? Now granted, you normally want to keep your file requests to a minimum (and the production version of the app, like many others, concatenates CSS to avoid doing so many calls), but when you're developing, it's nice to have things split up. So I was driving myself nuts trying to figure out why the hell absolutely nothing was working when trying to print something from the application's script module (which uses a CSS file targeted to the printer instead of the display), commenting out line after line of what I'd done and noticing that nothing seemed to be making any difference. And then I remembered one of my co-workers at Nexopia running into a similar problem with Internet Explorer (but in this case, it had to do with the size of a CSS file, which apparently matters a lot to some browsers) and took a closer look at what files were being loaded. Sure enough, the one I was after wasn't in the list, and sure enough a google search about CSS file limits and IE resulted in the magic number 31.
Come on, Microsoft. Seriously? 31? I mean, I know us web developers whine about your product maybe a bit more than is warranted, and somehow you have managed to capture the attention of the masses so that when we develop to web standards (for browsers where the development tools actually help us track down errors and fix them), we have to turn around and re-develop things for you unless we want to turn away half of our potential customers. And I can even buy the argument that because of this huge user base and big important sites that have been developed to work well with your browser and its quirks, that it's hard for you to take those quirks out later when you finally come to your senses. Too many people rely on the bugs. Yeah. I get it. But when you do something like set a 31 file limit on CSS files loaded from a page, it's like you're taunting us. Why? Why must you be so cruel?
The other thing I fought with was my Parallels/Windows 7 installation that allows me to test all the IE stuff out on my Mac. When I installed the thing, it was beautiful. You could suspend Windows when you weren't using it, and then fire it up in a minute to start IE. Or, with enough memory, you could keep it running and simply use the Windows programs almost as if they were native Mac ones. But this was no more. Even starting it from a suspended state, it would take half an hour before I had complete control of my system again and Windows was actually running. And I'm not talking about running it on a laptop. This is an 8-core desktop with several gigs of memory. My google-fu turned up nothing of use. Any of the stuff that even came close had to do with previous versions of Parallels and Windows. So, I decided to take an educated guess and turn off the Windows virtual memory swap file. I looked this up too and everywhere I found something about it, it either said not to do this because bad things will happen or not to do this because people who say it makes a difference are crazy. Well, count me in with that crew because as soon as I stopped it from using the swap file, it ran as smoothly as it did in the beginning. I even tried setting a static swap space of a gig, but that was still worse than having nothing at all.
Now for the news that's gonna make y'all sad. I'm planning on turning down the frequency next week on the posting. Like I said in a previous post, this sort of reflects me getting into the swing of things (so now you know, it takes about a couple of weeks). Things are picking up with M7 now, so work will probably be a bit more intense over the next little while, and I'll want my downtime to be real downtime (though by downtime, I mean being able to concentrate more on the music and the more artsy writing that I kind of put on hold to be able to work out the details of this slightly more complex day job). At the very least, the posts here will be shorter and less of a "stream of consciousness," as I won't be trying to recount an entire day in each of them.
Quantity? Been there, done that. Now lets go for quality! And by the way, in case you missed it, I couldn't resist making good on your request, M7 hecklers. It's up there somewhere, floating around in a sea of other words. How good were you at Where's Waldo?
The 11:30 Post
I know what you're thinking. It's 11:30 PM on Tuesday night, and David's going to miss his first daily update. And you know, I'm sort of disappointed in you for that. I thought you'd give me a bit more credit. The thing is, I actually like writing. I know it's an odd thing for a computer scientist, but I do. I've always had an equal interest in the arts and the sciences. For most of my life, it's simply made me feel like I didn't fit in, but now that there's so much technology in art and there's so much art in science... well, I think the future's looking pretty cool.
And why am I doing said blog post so late? Well, tonight was my night to talk about money with my accountant. It just so happens that he's also a fellow karate student, so after learning to defend against knife attacks number 1 to 7 (and yes, if I ever have to deal with an actual knife attack and running is not an option, I plan to ask my attacker if he or she can assume one of the seven standard attack positions that I've learned – why not?), we talked about all the things I have to do between now and April 30th in the event that I become a permanent contractor.
We talked about many things, and no, I'm not going to tell you about everything right now. I still have to have a few aces up my sleeve, right? But the bottom line is that it wouldn't be a horrible thing to just stay as a contractor. There are advantages and disadvantages to that extra step of independence, and it's not for everyone, but it's nothing to be afraid of. And this gets me to an important thing I've been getting better at but still have a long way to go on...
YOU DON'T HAVE TO DO EVERYTHING YOURSELF! I'm an indie musician and an indie writer. I do my own software development on random ideas when I have time on the side (though unfortunately, I have not yet figured out how to monetize any of them just yet – but just you wait... sooner or later, Malcolm Gladwell's 10,000 hour rule will kick in). When I was in a metal band (yes, you should have seen me with long hair!), we used to take great pride in braving a few hours in -30 degree (that's Celsius, for my American friends, which would be around -22 degrees Fahrenheit... thanks Google!) weather to put up posters for our next show. We were HORRIBLE at actually promoting these shows, but we recorded our own albums, made our own artwork, put up our own posters, and damn it, we were proud of that. I originally took that to web development. I made my own graphics, did all my own coding, etc. That's just what I'm used to. (I'm now smart enough to use WordPress for anything even remotely blog-like, and to buy or search for free things like icons made by awesome designers where I'd have to spend countless hours using the DIY philosophy to make something half as good). And the old me would have tried to figure out all by myself what to do about taxes and trying to avoid losing out by being my own boss.
And that would have been DUMB. Because I hate dealing with money. I really do. My dream is to be able to make enough eventually to be able to pursue any idea that I'm passionate about and not worry about whether it will make any money because the next one will, and while I'm waiting for that, a bunch of previous ideas / extra work are helping me make ends meet. I don't care if I'm a millionaire. I don't even care about early retirement. If I can keep doing stuff I'm interested in, that's all I want. So if I can get someone else to figure out how to get the most, financially, out of being a private contractor, then it's money well spent. But even better, my accountant friend is silly about offering his service to someone he considers a good friend for basically nothing. Now, I'm not going to take advantage of anyone else, especially not a friend, and especially not with something where I recognize the value he's giving. I believe in win-win situations as being the only ones worth doing. So the idea is that he might very well want a web site at some point for his own business and while that's foreign to him, it's a piece of cake for me. And that's what we agreed upon as a good trade. It's kind of funny. I'm following in my computer salesman dad's footsteps, as he did almost the same thing when he started out. Maybe that will make up for his son becoming a Mac user when he sold PCs.
Tests. I thought more about these, and you know what I think the problem is? It's a Black Swan situation. The only time tests are valuable is when they catch something bad. Until then, you can't know that they're doing any good. The guy who wrote the Black Swan gave the example of a fictional U.S. senator successfully passing legislation to get locked, bulletproof doors installed on planes and if this had gone into effect by September 10, 2001. That next day might never have happened, and people would have hated the senator because, in their eyes, he'd be wasting tons of money on something that's not even a problem. But we know better now. That's the hard thing about preventative stuff. You can go overboard and do way too much work to cover a very small amount of uncertainty. But how much is too much? Especially when the costs of that very small probability event happening can be huge.
And on that super serious note, goodnight! Nine hundred words in 30 minutes isn't that bad, huh? Okay I am cheating a bit and am going to set the timer back 3 minutes to 11:59 PM to keep it as Tuesday's post. But I think that's close enough, don't you?
Week 2: Who tests the tests?
People are already becoming skeptical as to how long I will keep up my daily posting regarding the brave new world of telecommuting. One of those people is me! Well, actually... I never intended to keep up the pace forever. But I figure it's worthwhile to make it daily for as long as I can. It makes sense in a way. Any new experience is very vivid at first. Lots of stuff for the senses to take in. And then, gradually, our brains go on autopilot, seeing less and less noteworthy material. So if I can make the effort to pump out these posts when there is stuff to talk about, we should actually get a pretty good idea of how long it takes for the telecommute experience to become the new "normal". And that, in itself, is useful information for anyone else looking to try.
The only thing that I really noticed today that was different between a regular job and telecommuting had to do with my first "all company meeting" with M7 (by the way, I like referring to the company as M7 because it sounds similar to MI6, which of course, is where James Bond works – where's my Aston Martin, huh?). I don't like letting a meeting go by without making the odd joke to make it feel a little less meeting-like. As I tried to figure out why the meeting felt kind of odd, that was what it came down to. Now, I'm not talking about doing something like, "A horse, a priest, and Jay Leno walk into a bar..." (By the way, I have no idea how this one would end, so please don't ask me). I just talking about general camaraderie that occurs in a face to face meeting (at least in a smaller company – meetings were just meetings at bigger companies). It's harder to do over the phone because you don't get to see the body language that usually indicates whether or not a little joking around is called for. The few attempts made by myself and others were also made awkward by the difficulty in interjecting. It felt more like you were actually cutting someone off. This happened even outside the realm of attempted camaraderie. If someone's saying something and you have a point to add, it's very hard to add it in at the right place without actually cutting them off. They don't see you bursting with something to say, as they might in a face to face meeting, and where they would naturally pause to let you in and then continue.
One thing I'll say about the meeting that has nothing to do about telecommuting or not is... it had a time limit! Listen up, certain former co-workers who will remain nameless but did not set time limits: when you have a time limit, things still work quite well. You still get to get all the important stuff out. You just squeeze it into less time and are more conscious about not going off on tangents. There. Said it. No more callouts on this post.
Finally, the title of the post. Let me introduce you to my latest obsession. When I started, there were around 500 out of 2000 tests broken due to a Ruby on Rails upgrade. We're now down to around 130. Important to note... in the 370 that were fixed, I only found one that was actually to do with the site code. The rest were broken simply because the test framework was broken. The fixes were to the test framework, not the actual code. I became a bit obsessed with getting the failing tests down to zero, and here's why. It's the broken window scenario. I've seen it happen time and time again. It's hard to justify spending a lot of time working on those extra 130 tests. And, in fact, I'm currently hitting the 80/20 rule hard. The first few fixes caused tons of tests to pass. Now it's down to 1-10 at a time. Talking to Seth, I momentarily woke up from my coder's obsession and saw things from the business point of view. Tests aren't features. They're something that helps us coders sleep at night. And they provide no visible benefit. Don't write tests and you'll crank features out much faster. If you're having trouble hitting a deadline, throw out the tests and you'll hit it way easier.
Here's the thing, though. If we let a few months go by where we don't fix those 130 tests, we'll probably stop doing test first development. The whole point of having a test suite is having them all pass. When you allow a lot of tests to fail for long enough (and usually long enough is a pretty short time), it's like not fixing the broken windows on a city block.
Coming from plenty of businesses where the test-first methodology ended up going out the window (pun intended?), I'm not sure this is the end of the world. The problem with having a load of tests, especially when they test really trivial things, is that sometimes the conditions that the test is concerned about at the time become totally irrelevant. Then, when they break, you're sometimes left wondering why the test was there in the first place.
But there has to be a happy medium. One idea on this is simply to watch the tests and be ruthless about culling the ones that become irrelevant. And looking at this as a case in point, I'd say that if we haven't knocked it down from 130 failing tests in a month, we should just delete them. If features are working, and you no longer know why a test is failing, maybe it's better to just throw it out so that it doesn't obscure more important failures and doesn't end up being the broken window that kills your automated testing going forward. Let's be clear. I think having these tests is a good thing. I'm just throwing in some heresy that's floating around in my brain at the moment. I may completely change my mind tomorrow, and certainly would love to find out what some of my fellow developers think of this problem. But even though tests are a great learning experience and, as I'm suggesting, leaving them for too long will result in jeopardizing the practice itself of testing first (that may be up for debate as well), it's obvious that given the choice between working tests and working features, the people actually using the product are going to want the working features.
So for now, I'm moving onto features, though I might pick away at the remaining broken tests as any flashes of brilliance occur. And I'll do my best to keep thinking in terms of writing the working test first and then developing the feature to make it pass. But I'm also going to be thinking of strategies for keeping those pesky tests manageable.
Day Four: Made it!
My first week of telecommuting is coming to a close, and you know, all in all, it wasn't too bad. Communication delay was probably the number one difficulty for me, with people being in transition, not being within arm's reach to grab someone I need to talk to, and a few flaky internet connections. But even then, we actually covered quite a lot. I'm not sure that I would expect to do much more in the first week at any other company. And the bigger they are, the more uncomfortable thumb twiddling moments you can expect. I now have a bird's eye view of the product, have been introduced to troubleshooting issues with the live site, even poking around in the logs and S3 a bit in the process (I'm really stoked that I'll be learning more about Amazon EC2 and S3. I'd looked into these when they first came out, but they were still more than what I needed for my various small side projects, and I ended up going for a Rackspace account instead. I get the feeling that while Rackspace was much easier and cost effective to set up a shared host, it might not be as easy to scale and as dynamic as EC2). The more I poke around in the test code, the more I get a feel for the heartbeat of the site, and I'm even starting to be able to do a bit without any hand holding.
So here's my big idea for the day. Working across a distance doesn't really change the nature of what you do during a day, at least as a programmer. What it does do is amplify everything. In the zone? Being "at home" contributes to this by giving you the absolute most comfortable place you could work, reducing the distractions of co-workers who might be far from in the zone on that particular day (at the office, when one person is not feeling very productive but is feeling sociable, the lack of productivity can spread like wildfire). Now, if you're feeling isolated or having trouble communicating or feeling unproductive, those things can get amplified too. And depending on the measures you put in place early on, working from home can be a blessing or a curse. But I think just being aware of how everything is amplified helps.
Talking to some people, I was worried I'd go a bit stir crazy, but that didn't happen either. I think some of that has to do with the fact that when I wasn't working my day job from home, I was still doing a fair amount of work on projects, etc. in my spare time. So I was used to sitting down for long hours in front of the computer at home to get things done. If not for that, I can see how it would have been a huge shock to the system. If home is already a place that you associate with everything work isn't, then it's a hard place to suddenly make into a work environment.
Now, I say that with the luxury of not having any kids running around trying to get my attention. We have only our fish, Dion*, and he is very nice and quiet when I am working.
What I have noticed is that I appreciate my off time, meeting up with friends for lunch, or even just a short walk to clear my head a little more than I used to. That's probably not so much a factor of working from home as it is a factor of being thrust into a period where a lot of things change really fast. The newness will fade, and with it some of that newfound appreciation. I guess the trick is to just keep finding ways to rediscover it.
Some of the things I'm looking forward to once I get a little more into the groove and I'm a little more confident that I can handle the freedom of being mobile without falling prey to its pitfalls:
1. Working at coffee shops from time to time! I know it's kind of weird, but one of my favourite things to do is work from a coffee shop where I don't know a soul. The coming and going of people adds a bit of energy you can feed off of, not knowing anyone keeps you from being too distracted, and new surroundings, no matter how generic, makes the odd dull task sort of novel again.
2. Doing the odd change in city. I don't visit my folks enough. But all I really need is a high speed connection and a laptop and I can work from anywhere. So in the future, I might try spending the odd week back in my hometown, working during the day and catching up in the evening. Plus there'll be even more reason to focus given the tendency for small towns to seem kind of slow once you've gotten used to city life (though I still remember feeling like an absolute hick when I moved to Edmonton to go to school, so I imagine it works the other way too).
That's it for this instalment. And that's it for this week! I will see y'all next week. Same bat time, same bat channel.
* Dion is named after the former leader of the Liberal party, Stephane Dion. He used to have a friend that we called Harper, after Prime Minister Stephen Harper, who was about twice the size of poor Dion. We think this is because Harper kept all of the food for himself, always chasing poor Dion away at dinner time. But alas, Harper the fish got a little too used to all that food and eventually ate himself into that fish bowl in the sky, and this is how Dion came to be the only fish in the condo. Draw the parallels to their namesakes if you will, but I insist that the fish situation was never meant to become such an awesome commentary on Canadian politics.
Day Three: The Sky is Falling! Oh… wait. False alarm.
I don't think you can work for long with interesting companies before you become a bit traumatized. One company used to serve pizza before telling you something bad had happened and they wouldn't be able to pay you on time. Seriously. Ever since then, I get nervous whenever a company buys pizza for everyone. At another, there would be a regular all company meeting in the afternoon, and if it got rescheduled for the morning, you'd know that something bad had happened and whoever didn't show up for the meeting had just gotten let go. I made the mistake of mentioning this observation and the modus operandi was changed, but there was still a huge sense of unease a few days before every strike of the doom hammer (though I kept this knowledge to myself). So, I've been slowly trained to look for these little quirks as signs of impending doom. I also have a pretty decent imagination. Not an optimal combination for telecommuting!
The day started out normal enough. I wanted to get an early start on getting all of M7's rspec tests running. I was told there were some broken ones due to a ruby upgrade, but I'm pretty sure there aren't as many as I was seeing. There's a very strong "test first" methodology at this company and I want to do my best to continue the legacy. All it takes is one or two people to find a reason not to do tests for a few months and the whole thing can go out the window. I've seen it happen at many a well meaning company. But the first step to me really getting into this frame of mind (and being able to fix some of the broken tests) is making sure that I'm looking at the same broken ones as everyone else.
Then my new colleague in operations said hello and informed me that the sky was falling. Well, he didn't quite put it that way, but the site was suddenly throwing a few errors and being very sluggish, and in the back of my mind was the creeping horror that I had checked in some code... some very, very simple code that shouldn't have done anything and shouldn't have gone live anyway, but... oh God... was this going to be how I made my first impression? It got completely resolved in less than twenty minutes, but it really sucked to not be able to do anything because I hadn't yet seen how everything was setup. Thankfully, the fears of my first code contribution run amok were unfounded, but let's just say the morning left me a bit rattled.
After catching CFL with some friends (there's this place in Edmonton called "Chicken For Lunch" that is a ritual weekly occurrence – we think it has something to do with the owner putting an unknown, yet highly addictive substance, in the chicken), I tried to get back to figuring out why so many of my tests were failing. I fired off a few questions as I went along, kept watching the chat, hoping to catch someone, waiting, wondering if I should go onto that one other thing that I wasn't sure about, waiting, and... what happened?! Where is everyone!? OH NO, BAD THINGS MUST BE HAPPENING! THIS IS M7's VERSION OF PIZZA (see above). Okay, I wasn't actually freaking out that bad. It was more like the subtle psychological tension of the three day rule. Don't act like you don't know what I'm talking about. Who of us has not gone through the, "How long should I wait before I call so as not to seem weird and desperate?" or "How long should I wait for them to call before I rebuild my shattered ego?" routine at least once?
Now, to start out with, I had forgotten what it's like to be the people who've been at a place for years, have tons of stuff to do, and, oh yeah, try and fit bringing the new guy up to speed into your already full schedule! In fact, I'm so used to being in the other position, where I was the person trying to find time to bring the new person up to speed, that I forgot to even try to prepare myself mentally for the role reversal (where sometimes you just have to wait). Add in a complication that is unique to my situation: if I was physically in the office, I could have just waited until someone was walking by and called them over to my desk. Doing things remotely, though, I had only email, instant messaging, and the last ditch of the more intrusive telephone call (and I only had Seth's number for that - note to self: it might be good to get some other numbers).
After Seth talked me down off of the rooftop, he told me more about some of the plans he had going ahead for development and at one point had to stop and bring up the fact that he couldn't really tell whether I was cool or not cool with these ideas because he couldn't picture the facial expressions behind the conversational murmurs (though that wouldn't have helped anyway because I'm told I have this tendency to frown when I'm thinking about something, regardless of whether I like it or not). And that basically hits at the centre of the whole problem of doing a telecommute job. It's those bits and pieces of body language that you pick up on. It's getting used to someone's personality. That's what helps you to put everything else in context and make sense of what the person is saying. I've always thought that the creepiest part of Alice in Wonderland is the one where Alice meets the Cheshire Cat. And it's kind of for the same reason. How can this pair of eyes and a voice actually exist without a body? It's a challenge. And it's one of the reasons I figured it might be a good idea to blog regularly about it.
Which brings me to the blog itself. I haven't really explained to everyone why I decided to start writing about this particular adventure. Let's do that:
1. I can't physically be in San Francisco (though I do intend to visit, and imagine this will make things a lot less strange), but writing long-winded explanations about my first few days (and hopefully a few more before I run out of blogging steam) has the side effect of giving my San Francisco colleagues a hint of my personality. And if I do it regularly enough, some of them might even make it a regular thing to check into David's blog to see what silly theorizing and allusions he's throwing about in his latest instalment. Whether you take it seriously or have a few laughs at my expense, at least I'm regularly in your thoughts . And that makes it harder for you to think of me as, "Just that guy who's teleworking from Edmonton."
2. When I looked around for info on doing something like this online, there was a lot of high level (listing off pros and cons, etc.) stuff, but nothing I could find that I felt would really give me a good preview of the experience. The problem with any sort of knowledge is that once you've learned something, you forget what it's like to learn it. I suppose that's the special gift of a good teacher. They're able to remember what it's like to learn something and know it very well at the same time. This way, someone else considering what I'm doing can actually follow me on the journey as I figure things out (and, of course, as M7 figures it out on their end – both parties need to be willing to make things work).
3. It forces me to reflect on ways I can improve. Instead of simply freaking out over a slightly stressful/odd day, I'm considering how I could have done things differently, where I made bad assumptions, etc. For example, one of the things contributing to my stress was the fact that, besides lunch, I was enforcing this strict schedule of staying at my desk as much as possible. Perhaps it would have been better to take a walk, run a few errands, and simply finish the day later. As I mentioned in a previous post, I don't want to get into the habit of doing that. But sometimes trying to stick to "the plan" can cause more problems than allowing a little flexibility, even if that means that I'll have to keep a closer watch on the discipline thing going forward.
4. It keeps me committed to making the situation work. I know a few of my own friends, family, and colleagues in Edmonton are reading these posts. And that means my pride's on the line. Pride is a much better motivator than simply paying the bills.
5. Ever since I started reading it, a semi-secret, mid-level goal in life has been to figure out how to get BoingBoing'ed And, well, if I can keep this up for a few hundred posts, maybe it will be strange and wonderful enough to qualify for that sort of techno-bohemian geek cred! Don't worry. I don't actually think I can compete with the likes of the keyboard cat, but one can dream, can't he?
Alright. This was a long one. I wanted to somehow tie it into similar problems that a video production team might run into if they were working over a distance (this was one of my selling points when I was initially pitching the idea of working for M7 from Edmonton), but I think I'll save that for another post. Instead, I'll simply close with a glimpse of what the northern end of the "San Francisco – Edmonton power corridor of software development" looks like in May (you didn't believe me, did you?):
Day Two: Enter the Code!
I can't decide whether the title to this post reminds me more of old Bruce Lee movies or of classic Metallica tracks. This is going to be a shorter post as it's been a fairly long and intense day, and I need to learn to write more concisely anyway.
As the title suggests, this was my first day of actually looking at code. I paired with Jeremy, Market7's senior software engineer, today. What, you ask? I flew to San Francisco and back for a paired programming session? But no, developer friends, I am going to tell you glorious things about iChat screen sharing. While a bit jittery at times, it actually works great for paired programming, especially with the dual monitor setup that I have at home. I was able to dedicate one entire screen to Jeremy's computer as I took notes, etc. on my local computer on the other screen. Every so often, I got to take the reins (I'm pretty sure this phrase is used outside of Alberta, but come to think of it, it sounds like a very Albertan thing to say), and type code on Jeremy's machine while he gave pointers on what to do. Combined with the audio chat, it didn't feel much different than a live pair programming session to me. And that's just scratching the surface on some of the tools out there. One of these days, I'd like to try something like SubEtha while pair programming, where both people can type at the same time.
What else was great about this session? Well, I was introduced to a lot of new ideas and tools. I also got to see how Market7 handles task management with PivotalTracker, which was much different than my initial attempts to track a project with this tool. Their philosophy boils down to breaking a story down into very small pieces that can be done iteratively with a test-first approach so that you get a real feeling of momentum with checking one off and going to the next. The other thing I liked is that I saw a few places that I thought I might be able to bring in previous experience to improve the code base, and Jeremy encouraged me to do so. Though not all at once, of course!
Finally, I seem to have fallen prey already to some of the pitfalls of mobile work. One is knowing when to call it a day. It's harder to do when you're working from home. The other is feeling guilty if someone tries to contact you when you're away from your desk (which happens all the time at an office, but you're especially sensitive about when you're working at home). I'll have to find more of a balance there, but for now, I justify this with the other piece of advice I got about working from home, which was to be extra disciplined about it in the beginning. If you don't set that pattern to start out with, it can be difficult to adopt it later on. Plus, things are normally a bit more stressful and longer when you're starting out on a new code base, so I'm not going to worry for a while about burn out.
One thing that's totally awesome, though? The zero commute. I only had to walk three blocks to my last job, but being able to just roll out of bed is where it's at. As Jeremy can attest to, though, I at least wore clothes. He can't really say for sure whether I was wearing pants (I've heard of people who have actually done the no pants thing!) but you're all just going to have to trust me on that one.
So this post was only slightly shorter... I think I cut off around 300 words. Baby steps, everyone! Baby steps.
Day One!
Day one ends with me frantically applying for a business license after texting my accountant friend (and fellow karateka) saying, "Hey, accountant friend, will I need to get a business license if I'm starting out on contract?" His answer is yes, and so I rush to the City of Edmonton website and find that, to my relief, the application for a home business license (especially for what I'm doing - nothing that creates loud noises, strange smells, etc.) is relatively pain free. We shall see if successfully getting said license is as easy.
As an aside, let's talk about my genetics in terms of entrepreneurialism. They're not very good. My parents were very dependable people who played it safe. Being their son, through example, they taught me to play it safe. Which is good. Much fewer headaches are in store for you when you think ahead of all the possible things that could go wrong when you take any particular course of action. The problem with this is that thinking ahead about all the possible things that can go wrong is a great way to not take necessary risks. It paralyzes you. Now, if I take a look at people who are successful in some sort of entrepreneurial endeavour, they seem to share one common attribute. They may recognize that the future is going to hold a bunch of things they have to do that will be troublesome, complex, etc. but before they think too much about this stuff, they simply jump in. People like me tend to not learn from these people. It's easier for us to say something like, "Look at that idiot. He didn't prepare at all, and is just going on dumb luck. Just think if I had done it how much better it would have gone." But that's the point. We're the peanut gallery. And it's easy to give critique when you're not in it. So rushing to get a business license at the last minute might look like simply not thinking far enough ahead, dear readers, but I would argue that it was better to simply tackle it when it came up than to make a daunting checklist of things I need to do before I can even start.
Most of today involved going through the product with Seth, the CEO. It was pretty intense to get the overview on something he's been working with for years in a few short hours, but that's been my experience getting involved in any new project. The trick is to take in as much as you can and try to build a "big picture" model of things. What's coming down the pipe? What's are the distinctive features? What's the general philosophy behind the application? Seth was pretty good about giving these high level details as he went along, and I think it will help a lot in my brain retaining the important stuff. And while I don't have a lot of experience in the video production industry (besides making low budget music videos with gaudy effects in final cut express / iMovie), I found that I could grasp the necessary collaboration aspects fairly easily. The Market7 product is meant to bridge that gap between business types who want hard data about what's going on and more creative types who don't necessarily fit into easy schedules. That's my first impression, anyway. Working on a lot of artistic stuff on the side, and more recently trying to write some software tools to make that easier, I've at least run into the problem of how to add more structure into a creative project's workflow in a non-intrusive way. I flip back and forth between creative and analytical mindsets often, and it always takes a little while to get settled in one. That's why it's important for software to be designed in a way that doesn't make you interrupt the one mode of thinking until you have to. I'm excited about bringing some of the musing I've done about this over the years into my work with the Market7 product.
I felt that a lot of trust was put in me right away, and that helped a lot in terms of making me comfortable working from afar. In my mind, it re-affirmed that, "Okay, we really are doing this thing." So that was unexpectedly important. I already feel much more confident going forward than I did a day ago.
Finally, what technologies are we using. Well, there's this thing called a telephone. That works surprisingly well. Combined with a WebEx meeting session with screen sharing, and it's almost as if I was sitting in San Francisco. We're using PivotalTracker for scheduling and keeping track of work that needs to be done. I did a little preparation on this, but it was interesting to get an insight into how the application (or any application for that matter) is tweaked to suit the working styles of the people using it. I imagine that will take a little time to get used to, but I don't anticipate any major issues.
So, that's it. Day one is complete and I know a lot more about the product, who I'll be working with, and what's coming up. Day two will introduce me further to the code behind it all. As a programmer, this is something that I feel will give me a much better feel for things and settle any other anxieties rolling around in my head.