08/22/10

Traits & Qualities of Best Developers on a Deserted Island

What is programming perfection? While the qualities that comprise “the most productive” developer will vary to some extent based on industry and role, I believe there are a number of similarities that productive developers tend to share. Understanding these similarities is a key to improving oneself (if oneself == developer) or differentiating from a pool of similar-seeming developer prospects. In my assorted experience (full time jobs in Pascal, C, C++, C#, and now Ruby (damn I sound old)), I have repeatedly observed developers who vary in productivity by a factor of 10x, and I believe it is a worthwhile exercise to try to understand the specifics behind this vast difference.

<OBLIGATORY DISCLAIMER>

I do not profess to be kid-tested or mother-approved (let alone academically rigorous or scientifically proven) when it comes to prescribing what exactly these qualities are. But I do have a blog, an opinion, and an eagerness to discuss this topic with others. I realize this is a highly subjective, but that’s part of what makes it fun to try to quantify.

</ OBLIGATORY DISCLAIMER>

As a starting point for discussion, I hereby submit the following chart which approximates the general progression I’ve observed in developers that move from being marginally productive to absurdly productive. It works from the bottom (stuff good junior programmers do) to the top (stuff superstars do).

Levels of Developer Productivity

And here is my rationale, starting from the bottom:
mario_1

Level 1: Qualities possessed by an effective newbie

Comments on something, somewhere. A starting point for effective code commenting is that you’re not too lazy or obstinate to do it in principle.

Self-confident. Programmers that lack self-confidence can never be extremely effective, because they spend so much time analyzing their own code and questioning their lead about their code. That said, if you’re learning, it’s far better to know what you don’t know than to think you do know when you really don’t. So this one can be a difficult balance, particularly as coders grow in experience and become less willing to ask questions.

Abides by existing conventions. This is something that new coders actually tend to have working in their favor over veterans. On balance, they seem to be more willing to adapt to the conventions of existing code, rather than turning a five person programming project into a spaghetti codebase with five different styles. A codebase with multiple disparate conventions is a subtle and insidious technical debt. Usually programmers starting out are pretty good at avoiding this, even if their reason is simply that they don’t have their own sense for style.

Doesn’t stay stuck on a problem without calling for backup. This ties into the aforementioned danger with being self-confident. This is another area where young programmers tend to do pretty well, while more experienced coders can sometimes let themselves get trapped more frequently. But if you can avoid this when you’re starting, you’re getting off on the right foot.

mario_2

Level 2: Qualities possessed by an effective intermediate programmer

Understand the significance of a method’s contract. Also known as “writes methods that don’t have unexpected side effects.” This basically means that the developer is good at naming their functions/methods, such that the function/method does not affect the objects that are passed to it in a way that isn’t implied by its name. For example, when I first started coding, I would write functions with names like “inflictDamage(player)” that might reduce a player’s hitpoints, change their AI state, and change the AI state of the enemies around the player. As I became more experienced, I learned that “superfunctions” like this were not only impossible to adapt, but they were very confusing when read by another programmer from their calling point: “I thought it was just supposed to inflict damage, why did it change the AI state of the enemies?”

Figures out missing steps when given tasks. This is a key difference between a developer that is a net asset or liability. Often times, a level 0 developer will appear to be getting a lot done, but their productivity depends on having more advanced programmers that they consult with whenever they confront a non-trivial problem. As a lead developer, I would attempt to move my more junior developers up the hierarchy by asking “Well, what do you think?” or “What information would you need to be able to answer that question?” This was usually followed by a question like, “so what breakpoint could you set in your debugger to be able to get the information you need?” By helping them figure it out themselves, it builds confidence, while implicitly teaching that it is not more efficient to break their teammates’ “mental context” for problems that they have the power to solve themselves.

Consistently focused, on task. OK, this isn’t really one that people “figure out” at level two, so much as it is a quality that usually accounts for a 2x difference in productivity between those that have it and those that don’t. I don’t know how you teach this, though, and I’d estimate that about half of the programmers I worked with at my past jobs ended up spending 25-50% of their day randomly browsing tech sites (justified in their head as “research?”). Woe is our GDP.

Handy with a debugger. Slow: figure out how a complicated system works on paper or in your head. Fast: run a complicated system and see what it does. Slow: carefully consider how to adapt a system to make it do something tricky. Fast: change it, put in a breakpoint, does it work? What variables cause it not to? Caveat: You’ve still got to think about edge cases that didn’t naturally occur in your debugging state.

mario_3

Level 3: Hey, you’re pretty good!

Thinks through edge cases / good bug spotter. When I worked at my first job, I often felt that programmers should be judged equally on the number of their bugs they fixed and the number of other programmers bugs’ they found. Of course, there are those that will make the case that bug testing is the job of QA. And yes, QA is good. But QA could never be as effective as a developer that naturally has a sense for the edge cases that could affect their code so don’t write those bugs in the first place. And getting QA to try to reproduce intermittent bugs is usually no less work than just examining the code and thinking about what might be broke.

Unwilling to accept anomalous behavior. Good programmers learn that there is a serious cost to “code folklore” — the mysterious behaviors that have been vaguely attributed to a system without understanding the full root cause. Code folklore eventually leads to code paranoia, which can cause inability to refactor, or reluctance to touch that one thing that is so ugly, yet so mysterious and fragile.

Understands foreign code quickly. If this post is supper, here’s the steak. Weak developers need code to be their own to be able to work with it. And proficient coders are proficient because, for the 75% of the time that you are not working in code that you recently wrote, you can figure out what’s going on without hours or days of rumination. More advanced versions of this trait are featured in level four (“Can adapt foreign code quickly”) and level five (“Accepts foreign code as own”). Stay tuned for the thrilling conclusion on what the experts can do with code that isn’t theirs.

Doesn’t write the same code twice. OK, I’ve now burned through at least a thousand words without being a language zealot, so please allow me this brief lapse into why I heart introspective languages: duplicated code is the root of great evil. The obvious drawback of writing the same thing twice is that it took longer to write it, and it will take longer to adapt it. The more sinister implications are that, if the same method is implemented in three different ways, paralysis often sets in and developers become unwilling to consolidate the methods or figure out which is the best one to call. In a worst case scenario, they write their own method, and the spiral into madness is fully underway.
mario_4

Level 4: You’re one of the best programmers in your company

Comments consistently on code goals/purpose/gotchyas. Bonus points for examples. You notice that I haven’t mentioned code commenting since level one? It is out of my begrudging respect for the Crazed Rubyists who espouse the viewpoint that “good code is self-documenting.” In an expressive language, I will buy that to an extent. But to my mind, there is no question that large systems necessarily have complicated parts, and no matter how brilliantly you implement those parts, the coders that follow you will take longer to assimilate them if the docs are thin. Think about how you feel when you find a plugin or gem that has great documentation. Do you get that satisfying, “I know what’s going on and am going to implement this immediately”-sort of feeling? Or do you get the “Oh God this plugin looks like exactly what I need but it’s going to take four hours to figure out how to use the damned thing.” An extra hour spent by the original programmer to throw you a bone would have saved you (and countless others) that time. Now do you sympathize with their viewpoint that their code is “self-documenting?”

Can adapt foreign code quickly. This is the next level of “understands foreign code quickly.” Not only do you understand it, but you know how to change it without breaking stuff or changing its style unnecessarily. Go get ‘em.

Doesn’t write the same concept twice. And this is the next level of “doesn’t write the same code twice.” In a nutshell, this is the superpower that good system architects possess: a knack for seeming patterns and similarities across a system, and knowing how to conceptualize that pattern into a digestible unit that is modular, and thus maintainable.
mario_5

Level 5: Have I mentioned to you that we’re hiring?

Constant experimenting for incremental gains. The best of the best feel an uncomfortable churn in their stomach if they have to use “find all” to get to a method’s definition. They feel a thrill of victory if they can type in “hpl/s” to open a file in the “hand_picked_lists” directory called “show” (thank you Rubymine!). They don’t settle for a slow development environment, build process, or test suite. They cause trouble if they don’t have the best possible tools to do their job effectively. Each little thing the programming expert does might only increase their overall productivity by 1% or less, but since developer productivity is a bell curve, those last few percent ratchet the expert developer from the 95th to 99th percentile.

Accepts foreign code as their own. OK, I admit that this is a weird thing to put at the top of my pyramid, but it’s so extremely rare and valuable that I figure it will stand as a worthwhile challenge to developers, if nothing else. Whereas good developers understand others’ code and great developers can adapt it, truly extraordinary developers like foreign code just as much as they like their own. In a trivial case, their boss loves them because rather than complaining that code isn’t right, they will make just the right number of revisions to improve what needs to be improved (and, pursuant to level 3, they will have thought through edge cases before changing). In a more interesting example, they might take the time to grok and extensively revise a plugin that most developers would just throw away, because the expert developer has ascertained that it will be 10% faster to make heavy revisions than to rewrite from scratch. In a nutshell, whereas most developers tolerate the imperfections in code that is not their own, experts empathize with how those imperfections came about, and they have a knack for figuring out the shortest path to making the code in question more usable. And as a bonus, they often “just do it” sans the lamentations of their less productive counterparts.

This isn’t to say they won’t revise other people’s crappy code. But they’re just as likely to revise the crappy code of others as they are their own crappy code (hey, it happens). The trick that these experts pull is that they weigh the merits of their own code against the code of others with only one objective: what will get the job done best?

Teach me better

What qualities do you think are shared by the most effective developers? What do you think are the rarest and most desirable qualities to find? Would love to hear from a couple meta-thinkers to compare notes on the similarities you’ve observed amongst your most astoundingly productive.

05/28/10

Hint for Job Seekers: Wake Up and Write!

Over the last three years I’ve spent at least 6 months hiring, which equates to more than 1,000 applicants reviewed. But even before I had seen our 50th applicant, I was stunned by the applicant apathy that pervaded our job inbox. At first I figured it must be us. When we were initially hiring, it was for the opportunity to work for peanuts at an unproven web startup. Surely this must explain why 95% of the applications we received were a resume accompanied by a generic cover letter, or no cover letter at all.wakeup_job

But now that we have proven our business, with ample resources to bring aboard top tier talent, I am baffled at the scarcity of job seekers who understand the opportunity that the cover letter presents for them to stand out from the other 49 applications I’ll receive today.

Think about it, job seeker. Every day, my inbox is flooded with anywhere from 25-50 applicants. Each of these applicants sends a resume, and each of these resumes detail experience at a bunch of companies I haven’t heard of in job titles that can only hint at what the person might have really done on a day-to-day basis.

If you were me under these circumstances, how would you weed out the applicants that are most interesting? What would wake up you from the torrent of generic cover letters and byzantine job histories?

P-E-R-S-O-N-A-L-I-T-Y.

When I am not paying close attention, it feels like the same guy has been applying for our job repeatedly for months, each time with a slightly different form letter to accompany his or her list of jobs titles.

The applicants that wake me up from this march of sameness are those 5% that demonstrate they have actually taken the 5 minutes to understand what Bonanzle is, what about the company gets them excited, and why they would be a good fit relative to our objectives and specific job description. (IMPORTANT NOTE: Batch-replacing [company name] with “Bonanzle” does not qualify as personalizing)

Interestingly, the applicants for business-related positions we’ve posted in the past tend to do a comparatively phenomenal job at this. If only these business people had design, UI, or programming skills, they would immediately ascend to the top of our “To interview” list. But the actual creators — programmers, designers, and UI experts — just don’t seem to get it. I suppose it could be a chicken-and-egg situation, where the minority of them that do get it are swooped up immediately by companies that crave that glimpse of personality, and the rest of them keep blindly applying to every job on Craigslist without giving a damn.

The other sorely underrepresented aspect to a good application? Decent portfolios. If you’re a designer, take the slight interest I’ve already expressed toward resumes, and cut it in half. Your value is much easier to ascertain by what you’ve done than what you’ve said, and you have the perfect opportunity to show us what you’ve done by creating a modern, user friendly portfolio. On average, I’d estimate I see about one modern, well constructed portfolio of these for every 20 designers that apply. (Personal bias: Flash-based portfolio sites load slow and feel staid; I might be unique in that opinion though)

I see a huge opportunity to awaken and realize how little effort it would take to create an application that shines. You want to be a real overachiever? Why not spend 15 minutes to sign up for an account and browse the site, and incorporate that experience into your cover letter? Amongst more than 50 applicants for our first hire, Mark Dorsey, aka BonanzleMark aka the best hire I’ve made so far, was the SINGLE applicant that spent the 15 minutes required to do this. In more than 500 applications since, I have yet to see it again.

The world is rife with creative ways to get your application noticed. All it takes is 15-30 minutes of your time (including time to personalize the letter) to rise into the 90th percentile. If it’s a job you care about, you’re earning a potentially $100k salary for 30 minutes of work = about $3-4k per minute. I know lawyers that don’t even make that much.

11/26/07

Must Love Chaos and Compromise

Progress continues to lurch forward in fits and starts as we settle on the personnel configuration to lead us to launch. Having watched a handful of similar revelations occur to many of our previous team members, it has dawned on me that the same factors that make Bonanzle so exhilarating for me are the factors that cause others to turn tail and head for the highway. My conclusion is that, until you’ve experienced the atmosphere before, it is easy to over- or under- estimate how difficult it is to be a part of creating something big from scratch. As usual, Paul Graham has insightful observations on the topic, but reading his poetic account of “hard work” makes it sound more romantic than I think it is. For my time, and the time of our future potential applicants, I think it is vital to accurately describe the most important differences between the startup and non-startup company.

I don’t think that work at a startup is most accurately described as “harder” than work at a large company. One of the “hardest” jobs I ever had was keeping my brain busy while I did nothing for 8 hours a day as a web programmer at the University Bookstore. A better point of comparison between small and large company is the degree of chaos and compromise you experience on a daily basis.

Specifically, these here are my five biggest contrasts that I think startle people who haven’t been immersed in a startup before:

1. The roadmap is drawn as you go. Well, technically, the roadmap is drawn at the beginning, but the more time gets spent drawing that original roadmap, the more time was wasted when that everything-you-know-is-wrong moment happens. Startups are about doing, not speculating.
2. Despite the best intentions, things will be broken. Sometimes with no easy solutions. And it will take creativity to work around it.
3. You are beholden to deadlines. No matter what excellent new service pack is available; no matter what important features from the next milestone one would rather work on. Of course, sometimes that excellent service pack absolutely does need to be installed, so you have to figure out the relative degree of necessity.
4. You are beholden to deadlines. Items only get checked off the schedule if each and every team member is 100% productive with their time. Working at Microsoft it might well be weeks before somebody notices you’ve been spinning your wheels over a certain problem. At a startup, spinning your wheels for 3 days will show up on the schedule.
5. You are your manager. And you are your everything else. Even in a company that attempts to create specialized roles, there usually isn’t time to send an email to the manager to get a task clarified, then get ahold of your web designer to create HTML, before finally working on the original bug that had been assigned to you. Instead, each person must often use their confidence (and common sense) to guide them to a sensible solution when a task has not been well-defined (see also item #1).

Look down the list, and there it is: compromise, chaos, compromise, chaos, chaos. Is it intrinsically harder to deal with chaos and compromise than a lack thereof? I doubt it. But it does take a special personality to have the confidence, patience, and foresight to see how the decisions they make on an everyday basis might seem like chaos, but when the dust settles, suddenly something amazing stands where moments ago there was nothing.

That is the payoff that awaits those with the grit to make something big happen.

07/4/07

Buy! Buy! Buy!

I think I’ve hit upon a pretty apt analogy for the ebb and flow of getting one’s business rolling. It is the very indicator used by millions of business the world over. It is the stock market.

200_year_stock_chart.gifFirst of all — and you won’t hear me admitting this again at any point in the near future — a lot of what comprises “success” is stupid luck. I have spent hundreds of hours recruiting our team to this point, and the best people we have all 1) came from different sources 2) did not find out about Bonanzle through any of the numerous postings I’ve made to sites like Jobster and the UW Career Center. People routinely ask me (and I routinely ask other people) how to find the best people for a project, and the generally accepted answer is that nobody’s got a clue. You just keep talking to people and eventually get lucky. The stock market analog is the (fairly common) incident where a lifelong financial analyst is beaten by the S&P 500. Even seasoned analysts can’t generally compete with luck.

Second, no single day is very indicative of the overall trend. I think this is one those principles you hear a lot when talking about entrepreneurialism without really understanding it. It’s often worded as “you should expect a lot of adversity and challenges to overcome,” but when you actually experience these “challenges” (or less nicely: failures) on a daily basis, it is easy to get discouraged and lose track of the overall upward trend. What it feels like is that every time you get traction with a new idea or new recruit or well-executed maneuver, it gets negated by the Looming Unforeseeable Obstacles. But, viewed objectively, a business only needs to have slightly less failures than it has successes to win. In the stock market (and in my stock market, fantasy basketball), the same is true: trend trumps daily blips.

And the correlate to both the first and second principle? That the best you can do for either your business or stock is to put yourself in the best possible position to succeed, cross your fingers, and pray to the law of averages for a break. Oh dearest law of averages always comes to the rescue of the worthy. But eventually.

06/16/07

The Slow Learning Advocate

What does experience buy an employee? It buys a body of knowledge to draw upon. Reflecting upon the nebulous “things that went wrong,” savvy veterans can provide great value to a company by using the lessons learned from past failures to steer clear of disaster on future projects.

But this is only in the perfect case.

In the real world, most people do not have the capacity to remember specific examples of what they’ve seen. Instead, most leaders that I have worked under develop a “gut feeling” that guides their judgement. If asked to substantiate the gut feeling, these leaders can be evasive, because without being able to remember the examples, one might not be sure what specifically led to that feeling being formed. Instead of the example that brought about the feeling, they will more often cite a recent-but-not-too-relevant example that comes to mind.

halobodysuittrojan.jpg
As a leader, I have found that I am as guilty of this as the leaders before me. I do not have the ability to remember every situation that has led to my gut feelings, and so I can sometimes find myself unable to substantiate even my “stronger” gut feelings.

Now, the fact that we tend to develop a gut feeling that we can not explain is not in itself a problem. If your gut feelings are correct within the context that you assert them, fine.

But here’s a little secret that I think is the key failing of many highly experienced leaders: their gut feeling is to avoid risk, and while that gut feeling is understandable, it is also stupid.

Think about it: indiscriminately avoiding risk is the natural culmination of years of collecting examples of things that go wrong. First you work on a project that was overly ambitious and got overscheduled, so you remember to keep your scope refined. Then you work on a project that used very elaborate systems that caused you to run out of memory, so you remember to avoid very elaborate systems. On a third project, you try a new 3d algorithm that ends up being thrown out during alpha because of low-level incompatibilities, so you remember to be wary of new algorithms.

Combine all of those lessons into one lesson and what do you get? At the most abstract level, all three of these examples suggest that by taking a risk (large scope, elaborate systems, new algorithm) the project suffered.

This is why I believe that many experienced people learn to avoid risks as a habit. And this is why I make it a point not to learn from my mistakes.

You can not make significant innovations without taking significant risks. Yes, you expose yourself to second-guessing, particularly if your risks have failed before. And yes, it is far more difficult to implement a nuanced risk-aversion plan that considers the specific reasons behind past failures, rather than simply avoid all possible risks that could beget failure.

But as an employer, I believe that the holy grail of maximal ass-kicking job applicants are those that have been through projects before, failed, but are just as willing to push the envelope as they had been during their first project. They need to have learned something from their failures so as not to be derelict, but learning to simply avoid risk is the recipe for perpetual sterility.

05/2/07

Profiteers, Continued

The philosophical side of me woke up a bit disgruntled this morning. It had processed that last blog post during my 6 hours of rest, and it concluded that what I had written ultimately spelled the unraveling of capitalism as we know it. “For you see,” says philosophical side, “if a company’s profit represents only the gap between the contributions of its workers and their actual pay, then any company that isn’t losing money is operating unjustly. And any company that is losing money won’t be operating for long.” Ah, guilty as charged. So how’s about I speak more precisely?

The root of that equation remains true. A company’s profit still represents the difference between the contributions of its workers and their pay. The crucial detail here is that in this definition, a company’s “workers” also includes its top brass — the people making the deals (the other crucial detail is that some of that profit is mitigated by taxes, risk, etc. boring!). In a perfectly just company, the gap between workers’ contributions and compensation represents the value that the company’s principal shareholders bring, because they are ultimately the ones that will reap that profit.

What had induced me to carelessly paint profit as an illustration that high performers were not fairly compensated was that it’s usually true. But only of high performers. This axiom can be witnessed at most any company, but it is perhaps easiest to illustrate at technology companies, if only because that’s where I’ve witnessed it. The gap in productivity between a company’s most productive programmer and least productive programmer is usually around 10x (This is not an exaggeration; if anything, it is an understatement. Unless they are damn good at hiring, a gap of 10x is usually observable by the time a company reaches 20 or so programmers. See Paul Graham’s earlier linked articles for some exlanation of how this is possible).

The gap in salary between a company’s most productive programmer and least productive programmer? Perhaps 2x, at most 3x. Blame methods of evaluation, blame economies of scale, blame the rain, but the reality is that a programmer who is 10x better than another programmer who makes $40,000 is not getting paid $400,000. They’re probably getting paid $70,000, and hopefully, working with a boss who lavishly praises their contributions on a regular basis.

But the bottom line is that $330,000 of that programmer’s productivity is being manifest as profit for the company (or $330,000 of that programmer’s productivity is paying for the 8 overcompensated crappy programmers, if you prefer). This is not a “good deal” for the highly talented individual. But I admittedly mispoke in attributing all profit to inequity. In actuality, some profit is absorbed by future investment, some by past and future risk, and some by the shareholders who will take that profit. The rest? That is inequity.

05/1/07

The Hunt Continues

I still need a bona fide “second in command”-type partner.

How much time to invest on this search and how to go about in on a day-to-day basis? I’ve gotten some interesting opinions on this from different people I’ve asked. When I started a thread about it on Biznik yesterday, I got one opinion (from the esteemed Mr. Pierre Leonard) that I should become a more active presence in community boards to make the people come to me, and one opinion (from the esteemed Mr. Kelly Hobkirk) that I’d be better off to just focus on building the business. Of course, both of these opinions were coming from people who don’t have an intimate knowledge of the business or its current state of affairs. But independently of my situation, they make excellent points to be weighed in the overall argument of how much time to invest, and where to invest it.

However, my prevailing opinion remains that, despite the small army of helpful consultants and rad programmers and able web designers that are already contributing to this project, having an equally-contributing, self-motivated co-founder is a critical path requirement to get where we’re going at the rate I want to get there.

The next frontier of exploration was actually proposed to me by none other than my girlfriend, the lovely KT. And it’s a damn good idea: students. Yeah, they aren’t going to step in with years of experience or a rolodex of industry contacts. But as I’ve found, those assets tend to go hand-in-hand with financial responsibilities and monetary expectations. I think there’s a reason that young co-founders flock together (Bill Gates and Paul Allen, anyone? Or their arch-nemeses, Sesnoopynontranparen.gifrgey and Larry?): it’s that they’ve got fire and they’ve got freedom. Of course, more seasoned co-founders can make something work if they’ve got a cache of money and cred piled up between them, but whuppersnappers on step 29 of 800 don’t have such frivolities (observe: blog sarcasm) at hand.

In the next couple days, I’ll post a link on here to my newest student job listing. But in a nutshell, my pitch to students will be the same as my pitch to every bright person employed by a company they don’t have a share in: why do you think you’re getting paid? So few smart people seem to “get” that their salary is inherently less than their value. If their salary equalled their value, then “profit” for their company would not exist. I find it ironic that when most people hear their company is profitable they will rejoice in this fact, perhaps boasting about it to their friends; when in fact, this profit represents the difference between what the sum of the employees are earning and what the company is reaping from those efforts. The bigger the profit, the bigger the discrepancy in what people earn vs. what they produce (and in a perfect world, would be entitled to). So my pitch, quite simply, is that join us and you can be the benefactor of your excellence.

It’s the pitch that ultimately persuaded me to stop thinking like an employee.

04/9/07

Now Hiring: Animals

When posting the Bonanzle co-founder job opening on Jobster this evening, I found myself remembering one of the very first and very best articles I read on entrepreneurship, authored by Paul Graham, back in the Spek days. This article makes more brain-sticky points on entrepreneurship than any other I’ve read. It’s good stuff, but lengthwise, the article might as well be an article of the Constitution. For today’s discussion, I’ll discuss Graham’s suggestion for how to approach the most important (and challenging) element of making any startup work: selecting the right people to work with.

The short answer: “hire animals.” Specifically, Graham says,

One of the best tricks I learned during our startup was a rule for deciding who to hire. Could you describe the person as an animal? It might be hard to translate that into another language, but I think everyone in the US knows what it means. It means someone who takes their work a little too seriously; someone who does what they do so well that they pass right through professional and cross over into obsessive.

“What it means specifically depends on the job: a salesperson who just won’t take no for an answer; a hacker who will stay up till 4:00 AM rather than go to bed leaving code with a bug in it; a PR person who will cold-call New York Times reporters on their cell phones; a graphic designer who feels physical pain when something is two millimeters out of place.”

As I’ve considered this since first reading it, I’ve found that this characterization rings true with many of the top performers I’ve known, regardless of their discipline. Of course, if someone asked me what a “programming animal” was, I’d probably stammer and be slow to find the words to explain it. But when you work with them, and you see them cut through logic problems like a hot knife through butter (borrowing the analogy I used to describe Jordan Phillips when I first met him), you know you’ve found yourself a programming animal.

A very common question I’ve received from fellow entrepreneurs when I talk about Bonanzle is “Where did you find these bad-ass programmers that are working with you to create Bonanzle?” The answer is that I am fascinated by people who are excellent at what they do. In a nutshell: fascination leads to inquiry, inquiry leads to friendship, and friendship leads to working together. Of course, I’m also fascinated by and try to learn from people who I will probably never work with. But when there’s something to be done, you best bet the first people I’ll be talking to about it are those people I respect most, who also happen to be best at what they do, who also happen to be friends.

My long-term dream? I’m hoping that I can meet more people who are great at what they do every year. As I meet more and more such people, I want them to join me and each other at my weekly summer barbecues. It’ll be like Hollywood for nerds, where the common thread amongst attendees will be the respect we have for one another and the shared intent to make good happen to each other and the world around us. Then we will drink too many margaritas, Jordan will lob his three-egg hamburger into the pool, and we’ll double-dog dare whoever’s drunkest to jump into the pool immediately and save the hamburger before the 10 second rule applies.

02/14/07

Realitivity

When’s the last time you heard that you did a “really great job”? Even better, when’s the last time you heard that you did a “really great job, and here are some ideas as to how you can do an even better one”? Hopefully in the last few weeks, but working at the average company with average boss, chances are that it’s probably measured more in months or years. As an individual in search of constant improvement, I am severely bugged when I see this happen. When one acts as their own sounding board, the veracity of the evaluation they give to themselves will be inherently more random. And with randomly correct data about what was and wasn’t good, the precision with which you can determine how to improve your actions is low. After working even one year without meaningful feedback, you end up with a lot of data points representing tasks that you completed, but no bin to sort them into. They are points in space, and the value of that experience is largely diminished because of it.

So, not getting feedback=bad. But is getting feedback=good? Sometimes. A concurrent epidemic that seems to have infected many of the noble feedback givers is that of not assigning degree and example to feedback. Did you ever have a class that was graded on a curve in college, and sit in class on a day where the professor jubilantly declared that “everybody did so well on this test, I am so proud of you all!” Seldom was there a compliment that I less wanted to hear. In reality as we know it, there are few, if any, absolutes. So feedback such as “you did well last week,” ranks only slightly higher in data conveyed than no feedback at all. A disclaimer is in order here that this is coming from a computer programmer who works in a world of logic and quantifiable principles, but in my eyes, a compliment that does not come attached to a comparison and an example will still be only marginally informative. Strictly speaking, whether you are “smart” or “good at what you do” does not exist in an absolute world. It only exists relative to other people (or your past self) who do those same things worse.

“Harsh,” you might be thinking, because it is. Society likes to sugarcoat the reality of comparison by labeling those that see the world as a place of relative degrees as “competitive.” Competitiveness of this type is often discouraged in casual affairs, or even in some business settings where it is important to preserve feelings. But whether you’re winning or not, the relative nature of success is here to stay. Deal with it and grow richer in your understanding of yourself and the world. Deny it and protect your self esteem while you remain ignorant to how you could do better.

It’s “Realitivity.”