iPad: First Impressions
Despite not being completely blown away with it (the "it's indistinguishable from magic" propaganda from Apple was a bit much, even though I think the company is probably still the most innovative out there when it comes to making tech products that are actually a joy to use), I decided to line up for the Canadian debut of the iPad. From a pure software developer perspective, it's hard to imagine the future not being filled with more and more touchscreen devices like this, and I've had a few ideas rolling around about apps that might be cool when used with the larger screen (over the iPhone) that the iPad gives. Maybe I'll even be able to beat the expected dilution of the market as the app store gets flooded with iPad apps to do just about anything. (Need to walk your dog, but too lazy to do it yourself? There's an app for that!)
And, admittedly, although I don't share the love of Star Trek that has become part of the caricature of your average software developer, I do find it hard to resist getting to know a new gadget.
So now that I've had a few days to play with it, here's what I do think is amazing about the iPad. Here's the spoiler: it has nothing to do with the hardware.
That's not to diss the people who actually make those electrons flow down the proper channels in such a way that I'm able to hold a tiny screen in my hand for ten hours per charge that makes the room sized computers of fifty years ago seem like a joke. It's just not my domain. I don't see the value of objects in and of themselves. But if we can do something really, really cool with them, well that's when it starts to get fun.
And I think this might be why Apple's iPad has been met with a more dimmed enthusiasm than previous products. It probably doesn't have any more or any less innovation involved than any of their previous products had at the time. It just doesn't seem like as much of a leap. Why is that? I think that a big part of it this time around is that none of the software that Apple has bundled with the iPad is that much different. Hell, they're even using the same operating system that they use for the iPhone with it. I can have an extra column when I use email? A fuller looking calendar? I can read an eBook on it? Well, woohoo.
Then I decided to pull down the first iPad edition of Wired Magazine and I saw the full potential of what devices like the iPad might bring to at least one very troubled industry.
It's mainly about the advertisements.
I found myself almost more interested in them than the various articles. If this isn't the moment for the advertising industry to lead a full charge away from old media forms and onto the Internet, I don't know what is. While everyone uses television commercial breaks to go to the bathroom or refill their drink, the ads in Wired magazine actually made you want to poke around and learn more. They were able to prove you with a simple and elegant, non-intrusive introduction. No blinking neon signs here. Just flip the page to be onto the next article. But maybe something caught your eye? Well, there's a play button you can press to see a video version of the advertiser's message. And if you touch some of the headings, they'll pop up more info for you. Just if you're curious. You don't have to. It's up to you. And hey, if you're really, really interested, here's a link that will take you to their website to actually buy the thing.
Wow.
It's like being able to have an entire website of information about your product embedded into a single page of a magazine. The purpose of advertising is to interrupt your routine. And that's not always a bad thing. Imagine if you had to actually go out and search for that brand new technology that will make your life so much simpler. How would you even know what to search for? While convincing us of needs that we didn't even know we had can be predatory, and in the current world of advertising it often is, there is nothing inherently evil about wanting to inform people about something they don't know about. What ads like these allow is for the advertiser to catch your attention with the typical "this will change your life" sort of appeal. But it also allows them to be more honest and give you more information right away so that you can decide for yourself how much your life will change and whether it will actually be for the better. I'm not so silly as to be utopian about this and say it's the end of deception in advertising. But I do believe that it provides an avenue for companies to get their message out in a way that doesn't litter our day-to-day lives so much. And that's good for everyone involved.
I imagine there'll be more than a bit of money out there in making these sorts of content rich ads easier to produce and embed. And I don't think there's much argument anymore that the Internet friendly ads like those in the e-edition of Wired are more valuable for advertisers and consumers alike than their old-media predecessors. It must be a heady time for the ad networks to consider the exciting possibilities ahead of them if they decide to go for quality over quantity.
So what else am I interested in seeing on the iPad? Textbooks. Imagine being able to open your calculus textbook, look at a graph it uses to explain a concept, and actually change values to see what changes on the graph? Or to be able to step through a virtual chemistry experiment? How about seeing the effect of your incorrect physics solution on the orbit of a space shuttle around a planet? I think that this level of interactivity could have an amazing affect in the area of education. And who out there doesn't believe that this is an area that we need to pay more attention to?
It's never the hardware that changes the world. It's how we decide to use it. And I can't think of any other device at the moment where this is more apparent than in the iPad and it's soon-to-be brothers and sisters. They could easily be a throw away fad or the future of computing, depending on whether or not they're able to capture the collective imagination of the software development world...
Caveat:
As this article points out, the Wired app may be, technologically speaking, a horrible mess. I agree that simply slicing up images to build your interface when you could be using a lot of HTML 5 to get the same effect is incredibly kludgy, and the amount of space that requires for an app is unacceptable in the long term.
However, I disagree profoundly with the idea that it was a mistake to move away from a more browser-like experience for the e-version of a magazine. I think us techies are sometimes too dismissive of the importance of how something looks. The success of Apple in recent years should have proven that to some degree, but maybe it's one of those never ending arguments. I've read other articles that suggest it's a step back that the Wired app doesn't try to more closely resemble a regular web browsing experience.
But I'd suggest that we shouldn't be so quick to say that the way information is organized right now on the web is at all optimal for every situation. In fact, an article in the current edition of Wired (which, granted, I couldn't have linked to in the app version) points out what I think anyone who still enjoys sitting down to read a real book or even magazine article will intuitively know.
The fact that we tend to follow links, etc. while reading content online, often only skimming content for something in particular that we're interested in, can result in a much more superficial form of learning. To be sure, we're able to get many more viewpoints around any particular issue, and thus get a more well-rounded perspective on it (and I think this is a very positive result of the web), but we're also less willing to sit down and give a lot of time to considering a single viewpoint before going elsewhere. There is a value that you get from sitting down with a single work (be it a novel, essay, or whatever) from a single mind, and giving it your full attention that you can't get in any other way. It may not seem as useful in the fast paced world of the web, but I think we ignore that at our own peril.
So I actually like the fact that the Wired App presents a unique and visually engaging experience that makes me want to actually sit down and read an article all the way through. It doesn't leave me feeling fidgety, wondering what else is out there on the Internet that I'm missing out on because I'm focusing all my attention on this one thing. And I hope that as we bring the experience of reading things like novels more into the electronic realm that we consider this. Yes, it's great to be able to cross-link and do all manner of Web 2.0 stuff with a novel. But I don't want that stuff to be in my face. I want it to feel like I'm reading a book most of the time. I think that's valuable. I like the idea of giving a designer control over everything, even the font face, so that he or she can present their full vision to me for a given publication.
There's a lot of thought that goes into laying out a magazine or even a novel for printing. Just go to any bookstore and pick out a pulp book to compare to one from an author du jour. Don't look at the quality of the writing. Look at the quality of the presentation. Taking away anything about the actual content (i.e. remove the actual author and subject matter from the picture). Which one's easier to read? Probably the one with the bigger budget. And that doesn't mean you need a big budget. It just means that considering those minute details involved in choosing typefaces, line spacing, layout, page-breaks, etc. (which tends to happen for books with a bigger budget) makes a difference. It's nice to be able to change fonts, etc. on something that's poorly laid out. But I'd rather just get a good quality layout. If I'm still paying $10 or more for an e-version of a book, I actually expect it. A plain text document might give me all the power in the world, unless my interest is actually reading the thing.
So, yeah. Can Wired on the iPad use some improvement? Certainly. But I still think it's a step in the right direction, especially for an avid reader, not to be confused with an avid web-surfer, although you often find people who fall into both groups.
On copyright
I saw this on BoingBoing earlier this week and thought it was especially appropriate as my own country moves towards adopting a stricter set of copyright laws. In summary, the presenter cites the fashion industry as an example of a world that not only survives but thrives under a complete lack of copyright protection. The thing that I think makes this argument especially compelling to me is that the arguments for protecting fashion under some form of copyright are the same as those being used by most media-centric industries today – and yet the fashion industry is still doing quite well without these protections. I like the comparisons drawn between music sampling and fashion sampling. When sampling music, no matter how small the sample, you're legally required to secure the rights. In fashion, you can outright copy someone, and as long as you don't use their name on the product, you're not breaking the law. The presenter argues that far from stifling creativity, the allowance of this sort of sampling in fashion drives innovation.
As a software developer who has used and worked on both open source and proprietary software, and as a musician and writer who has spent many years and will likely spend many more honing his craft (who has also sold music and played for money, albeit chump change at the local level), I think I'm pretty qualified to say something about copyright. I believe that creativity is valuable and that it needs to be compensated. It bugs me when someone says that I should do it for free. Or that I must. Anyone who's passionate about creating things will do it regardless of whether or not he's paid to do it. If we abolished all forms of protections and in fact made it illegal to make money off of works of art, we'd still have works of art. It's not a rational economic choice that one makes to be an artist. But when you allow someone who truly loves their craft the ability to also pay their bills and maintain a reasonable level of comfort with it, everyone wins. You get better quality art simply because they're able to spend a lot more time practicing their craft.
So, I don't come from the Napster-flag waving crowd. I think creative people, especially artists, are undervalued and always have been. And I hope everyone keeps in mind that even some of the most famous and wealthy artists were once independents who went home after a full day of work and, instead of turning on the TV, spent another six to eight hours sweating over their craft. If they're not deserving of at least your respect, I don't know who or what is. And if you think that what they produce is of value, you should find a way to support them, no matter how small. Yes, some people lucked out. Some people win the lottery too. That doesn't mean that there aren't a whole bunch of other people who actually deserve the credit they get.
That said, how does extending a copyright to a song seventy years after my death help me to create? Why should my heirs be able to live off of one or two very successful works, if I were to produce such things, without contributing anything of their own to society? Why should you have to jump through so many legal hoops to pay homage to another artist by sampling his work? And if you're a big fan of a band or movie, should you really have to risk legal action in order to help promote them by passing their stuff around to your friends?
That last action is, of course, classically referred to as piracy. And, to be fair, sharing music out of a hard drive and using it as a sort of currency to get other music you want (unless you're okay with the much frowned upon practice of "leeching," as it's referred to in the file sharing community), isn't quite the same thing as saying to a friend, "Hey, you've just got to hear this band! They're amazing! I'll send you a track!"
But who's fault is that? Any market that is made illegal (such as the file sharing market) is naturally distorted because of that illegality. You can't say that it would have exactly the same characteristics as a similar legal entity that had a few reasonable controls placed on it. For example, if people weren't worried about being sued for sharing files, they'd be more open about it, and you could use that data to market to them and/or implement fee structures that everyone thinks are fair.
As an indie musician, even doing short runs of 500 CDs, it costs about $2 per copy. I know this because I've done it. For a few thousand dollars, you can have the equivalent of a million dollar 1980s recording studio in your home. I know this because I have such a studio, and I've watched over the years as the sound that only the pros could afford fell further and further into my price range.
Fans trading music around can end up doing your marketing for free. Most indie artists I know would love for people to start "stealing" their music. Our enemy is obscurity, not piracy. Get the obscurity thing out of the way and most indie artists can do just fine on their own.
So where do those extra $13 per CD really go? That markup might be necessary, but you have to be able to convince your customers of that. Notice that I said "convince them of that," not "compel them to pay that." When people see indie musicians producing often more inventive music at the same or lower price (when these musicians are not able to take advantage of the economics of scale), you need to find a way to justify your own price.
In my mind, the biggest contributing factor to piracy and its more harmful aspects, is that we've barely even tried to recognize the new digital reality. The music industry is just starting to. It took them over a decade. How long for the movie industry or the book industry? Or the manufacturing industry? I can't wait until machine fabrication becomes so accessible that people start trading design specs so they can print off a brand new pair of Nikes. We might as well start thinking about how we're going to compensate people in ways that encourage the flow of ideas instead of stifling them because the world is only moving further in that direction. There's no going back. Let's just accept that, embrace the future, and try to save what's truly of value in the present.
Copyright law, at least as it was applied in the nineteenth and twentieth centuries, just isn't compatible with what's happening. We need to accept this and move on, instead of tying ourselves in administrative knots. And somehow, it seems, we need to still convince our leaders (in industry and in government) of this. Maybe we need to buy them all iPods or something.
Because instead of communicating and adapting, they've gotten the lawyers involved – and nothing drives up the cost of anything creative like getting the lawyers involved.
I have the maturity of a twelve year old… and so do you.
WARNING! MUCH TECH-SPEAK AHEAD.
So, there's a certain type of test that's been failing in the M7 code, and I've been working on it all day long. It has to do with the Erector 0.5.1 gem from Pivotal Labs. Now, they've since moved on in versions (all the way up to 0.7.3), but for various reasons, I'd like to avoid upgrading the gem right now. (I'm pretty sure I remember hearing there was an issue with upgrading Erector sometime in Week #1, and regardless, it was an upgrade that got us into this test fixing party in the first place – I don't want to add any complexity by upgrading more stuff that will certainly break existing code before I've dealt with these changes). Plus, I don't even know for sure if the upgrade would fix the problem we're having with these particular tests.
I think this is a good time to pause and let you all snicker a bit (yes, dad, you too), catch your breath, compose yourselves, and... can we move on now? Are you sure? (Thank you, WordPress, for giving me the power to moderate comments!)
Well then, moving on.
So, Erector hooks into Rails' ActionController rendering via the following code:
ActionController::Base.class_eval do
def render_widget(widget_class, assigns=nil)
@__widget_class = widget_class
if assigns
@__widget_assigns = assigns
else
@__widget_assigns = {}
variables = instance_variable_names
variables -= protected_instance_variables
variables.each do |name|
@__widget_assigns[name.sub('@', "")] = instance_variable_get(name)
end
end
response.template.send(:_evaluate_assigns_and_ivars)
render :inline => ""
end
def render_with_erector_widget(*options, &block)
if options.first.is_a?(Hash) && widget = options.first.delete(:widget)
render_widget widget, @assigns, &block
else
render_without_erector_widget *options, &block
end
end
alias_method_chain :render, :erector_widget
end
This is all well and good, except that we also test views individually via RSpec, which means we have to fudge variables (on any Erector widgets we test that take variables) that would normally get set through the controller. When you're just rendering a template, Rails gives you a mechanism to set local variables at this point, via:
render 'some/template', :locals => { :some_local_var => 'some value' }
You'll notice up above that, instead of passing the options along when rendering the widget (in the case where :widget is given as the first option), the substituted rendering functionality passes the value of @assigns. This works when you're using the widget through a controller, but breaks down when you try to render the widget on its own.
So, when we call the following line in one of our tests:
render :widget => Views::ScriptVersions::Show, :script_version => @script
The variable script_version that's local to the widget does not get set to the value of @script, like we'd want it to. And trying various combinations of :locals => {} didn't work either (as it would on a regular template render. I was consoled by the fact that at least one other person seemed to be dealing with a similar problem in this area of the code. However, I figured I was unlikely to get a fix for it (and for that version of the gem), as the later versions seemed to address the need to set variables without using the controller (though I still wasn't sure how easy this new way of doing things would be to put into an RSpec test). Not an option unless I wanted to disrupt a bunch of code with the newer syntax, etc.
So, after a bit of digging through the rspec gem code, I realized that the Spec::Rails::Example::ViewExampleGroup class, which the various rspec view tests inherit from, did contain a reference to a controller in order to do its magic without us needing to explicitly set one up. And that meant I could just set the @assigns local variable on that via some simple Ruby reflection magic (thank you, Ruby!) before rendering the widget, and the widget would pick up the variable as if it had been set in the controller:
controller.instance_variable_set(:@assigns, { :script_version => @script })
render :widget => Views::ScriptVersions::Show
And voila! All tests pass!
Ruby is really a great language to work in. It lets you do so many things that would take you much longer (and look much uglier) in another language. The price for this is that when something goes wrong, you have to decipher all the nifty meta-hacking, which is usually a great deal more time consuming than in other languages. Trade offs. You can never quite get rid of them. I sometimes wonder if the time one saves by coding in Ruby is completely negated by the amount of time he or she spends on treasure hunts like this. That said, the beauty of open source is that I was actually able to step through this code, line by line in the debugger (my new favourite thing to do!), to see what was happening, which is something you can't always do. I've run into similarly arcane problems while programming in Cocoa without that luxury.
Sometimes you just have to bang your head against that wall…

image from ilco on sxc.hu
Thursday night, there were 136 failing tests left on the M7 test suite. As of this morning, that number is 90. 46 fixed tests in 3 days. Not bad! Of course, 1.5 of those days consisted of trying to fix a set of tests that I never quite figured out (but fortunately, I have lots of notes and ideas!).
The career of a software developer is one of continually not knowing the answers. That's what makes the job fun. Every day, you're learning something new, solving some new problem (unless you're in one of those other software jobs, you poor soul!). But when you're racking your brains (I was corrected recently on this term – it's not wracking, it's racking) out on why Factory Girl (yes, this is actually a Ruby gem) won't work the same under Rails 2.3.2 using particular "associations" and there's only one way-too-simple example to go off of (nothing is said about creating a factory with more than one child association, which is unfortunately what we had) and not very much documentation, well... it can be a little frustrating.
But sometimes you just have to beat your head against that wall until you get it. It's a concept that most skilled creative types have to learn at some point. I remember learning guitar and it just seemed so hard to stretch my fingers far enough to make a power chord. Then one day after weeks and weeks of trying to do it, it just clicked. The process of writing songs is like that for me as well. I seem to make about ten or twenty failed attempts at one for every good one I write, and usually that one's written in under a day. But those ten or twenty failed attempts were as much responsible for that one good one as anything else. They attempts had to be made. I had to go through that frustration to finally relax and write the one that worked.
I've actually started to look for the odd brick wall. The thing about them is that they act as natural barriers to everyone else. When you look at the amount of stuff out there on the Internet, it's easy to get discouraged. Everyone has a voice now. Tools are being created every day to reduce the barrier of entry (in terms of skill) to a lot of areas of creativity. I actually think this is a good thing, as it allows people to exercise other areas of creativity. But if you want the creative life to also pay the bills, you need to continually stand out. Brick walls help you do that. Because they can be pretty daunting, and they won't seem worth it to most people. And, actually, they aren't really worth it, unless there's at least some passion backing your attack. You've got to love something about the challenge. You've got to be a bit obsessed.
And sometimes you've got to just keep going when you've got a bit of momentum. This was basically a work weekend, but I don't mind doing that the odd time. Of course, I also expect people to understand when it goes the other way a bit. Creative work does require discipline, but it also requires a little more flexibility than is built into the nine to five system. You've got to give time for brick walls, and also take time to rest a bit once you're on the other side. Still learning to properly do the latter.
Food for thought: I've been musing over this slightly related post over the last couple of weeks. I think there's a lot of truth to it. I hate the uncomfortable moments, but good things often seem to come from them.
The Art of the Confessional
I think you could make a very compelling argument that programming is simply the practice of making trade offs. Minute after minute, day after day, week after week, we're presented with these tiny little choices. The simplest choice in the life of a programmer is, of course, "on" or "off", one or zero. But few of us even need to get that close to the mind of a machine anymore. Languages like Ruby are often a joy to use because they provide such abstraction from that on or off world. By building abstraction on top of abstraction, they've given us a multitude of ways to express what it is we want those pesky machines to do.
But try as we might, we never quite get to that point where we can turn off our brains and let the machines do all the thinking – so that we simply tell them to make us breakfast (or some other absurd techno-utopianism) and have them serve up the perfect meal: exactly what we wanted, how we wanted it, efficiently delivered, and all that jazz. I mean, how would we even begin to do such a thing? First we'd have to figure out how a machine could figure out what you liked. Perhaps it could observe you and see that every morning you make yourself some toast, pour a glass of orange juice, and have a bowl of cereal (if this breakfast seems rather uninventive, it's because I hardly ever eat breakfast, which I know is very, very bad for me – but then we all do things that are bad for us, don't we?). And by observing the frequency and types of food, it could quite easily infer that a "good" breakfast to make would be one including toast, a glass of orange juice, and a bowl of cereal. But what if you were only doing that because you were a complete buffoon in the kitchen (like me)? What if you really wanted it to create exotic breakfasts from around the world for you? A new one every day! Well then, maybe we should introduce an element of randomness into this machine. Perhaps, every so often, it rolls the dice and picks a meal you haven't had before, no matter what it's observed. As a further refinement, maybe we'll let you vote after each meal whether you liked it or not, and the machine can keep a record of these and infer better random choices for future breakfasts from the data it collects... well, this is going to totally piss off the guy who just wants the machine to make him some damned toast and orange juice and cereal! It's the 21st century! Come on! This isn't too much to ask, is it? (Don't lie... you all know someone like this.)
Hopefully this gives any of you non-programmers a little more insight into how us programmers think (and to the programmers, perhaps it can give some good arguing material when your friends bug you about thinking too much about things – of course you think too much about things... thinking too much about things is your job!). As I've (hopefully) demonstrated above, we can even turn a simple breakfast into a war of algorithms. None of them is "the right way" to go. But each of them might be the best choice depending on your target user. Want to cater to grumpy old men who like their routines? In that case, the first, less complex, algorithm above is the way to go. But for the adventurous connoisseur (aka "the power user"), complexity is ideal because it means they have more switches and buttons to play with in order to tweak it into what they consider the perfect breakfast making machine.
But that's all still terribly high level for us programmers. Not even close to the necessary ones and zeros that are the only things machines will really understand (and even that, of course, is being very loose with the definition of understanding). The choices that keep us programmers awake at night are written in code.
One such typical code-based dilemma is the choice between hardcoding and making generic components. Especially with complex business logic, where it's sometimes arguable as to what constitutes the sinful act of "hardcoding" and what doesn't. After all, the ideal generic component is the computer itself. If everyone could program, we'd only really need one application, and that application would allow us to do absolutely everything given the right commands. So, at least sometimes, the more generic something is, the less user friendly it will be. And yet every programmer I know has at least in one point in their careers, striven towards this ideal generic code that will do anything and everything. It drives managers nuts. It drives us nuts (though it's an intoxicating sort of madness). And eventually, if we stay in the field, we learn to draw often arbitrary lines as to what's going to far and what's just being a lazy hack. Hard core religious folk ain't got nothin' on how heated these ideology debates can be!
Another common decision is between decoupling and duplication of effort, which is actually the thing that came up today at work that prompted this post. Here it gets to be even more fun and more difficult for your friendly neighbourhood programmer, as decoupling and the avoidance of duplication are practically stone tablet material when you're learning your trade. But it's pretty difficult to get both in ideal quantities. More often than not, you have to choose.
And at this point, you're wondering if I'll ever explain the title of this particular post. Well, here it is...
The point I'm trying to make above is that, although programming is often seen as a science where it's possible (if we're just smart enough, damn it!) to make a computer do exactly what it needs to for a particular industry or user, the real world calls on us to be artists (which is not so bad for those of us who like being artists) as well, who sometimes need to make choices they might not even be able to explain, based on time and circumstance. And yes, even very good programmers can feel very stupid trying to explain why they went one direction as opposed to another when suddenly all hell breaks loose and that other direction starts to look like the road to paradise. "Well, yes, with hindsight, that is certainly the way we should have gone! But you see, at the time, well, there were certain objectives and, well no, I can't quite remember what they were, but there was a reason we went this way in the first place, I swear!"
That's where "the confessional" comes in. If I've stolen the term from someone else, please accept my sincere apologies, but among the programmers that I know, I do believe I've at least led the charge in advocating it.
There have been several times in my career that I've faced some agonizing decision where I either wasn't sure which way was the best way to go, but had to pick one, or I simply saw the possibility of negative consequences down the road but knew there was not enough time to cover every possibility. And there were also times where I outright hacked something together because it had taken too long, I had too little understanding to make a proper solution (and no one else to ask), or the coffee wasn't strong enough to de-fuzz my brain that day. There's always a tendency to either be paralyzed by indecision or to make the choice silently and hope no one discovers your secret code-crime.
Avoid this. Write a "confessional". Every decent programming language gives you this beautiful structure called a "comment", which allows you to babble on to your heart's content about how frustrating a problem is or how you know this is an awful thing to do, but you really had no choice! Use it. Get it all out. You don't even have to make the machine understand it. You won't make the program less efficient (compilers usually strip these out, and in non compiled languages, it's easy to write something to do the same thing). And even the odd page-long confessional won't have your fellow programmers snickering behind your back about what a hack you are. Well, maybe. But you shouldn't worry about it.
No matter how long they've been (and I've had some long ones), I haven't once had a fellow programmer bring up one of my "confessionals" as criticism. On the contrary, people have actually said thanks at times, seemingly out of nowhere, long after I've forgotten writing it, because they were chasing down something to do with the problem or considering making some change that I had considered and decided against (but talked about in the "confessional") and by writing down my horrible coding transgressions and why I made them, I saved them from doing bad things they hadn't considered. Other times, I've run into my own "confessional" in trying to explain to a manager why something's the way it is and not quite being able to make a good enough argument. I suddenly hit the "confessional" and say, "Oh yeah, now I remember! It was because..." I really don't think managers care so much whether you make the odd bad decision. I think they're more interested in whether you care about what you're doing. And combining a "confessional" with something you see as a possible code-crime is a good way of showing that you care about what you're doing, even when you can't do it perfectly, for whatever reason.
Caveats. First, if you tend to write more "confessional" than code, you should perhaps consider another career. Just like swearing, a "confessional" is more effective when used sparingly. (I've always gotten a kick out of adults who desperately try to get kids not to swear, usually by admonishing them, with varying degrees of harshness, over it. I think a much better way of attacking this one is to convince them that a word like fuck is way more shocking when it comes out of nowhere... especially after 1694 much more innocent words!). The second thing is that, on longer confessionals, it's considered courteous to stick the odd joke (geeky in-jokes even better!) in there as a sort of "thank you" for someone else taking the time to slog through it all.
With those caveats in place, programmer friends, go forth and write wonderful code! Repent less, confess more, and be merry!
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.
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?