Posted by Jacob Harris
Wed, 31 May 2006 22:25:00 GMT
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!
Posted in Project Management, Programming, Career | Tags flow, productivity, programming | 15 comments
Posted by Jacob Harris
Fri, 12 May 2006 23:28:00 GMT
A couple weekends ago, I went on a trip up to the People’s Republic of Cambridge, Massachusetts. While my wife was at a conference, I spent my time writing, thinking, and catching up with a few old friends from MIT about all the things that have been going on while I’ve been here in New York: changes to campus life, hideous new architecture, notable hacks, and the fact that my beloved dorm of Senior House still seems to be the same merry land of malcontents and eccentrics. We talked about many other things, but I recall most clearly the talk about books.
The common stereotype of computer nerds is that we spend all of our non-technical reading time with noses deep in cheap mass-market science fiction paperbacks featuring lizard men, busty women, and spaceships pointing phallicly towards a planet. But this seems more of a cheap joke than a deep truth; the geeks I know love novels. And so, in an attempt to convince the world that computer people have a special depth, I’m starting my own version of a book meme and naming three notable books along a theme and why I like them. I know this is of course what is known as filler in blog land, but it might be fun anyway. So, first up in my listing is three excellent novels for computer scientists that aren’t science fiction:
Galatea 2.2 by Richard Powers is a wistful and intriguing book about a writer named “Richard Powers” who returns from a failed life in Holland for a directionless sabbatical at a Midwestern university. While there, he becomes involved with a project in the university’s large Computer Science department to teach an Artificial Intelligence named Helen about art, literature and beauty. The result is an exploration of identity, consciousness and the emotional connections we feel with machines, made the more interesting by the intermingling of the author’s real and fictional personas in the book.
Mefisto by John Banville is a hypnotic retelling of the Faust story from Ireland’s best contemporary writer. The book comprise two symmetric episodes of the life of a main character gifted in mathematics who falls into the orbit of a seductively mysterious man. Equivalences, symbols and symmetry (it’s no coincidence the book begins and ends with the word “chance”) make for some interesting connections without the gimmicky annoyances of more experimental textual structure. Those of the scientific bent may also prefer Banville’s books Kepler and Copernicus.
Gravity’s Rainbow by Thomas Pynchon is a mess of a book. Ostensibly dealing with a mystery about the V-2 rockets at the end of World War II, it becomes a grand descent into some disparate subjects as chemicals, sado-masochism, conditioning, identity, race, and an immortal lightbulb. It might not make complete sense the first time through (or even subsequent times), but it definitely is a dense exercise in style unmatched by any. Besides, any novel that can inspire cool art like this can’t be bad.
What’s the next Three? I don’t know. Maybe poetry for pretentious people or weird books that mix text and pictures. Feel free to do your own or make a suggestion below.
Posted in Books, Filler | Tags books | no comments
Posted by Jacob Harris
Tue, 25 Apr 2006 17:44:00 GMT
In an apparently blatant attempt to be more like Amy Hoy, I’ve decided it’s time I did some Intro to Rails writing. Tonight I’m going to be giving a little talk on what I’m calling Rubyisms as seen in Ruby on Rails. I think one of the things that makes Rails so cool is how it is built upon some of the best aspects of Ruby’s style: duck typing, symbols, blocks, and metaprogramming. And yet, I think many newcomers to Rails don’t really notice some of the magic going on behind such simple declarations as
<% 30.minutes.from_now %>
or more complicated Rails cases like
class Review < ActiveRecord::Base
belongs_to :article
validates_presence_of :author
end
My humble little slideshow goes out to those Rails newcomers hacking code to look like PHP or Java. The conceit is to use some sample Rails code as starting points for deeper explorations into some of the Ruby coolness lurking inside Rails. This is a nice little look under the hood, but I hope it will educate people new to Rails on how to embrace Ruby style for cleaner and cooler code.
I’m posting the slides early for some last minute feedback and I might update these files if any other errors are found. I’d like to thank NYC.rb compatriots Sebastian Delmont, Ryan Raaum, Trotter Cashion, and David Black for their help and corrections as well.
The presentation itself is two parts. I’m releasing it here in two style. The light version is stripped of interstitial chapter screens and is a lot easier on the bandwidth:
If you like what you see there and want to get the version I’m presenting with images, the full 2MB PDF dump is also available:
Anyhow, I hope you enjoy my little presentation, and as always feedback and corrections are welcome in the comments.
Update (8/2/06)
This presentation is now available for sale as a digital shortcut from Informit (54 pages, $9.99). Please see my Rubyisms Redux for a small pitch and purchasing links. Thank you!
Posted in Web Coding, Programming | Tags rails, ruby | 7 comments
Posted by Jacob Harris
Mon, 24 Apr 2006 17:26:57 GMT
I’d like to apologize for the silence on this blog. Way back in the days before MeasureMap I used to feel like I had to keep writing for my many regular readers (all 12 of you as I now know), but the inspiration has just not been there recently. It hasn’t helped that I have been out of town on 2 separate occasions and with enough work to keep me busy and focused. But I also have been purposefully staying away from my blog. It’s not that I can’t find things to post about, it’s just that I haven’t felt they’re really interesting enough to say (I like to do more than belabor the obvious).
I hope to return with more content in the future, but this period of lying fallow has been immensely inspirational and productive in so many other ways; in short, it might be a while. Thanks again for your continued patronage.
Posted in Meta | 2 comments
Posted by Jacob Harris
Thu, 09 Mar 2006 23:24:00 GMT
Okay, I won’t deny that this is a new category of postings inspired directly by Slashdot’s notion of Slashbacks, short little postings that track followups to previous postings as well as miscellaneous tiny bits that don’t warrant their own postings, but are still above the level of bookmarks or Kottke’s remaindered links. I still am a firm adherent of Slow Bloggging, but I like to update notable developments to previous postings too.
Impressive computer security expert Bruce Schneier has posted his own similar analysis on the excessive confidence being placed on data mining as a counterterrorism tool (Data Mining For Terrorists) that’s worth a read. Not only is it smart, it’s well-written to boot.
Of course, Congress did have a chance this week to assert some oversight over domestic spying and the like. And what action it was, as they promptly rolled over to avoid any possible political embarrasment for the GOP. The Roman Emperor Tiberius’ comment to the Senate of his day is as apt today: “how eager you are to be slaves”.
The Emerging Technology conference has concluded and there have been several nice talks posted. One of the major themes this year was discussion about the Attention Economy, how to cope with information overload and rise to the top. O’Reilly has some summaries of talks on this subject by Clay Shirky, Seth Goldstein, Felix Miller, and Ray Ozzie. Tim Bray’s summary is also good too.
. While you’re at it, be sure to check out Entrepeneurial Proverbs as well.
If you were intrigued by future business of RSS, all of these should be worthwhile reads for you.
I brought my Canon camera back to life last weekend. All it took was removing the outer case, extracting an internal hidden battery and replacing it after an hour to reset some internal component. That’s it. Luckily I’m not scared of opening up electronics, but it still galls me that Canon charges $175 to do this very thing, The disposable mentality behind consumer electronics still mystifies me.
Posted in Short Takes | Tags etech, oreilly, tia, topsail | 3 comments
Posted by Jacob Harris
Wed, 01 Mar 2006 23:21:00 GMT
Lost in the last few weeks in the incessant coverage over Dick Cheney’s decision to hunt the ultimate prey were some interesting revelations about the NSA’s new mechanisms for spying on electronic communications. The Christian Science Monitor broke this story first, report on a system named ADVISE that would spider blogs, wishlists and other relics of online presence to build up dossiers on people. Some people thought that ADVISE was simply the rejected Total Information Awareness (TIA) program in new clothing, but Newsweek in a truly excellent work of reporting broke the information that the core of TIA was actually renamed to a project called Topsail and ADVISE was something else. TIA’s core motivation was to simply scan communications for “suspicious activities” and then notify human analysts of potential problems. ADVISE seems to have a much grander scope of building up dossiers of people’s interests and intents to identify “suspicious people” instead. Yikes.
In some sense, this is nothing new. Way back in 1993, the NSA made waves by trying to pass through a mandatory encryption standard called the Clipper chip that would enable the government to decrypt any encrypted communications and the Echelon project has been steadily accumulating intercepted electronic communications under the NSA’s purview. But the NSA has always had issues analyzing the volume of messages they grab and very, very little of the data they retrieve ever makes its way in front of an analyst. Making light of this, some Emacs developer even added a feature M-x spook that would spit out a series of suspicious words suitable for activists to add to their email and overwhelm the already overstrained capabilities of the government like so:
top secret SAFE terrorist ANZUS New World Order enforcers radar TELINT Serbian advisors FIPS140 INSCOM government CNCIS secure
But here we are again, with the government claiming a need to spy on us and the media leading a fight against it. If it continues like it has though, we fighting this are destined to lose. The problem is that most of the ensuing discussion of the government’s data mining operations have been like those for the wire tapping scandal; criticism is focused on the political and ethical problems of the systems and lies are exposed, but the underlying technical problems are glossed over by tech-averse journalists. Indeed, most discussions on the legality of wire tapping implicitly assume that the technology is completely effective but should be avoided strictly out of moral concerns. To see what I mean, recall how the debate over torture that started last year played out in newspapers and TV shows. The “anti-torture” side would start the argument by positing the moral horror of torture. The “pro-torture” side would almost always then counter with a hypothetical situation of capturing a mastermind who we are unquestionably certain knows about a master plot to destroy an American city and from whom torture is the only way to get such information. The torture advocate thus sidesteps the moral horrors of the situation by claiming there is no viable alternative. Of course, such situations never happen and torture rarely ever yields true information, but that’s besides the point. The argument is thus glibly reduced to “idealists vs. pragmatists”, and in these times the pragmatists always win the debate for public opinion.
This process will likely happen again with the debate over data mining. That Newsweek article does an exemplary job of exploring the technical issues, but they’re an exception to the rule. The pragmatists will advance the argument that nobody really like spying on Americans, but it’s the only way to catch the bad guys. And this is what makes me really upset. It’s bad enough that data mining is likely illegal and invasive, but even more galling that the system most likely will never work in the first place.
eavesdropping emc ARPA HAMASMOIS Aldergrove AGT. AMME Freeh White House jihad csystems MIT-LL 22nd SAS NWO pink noise mania
So, what are the technical problems that make such a system unfeasible? For starters, this isn’t actually data mining. I used to work at a data mining software developer (Dimensional Insight) and the goal of those products was to organize complicated data into easily traversable ways for analysts to drill down for connections. In a typical case, you might want to look over your sales data for the last year to see how products sold in particular parts of the country, which sales divisions did best, or similar queries. The process is human-driven and its sole purpose is to represent complex multi-dimensional data (ie, price, product, sales person, city, region, state, time, correlation to other product sales, etc.) in an easily viewable and usable manner to drill down through the data for connections. In addition, data mining involves looking backwards from the present to gain insight into past purchasing patterns to drive future sales (the classic success story is a supermarket finding a correlation between diaper and beer sales).
Instead, the NSA largely seems to be interested in predicting novel future behavior and retrieving warnings when suspicious activities occur. This is actually more in line with Artificial Intelligence research on classifiers. Essentially what the NSA seems to be striving for is some sort of theoretical Threat Box which can be fed a steady stream of events and spit out a warning for human analysts to follow up in certain cases. Whether the backend classifier is a neural net, support vector machine, or other sort of technology, the process of training classifiers usually includes the same parts. First, a training set needs to be assembled out of a mixture of scored positive and negative events. So, if you were creating a “terrorist email classifier”, the positive events might be emails from Osama Bin Ladin, the negative would be emails from your Aunt Sue (there are usually many more negative than positive selections). When the testing is done, a similarly pre-classified testing set is used to evaluate how good the classifier actually is. The goal of a well-trained set is to make the correct correlations between certain inputs (so that the presence of “bomb” and “white” and “house” triggers an alarm), but a constant risk with such systems is the danger of erroneously assuming certain correlations are meaningful (eg, all of Mohammed Atta’s emails included the word “the”, so the system concludes that “the” indicates the email is dangerous). To minimize such problems, both the training and test sets usually go through a process of feature selection, where meaningless information is filtered out so it doesn’t affect the classifier. If this sounds like more of an art than a science, it is and there are several ways in which errors can manifest:
- Human Bias – people are necessary to select and classify the training and test sets as well as feature selection. This can create biases in the system that reflect the assumptions of the creators. As Malcolm Gladwell’s excellent article on profiling explored, such biases create systems that solve the wrong problems and vulnerabilities exploitable by intelligent attackers.
- Too Little Human Bias – on the opposite end of the spectrum, it’s possible to have too much faith in the effectiveness of a classifier. The difficulty here is that the judgement of the computer will be accepted as absolute. One problem is that it generally is impossible to extricate any clear explanation of the classification’s reasoning (any explanation is like teasing out thought at the neuron level, making it too low-level to be sensible). Furthermore, even if such explanations were available, the experience with the TSA’s No Fly Lists suggests they would not be made available to agents acting on the classifier output. At best, this would only mean that the NSA is inundated with erroneous data. At worst, it could lead to extensive spying, internment, and misguided strategic directions. Best not to contemplate this further.
- False Positives and Negatives – any classification system usually contains some mix of false positives and negatives. In this system, the political pressures seem to mandate that the false negatives (ie, missing a threat) should be 0 if at all possible. Unfortunately, minimizing the false negatives invariably increases the false positives, meaning that more events will be erroneously triggered. For the dangers this presents, look at item #2.
- The Wrong Tool For the Job – Even if the classifier were able to achieve a remarkable level of correctness and accuracy, it’s still possible it would be the wrong tool for the job. As one blog has observed, Osama Bin Ladin probably isn’t clicking around on Amazon, meaning that these tools for signal intelligence won’t be very useful if the enemy is not creating any signals for them to detect. How likely are terrorist cells going to be using email when you can fedex or hand-deliver documents anywhere around the globe in a few days? How hard is it to exploit steganography or misdirection to thwart any tracking systems? In this case, this elaborate NSA system just becomes another example of America’s heavy reliance on technology (smart bombs, sigint, spy satellites) over the crude and dirty human-based methods of gathering information and waging war. How many gaps in our knowledge will this system ever fill? Or are there other ways to more effectively gather information for the cost of building this surveillance infrstructure?
freedom Kennedy chameleon man mindwar BROMURE Echelon TELINT Armani Marxist Bletchley Park FIPS140 nuclear supercomputer mania USDOJ
Of course, the NSA will claim their systems are effective and already performing vital tasks in the war on terror. Indeed, the article about ADVISE reports “the system – parts of which are operational, parts of which are still under development – is already credited with helping to foil some plots.” But what are the nature of these plots? Even if I give the NSA credit and assume they aren’t being duplicitous about current problems in the hopes they can fix them later (a condition known as hope creep), I wonder if the same circular logic presented in the case of Guantanamo Bay detainees will also be applied here: Guantanamo Bay is only for Al Qaeda terrorists, therefore everybody interred there must be a dangerous terrorist. Again, what are these thwarted attacks? Are they real, orchestrated and viable or just some bored teens talking smack on MySpace? Such information will never be made publicbecause the NSA needs foiled plots to justify the system and thus any vagule plausible detected messages will become foiled terrorist plots. Meanwhile we lurch closer to national insolvency, confident in our abilities to detect the next 9/11 if only those darn terrorists would play by our expected rules. And we lay the groundwork of a national surveillance state, just ready to be exploited by some avaricious future leaders.
So, what is to be done? I wish there was something. If the stakes were not so high, I’d suggest that it might be worthwhile to update M-x spook with a whole new lexicon to sabotage the surveillance mechanisms now before more money is thrown into the whole. But these are no times for pranksters, and the only real solution is for Congress to exert the oversight they have. They killed TIA one already and the could do it again. The oversight is theirs; if only they had the courage and the wisdom to use it.
Posted in Miscellaneous | Tags advise, nsa, politics, spooks, surveillance, tia, topsail | no comments
Posted by Jacob Harris
Thu, 16 Feb 2006 20:18:00 GMT
I am aware there is something so deeply ironic about this, but I wanted to share a great link about the practice of blogging titled A Great CD Is Not A Failed Radio Station.
If you’re a blogger, you should read it. You can go there now, I’ll wait.
Most blogs suck. They don’t really say anything new. This is largely because search engines, aggregators, and advertising models all encourage quantity over quality – many short and quick observations over long analysis. Search engines love freshness in content, and fresh posts mean more clicks means more advertising revenue. And so, many people labor strenuously to post daily to their blogs, even if this makes their writing suffer.
The problem is that like any writing, blogging takes time and mental energy, and if you find yourself having to write daily or more, your blog postings will usually become little more than “me too” or “check this out” declarations – filler content with no real additional thought or analysis. This reductive trend is accelerated by the desire to want to be the first post to comment or link to something new on the web. This leads to initial kneejerk appraisals on big stories instead of more thoughtful analysis days later when the story is “old.” And so, the reckless pursuit of freshness in blog content only encourages staleness in the ideas on those pages. And the Internet begins to resemble Sunday political talk shows with their empty talking-points and flip-reactions.
As you can see from my posting schedule, I’m hardly a victim of this syndrome (I’ll call it Premature Blogification). But if you find yourself on a never-ending race to keep up posting to your blog, maybe you should try a change. Get the Blogging Monkey off your back and embrace quality and sanity again. Your readers will love it. And so will you.
Posted in Meta | Tags blogs, writing | 3 comments
Posted by Jacob Harris
Thu, 09 Feb 2006 23:53:00 GMT
It seems like it was only yesterday that I was loudly praising the bold moves Amazon was making in search, but now that is probably going to end. The head of Amazon’s A9 search service Udi Manber has jumped ship to Google. Bummer for Amazon. I guess Google is becoming the Microsoft of search, scooping up everybody eventually.
Posted in Search | Tags a9, amazon, google | no comments
Posted by Jacob Harris
Thu, 09 Feb 2006 04:02:00 GMT
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…
Posted in Career | Tags career, job, responsibility | 1 comment
Posted by Jacob Harris
Thu, 02 Feb 2006 23:59:00 GMT
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.
Posted in Programming, Career | Tags bugs, career, responsibility | 1 comment
