Nimble Code: Category Career

Moving On

harrisj@nimblecode.com (Jacob Harris) — Tue, 25 Jul 2006 10:37:00 -0700

Eight years. That’s how long I have worked at Alacra, starting fresh out of school in the heady days of the first web boom. Eight years is an astounding length of time to most programmers, conditioned to a revolving door approach to employment, and it is a testament to what an interesting and nurturing place Alacra is that I’ve been here this long. Furthermore, I’m hardly an anomaly among the developers, most of whom have been here well over five years too. It’s a place where people like to stay, and it feels more like a family than an office sometimes. But I am now leaving. Alacra’s been my only post-college job, and it’s simply time for me to try something new.

Next week, I will start working at New York Times Digital. Yes, that New York Times that is delivered to about 1.5 million readers in dead tree form. That number might seem impressive in itself, but 50 times that number of users read the online web version, meaning I will be working on apparently the most popular online news site in the world. Yow. No pressure there. Seriously though, I am looking forward to the challenges and I hope to learn a lot of new skills on the job. The new office building will also be pretty sweet when it opens.

Still, the change is weird. It’s definitely been a strange two weeks in this liminal zone, and I am filled with conflicting emotions. I am sad about leaving all my colleagues at Alacra, but enthusiastic about the opportunities ahead. It’s an exciting time.

Things I Figured Out

harrisj@nimblecode.com (Jacob Harris) — Mon, 03 Jul 2006 09:58:00 -0700

And now for something different (and shorter, for those recovering from the length of the last post). Insanely talented Internet prankster Rob Cockburn recently posted a short and sweet article Things I Figured Out, where he listed a bunch of interesting and slightly stupid revelations he’s had over the years. This has been followed by 15 pages of reader comments chronicling their own brilliant insights and forehead-slapping moments.

I think this is a brilliant idea for an article, and I’ve certainly had my moments of utter brilliance and sheer stupidity (even this blog probably has examples of both). So, I’m going to post a few of the things I’ve figured out on my own or, failing that, learned the hard way. But since this is a technical blog only, there will be no personal idiocy. Just technical things I now know better about now

XML is Not For Everything Great for long data files, lousy for configuration files, downright terrible for love notes. It’s not one-size-fits-all.

XML Is a Minute to Learn, a Lifetime to Master It’s easy to gloss over some of XML’s subtleties when you begin, but they’ll get you later if you aren’t careful. Sadly, very few resources articulate some of the things that’ll get you, but maybe there’s a future blog post about that.

Somebody’s Done It Better Already I’m being glib here, but one of the joys of Open Source is that if you need a generic component, it’s best to look for someone who’s created it already. For instance, if you need a logger, you could write one on your own, but there are excellent libraries out there and your time is better spent writing stuff you can sell.

HTTP Blows Away Raw Sockets Unless you absolutely, positively have no choice, there is no reason you should use raw sockets instead of HTTP protocol for remote services. Sure, it might be harder to set up in the short run, but it’s so much easier to debug and maintain in the long run this is a no-brainer. Especially since small, light, and fast HTTP parsing libraries are available for all.

Often Too Much Is Worse Than Too Little Or as Donald Knuth put it, “Premature optimization is the root of all evil.” I’ve been stung so many times by trying to be clever, I’ve finally realized I should see if it’s slow before I try to fix what ain’t broke.

Stored Procedures Are Evil DBAs swear by them because they’re supposed to control access and speed up performance. In reality, they move application logic out of your program into an awkward language (SQL) that will usually fall out of sync with your application and aren’t kept consistently in sourcesafe or migrations. Worse still, they’re the trenches for warfare between developers and operations.

Developers Black-Box Way Too Much It’s too easy to leave this with a cliché admonition to “think outside the box,” but it’s sadly true. As developers, we’re taught early the useful technique of abstracting away complexity within black boxes. This is useful for that third-party API or calling operating systems, but it’s very easy to fall into that trap in your job (“we’ve always done it this way”) or your life (“I’ll just wait for career advancement to come to me”).

Physical Contact Matters The Internet still hasn’t annihilated geography yet. And personal, physical presence still matters. Meeting people is so much better than emailing them. Which I guess is just a roundabout way of saying, yet again, I should’ve gone to Railsconf. Sorry!

You’re Going to Screw Up The First Time. Just Accept It. It’s so easy to fall into the fear of not getting it right the first time, you never get started. Get over it. Accept you’re going to make mistakes the first time around and you’ll fix it later and do the best you can. And if you can, write unit tests to make it easier to clean it up when you start.

Things Break Slowly, Rarely All at Once It’s rare you can pinpoint a single decision or piece of code where everything catastrophically failed. Instead, the road to failure and mediocrity is a gradual and painful process, of many small failures along the way. It’s hard to resist the downwards momentum, because it always seems feasible to reverse. I would like to see more project management texts that tell you how to stop digging that hole.

If You Can’t Explain It, You Shouldn’t Do It. Sometimes I think half of IT operates by overwhelming your natural instincts and confusion with so much jargon, your brain just gives up. It’s a mysticism of sorts, but the wakeup to reality again is painful. My rule of thumb is if I can’t explain it in plain English using metaphors, and optionally table utensils, then it’s not worth doing. Because it most certainly will not be maintainable.

Okay, that’s all I have so far. But I’m sure the realizations will keep coming. Happy 4th of July everybody!

Are You Happy?

harrisj@nimblecode.com (Jacob Harris) — Wed, 31 May 2006 15:25:00 -0700

I read a lot of feeds. A lot of feeds. In my hobby trend-spotting (it’s like a dorkier birdwatching), I read my feeds to monitor the zeitgeist to see what the real Alpha Geeks are into. And the last year has had some interesting trends. For instance, dynamic languages like Python and Ruby are now firmly the new wave, although functional languages (Haskell, OCAML) and prototype languages (Io) seem to also be attracting interest. Web2.0 is a term bandied around casually, mocked, and even litigated over , but the concept seems to be here to stay. The most novel aspect I’ve seen about Web2.0 is that the Web has become a source of real tools many developers are using to manage their lives; as a holder of Sun stock much diminished in value, I guess I can at least take comfort in the fact that their adage “The network is the computer” seems to finally be coming true. Sure, it’s about 6 years later than predicted, but it’s happening.

But most interesting to me is when the alpha geeks flock to ideas not directly related to coding frameworks, business plans or the like. For instance, six months ago it seemed like every serious hacker was devouring Getting Things Done and blogging about organizing their lives. And now the new obsession is Flow. A conceptualiztion first coined in a book fifteen years ago, Flow is a term Mihaly Csiksczentmihalyi (don’t ask me to pronounce that) coined for that mental state where work is stimulating but not frustrating, intention translates effortlessly into action, and happiness and productivity are intertwined. Csiksczentmihalyi teased out a description of Flow by looking at the mental states of people practicing Zen mindfulness or risking bodily harm in extreme sports like rock-climbing or surfing. But he could just as easily described the euphoric states of serious computer programming. Small wonder this book has now been “discovered” by the alpha geeks, this fleeting feeling is what we find so addictive about programming in the first place.

The basic concept of Flow is that certain tasks make us happy to do them because they exist within a narrow channel between fear and boredom, because they encourage us to improve our skills but do not overwhelm us with too many challenges at once (for Donnie Darko fans, the goal of flow is to find the middle of the fear-love axis). We developers are well-acquainted with that fear. It’s the fear that keeps you from refactoring that legacy system because you’re not sure what would break, the fear that keeps us using a clunky library because we can’t test changes, the fear that makes deploying the new version to the server nail-biting because it’s crammed full of changes that might take it down. In short, fear and specifically fear of change is a constant state of mind for too many programmers, but it doesn’t have to be. A state of happiness is possible if you can conquer the fear.

Flow is the reason why some frameworks like Ruby on Rails are so appealing to programmers; it straddles that line between utter boredom (coding a web site in PHP like always) and high anxiety (having to master a complicated system like Cocoon just to print out “Hello World”). The key is allowing people to add capabilities (like authentication, tagging) as their skills grow, but not require everything to be planned up front. It conquers the fear of change, but hacking change into smaller steps. What makes a framework good (the same is true for languages, methodologies, testing, architectures) is how it destroys this anxiety.

For most of my career, the basic question asked of developers was are you productive? Computer programmers are naturally obsessed with productivity. This is after all a field where good programmers can outperform bad coders by several orders of magnitude. and for years the industry has marketed to this by selling tools that promise leaps in productivity. The key to productivity was seen only through uses of higher-level toolsets/IDEs or APIs. This is a philosophy Cote has memorably termed Right-Click Coding because of all the right clicking and fiddling you have to do to get anywhere. This was seen as a development accelerator, because it enabled poor developers to do complicated things like enterprise integration and GUI development without needing to actually write code or learn details of how things work. But, I think that overall such tools have actually decreased developer productivity in several ways. Like a teacher teaching only to her worst students in class, the wizards and libraries stifle and frustrate more able programmers. And since they remove developers from using the underlying code, wizards only accelerate bloat and complexity in their underlying code bases.

Worse of all, the fear was still out there. Indeed, like air conditioner output makes city streets hotter, they’ve made the situation worse. By piling away programming within massive APIs and single-purpose wizards, this approach has created a nightmare of complexity waiting to ambush more able developers. Now the question becomes are you compliant? Being savvy to the latest standards, libraries, or buzzwords is touted as the key. But the difficulties people have had using SOAP is but one example of how compliance doesn’t really help either. Just mention “interop” to any CTO or high-level architect and you’ll see what I mean. The complexity (and the fear) are still there, standards compliance just blames the programmer when things go wrong.

Instead, it’s time for a new question: are you happy? I think the growing interest in Flow and GTD and higher-level languages and test-driven development and agile project management reflects a sea change in attitude by the alpha geeks. Trying to find happiness through artificially increasing productivity is like putting the cart before the horse. The key point of Flow is not that productivity fights fear and creates happiness, but recognizing that creating happiness is what creates productivity. I think it’s about time, if we want to avoid the descent into compromises and disillusionment common in computer science. So, get in touch with your feelings when deciding about that design, language, system, api, etc. and ask yourself “am I happy doing this?” I think your instincts are a better guide than you know. Trust them. And don’t be afraid to be happy.

Update: I added some links to the original book as well as discussion in a short take posting. Happy reading!

The Dangers of Heroes and Martyrs

harrisj@nimblecode.com (Jacob Harris) — Wed, 08 Feb 2006 20:02:00 -0800

In my last posting, I riffed at dubious length about how taking responsibility for your code (from testing and maintenance through fighting fires in extreme situations) was a lot like cleaning up after your dog—a frankly unpleasant task, but one that you owe to your colleagues and customers. More importantly, I feel you owe this obligation especially to your fellow software developers of all stripes, as we are all hurt by the cynicism that results from crappy code being left in the world.

Maybe it’s the fact that I was out yesterday for an extremely rare sick day, but I’m feeling philosophical again today about a related yet opposite problem that also strikes software developers: the hero complex. And since I’m in this frame of metaphor, it’s time to return to dog poop to explain the craziness of the hero complex. When I’m at the dog run with Bella, I always clean up her mess. And occasionally I will go and clean up someone else’s if I’m feeling charitable. But what if I were to scour the dog run for all messes and clean them up, even if other owners there should be watching after their own dogs? What if I were to regularly go to the dog run at 3am in the odd chance that there might be some more poop I could clean up? What if I strutted around all proud because of my poop scoopery? What if I were to do all this because I was magically hoping for a commendation from the Parks Department? You’d think I was nuts, and yet this is exactly the kind of thinking that motivates the heroes and martyrs of software development.

Scott Berkun’s excellent book The Art of Project Management is the only project management I’ve seen so far that talks about the dangers of this hero complex to software development. The problem with hero developers is that they derive their self esteem solely from their rescue efforts, and this can create some real problems for the software. It might encourage code to be released recklessly with little or no testing, because the developer feels he can fix all problems that occur. If the hero is really good, it might mask serious problems in the organization (a horrible testing process, other bad developers who really need to be replaced). Worst of all, the hero complex might lock the organization into a constant fire fighting mode, where all resources are allocated in reaction to things breaking on a regular basis, leading to poor strategic vision, a lack of energy for new projects, and ultimately complete burnout.

The hero complex is ultimately a problem of self esteem. In a few cases, the hero has a huge ego, which leads himself to think he really can single-handedly tackle any grand challenges that come his way (hopefully he doesn’t take down the company in the process). This is usually what most people think of as the hero complex problem, where a charismatic cocksure loner takes everybody down with him. But for most developers, the hero complex emerges in a different fashion out of low self-esteem. We have no real idea what value we’re contributing to the company, because we only get feedback when things go wrong (negative and angry), and any positive feedback usually comes at most once a year in the form of a performance review. And so, many developers easily find themselves seeking out the positive acclaim through the hero complex. But many more find themselves sacrificing more and more of their selves to curry favor with their bosses; I call this the martyr complex. For instance, you might find yourself volunteering to clean up and cover for other people’s messes, because you’re worried you’re not enough of a “team player.” You head into the office very early and work late, grab more things to be responsible for without any additional pay or help, get added to pager duty for evenings and weekends, even stagger in with a high fever from the flu –- all of this is considered worth it for getting your boss’ notice and praise. Which is crazy, because your boss most likely doesn’t care (or you work for a soulless tyrant who thinks you should put him before your own family). No offense, but you usually don’t matter as much to the company as you think you do. You need to redefine your self-esteem.

But isn’t the alternative just nihilism? No, you instead need to develop a true sense of what you contribute to the company and how the company in turn contributes to your career path. I hope to delve into my own experiences and my own dabbling in martyrdom. But that’s a subject for another time…

If You Can't Scoop The Poop, You Shouldn't Own A Dog

harrisj@nimblecode.com (Jacob Harris) — Thu, 02 Feb 2006 15:59:00 -0800

If you own a dog in New York, you’re probably very familiar with the sentiment of the title. New York has “pooper scooper laws” that require all dog walkers to clean up after their dogs. It’s not really pleasant to clean up after my dog, but it’s something I accept as part of owning her. It’s simply being considerate to my fellow person, but especially to my fellow dog owner; when someone doesn’t clean up, it makes all of us look bad.

Perhaps it’s a result of fatigue from having stayed up late the night before fixing an urgent bug, but the next morning at the dog run with Bella this seemed like a remarkably good aphorism about taking responsibility as as a programmer.

I can’t really give details, but I was up the night before fixing an extremely critical bug. I was fixing the bug because it was my fault. And I was fixing it that night because it was vitally important it not inconvenience customers any further (it had already affected them for a few days). And the bug was completely my fault, not the code’s, not the operating system’s, not my coworkers’ or the QA testers’, all mine. And this is what I told my boss and my coworkers, and this is what I think was also told to the customers.

This may sound like I am only pointing out what’s natural (like tooting my horn about how my heart is able to speed up when I exercise). But from my experience, software developers are horrible at handling failure. We blame it on the language we write in, the overwhelming complexity of our tasks, those testers we expect to find all our bugs for us or those project managers we expect to manage all our time for us. When we fall behind on deliverables, most of us keep silent and vainly hope we can catch up before the next milestone (a mistake so common it’s earned the euphemism hope creep among project managers). And when we mess up technically in front of the customer, we mask it in euphemisms like a technical error has occurred whose passive voice make the customer wonder if they’re being blamed and if errors just magically fall from the sky like rain.

To be fair, taking responsibility hurts. It damages your pride, makes you look bad for the moment, and might almost feel like a career-limiting move. But as Chad Fowler puts it in My Job Went To India, you must learn how to fail. Your managers might be pissed at the moment but I think honesty as well as concrete plan for fixing things and taking action will impress them. Your customers might be annoyed but will appreciate your forthrightness instead of fuzziness when explaining what broke and will love it if you can make things right as soon as possible instead of a few months. It’s good for your fellow developers because it fights the cynicism and despair that result from too much unapologetically bad software already. And it’s good for your character. You will actually turn out the stronger for having taken your lumps and emerging from it.

So, the next time something breaks (and there will be a next time), embrace it. And if that’s too hard for you to do, get a different career; and don’t get a dog.