The Talent Gap

In the world of developers, there is a talent gap. This is a true statement. However, the same statement is true for any job type of any sort, at all. In fact, I'm going to amend my opening sentence to the following, which will diminish its truth not a bit:

public bool ThereIsATalentGapIn(string jobType){
return true;
}

No matter what type of job or activity you can come up with, there will be some people who are better at it than others. I mean, to pick a really obvious one to use as an analogy, let's take basketball; everybody playing at the pro level is no doubt talented, but certainly they're not equally talented. Spud Webb was a better basketball player than I could ever dream of being, but Isaiah Thomas was better than him, and Michael Jordan was superior to both of them. One could argue how much better Jordan was, but that's a difference of degrees. The point is few would argue that he wasn't better, just as few would argue that all basketball players have the exact same amount of talent. So if we all agree that the fact that there are different levels of talent is self-evident, regardless of how talent is measured, in any given job, a new question comes to mind: Why do developers in particular seem to devote so much time to visibly obsessing over it?

I mean really, it seems like every couple days on one of the dev aggregator sites, someone has posted a new article bitching about all the untalented clods out there, or advising people on how to hire the best talent, or worrying about where all the talent is going, or who's hiring all the talent, or how you can best pamper and retain your talent, or whatever. The dev world zeitgeist betrays an obsession with talent bordering on the mainstream world's obsession with beauty. What's an Idiot to do?

The first thing I should admit to myself is this is basically a post about my inability to not take things personally. I read tech blogs, I hear the complaints about having untalented colleagues, and I feel a little hurt; as I say in my byline, I don't try to code poorly. I really do keep learning and I really do care about doing my job well. I like to design and I like to write code. However, when it comes right down to the basic facts, I just don't have "it," the magical "it" that makes you a monster developer, just like I don't have "it" that makes me a monster basketball player. I mean, I have more "it" at developing than playing basketball, but anyway you get my drift.
Sometimes it seems like the Great Talents just don't want us Idiots around. In concept I can't blame them, I guess, but you know, an Idiot can have his place, especially if he knows he's an Idiot. I've worked on big software projects where I was on a team with a couple Talents and a bunch of idiots. The Talents generally did amazingly difficult things and challenging things and the Idiots got the more basic, line-coding work. And you know what? It worked great. I don't want to make the "sample of one" mistake, so I won't assume our results were typical, but in our case the Idiots knew they were Idiots, and didn't try to go all high-minded or outthink anyone. We stayed within our skill range, did what the specs told us, and kept a low profile. As a result, the Talents got to concentrate more on their high-end stuff and make that work better. Also on this point, I wonder what would happen if there were no idiots. Would all software development suddenly rocket to unprecedented heights of excellence and productivity? Would we reach development nirvana? Would the "oh there are so many untalented hacks out there in software developement, why can't I work with REAL Talents?" blog posts and articles stop? I doubt it. Considering the adaptive nature of the human psyche, I imagine it would be a short time before the talent bar simply got raised, so that instead of people in say the 75th percentile of talent being considered idiots, people in the 80th percentile would get the abuse. Then when they left the industry it would be the 85th percentile, and so on. I think it's just human nature, and the bitching and pontificating and ruminating will continue ad nauseum.

So in conclusion, and to return to my earlier, not rehetorical question, what's an Idiot to do? Personally, because I can only speak for myself, I try to be aware of where I stand in the talent continuum, and decide what I want to do about it, keeping in mind that I'm only going to be able to do so much before I quite frankly run into my own personal talent ceiling. I think it sucks, but that's just life. Hard work will get me to a point, but it'll never make me a naturally gifted developer of the same caliber as the Great Talents. Also, of course, I work hard, and stay as good as I can, recognizing that if I remain mired in line-level work, sooner later I risk being replaced by cheap coders from Russia or something, and that that's just the way it goes. I don't want it to happen, and I'll do everything I can to prevent it from happening via hard work (c.v. above) and education, but as more people get brought into the talent pool, what Talent Percentile I'm in will change constantly.

And lastly, I can stop worrying about my rank in the Talent Pecking Order so damn much. I'm lucky I get to do something I consider fun for a paycheck, and I'll keep at it as long as I can. If I was gonna be a Great Developer it'd already have happened by now, so there's no point in fussing over it. I need to just focus on doing the best I can with what I have, maximizing my talents and minimizing my flaws, and let the chips fall where they may. It's the best I can do.

Traits of Great Developers

One of the things that I see and hear being discussed with great frequency is what makes a Great Developer a Great Developer. Usually, this arises in discussions about how to hire Great Developers. Joel Spolsky talks about it. Paul Graham talks about it. Everyone who has anything to do with hiring talks about it. Rank-and-file developers talk about it too, I know, and it's interesting how often people seem to come to the conclusion that it's a subjective thing, that what makes a Great Developer Great depends on the job and its requirements and other variable factors, i.e., A Great Developer who is great at writing device drivers might not be so great at developing web apps. Well, I don't know anything about that, but I do know that I've worked with some people who were generally considered to be Great Developers, and have noticed some traits that they've all had in common. I'm sure there's others, these are just a couple that I recall off the top of my head, or was recently reminded of.

1. Memory :: I don't know how they do it, but the Greats always have this amazing memory of languages, techniques, etc. As an idiot, whenever I'm asked to write e.g., SQL stored procedures (not something I have to do often), it can take me hours to remember how to do everything ("waitaminnit, how do I loop, again?"), but all the Greats I've worked with, despite their protestations to the contrary, seem never to forget this stuff. They'll say "oh, gosh, I haven't done [insert obscure programming task here] in a year or two, let's see..." and then will promptly write something great that works pretty much on the first try. It's amazing.

2. Breadth AND Depth :: The Greats make no excuses about not getting some hardware tweaked or systems settings adjusted, because they're great at all that, too. In fact, all the truly Great Developers I've worked with could just as easily have been Sys Admins or DBAs, and their choice of working as a developer seemed to be arbitrary and based solely on a preference for the type of work developers do, or something similar.

3. Task Switching :: No one likes to be interrupted, but the True Greats I've encountered have an incredible capacity for taking interruptions in stride and going right back to work as if nothing happened. When I get interrupted it takes me like 10 minutes just to get back on track with where I was, then a few more minutes (if I'm lucky) to get back to work, and even then I might not get back into that same smooth flow for the rest of the day.

4. New Tech :: I pride myself on doing a pretty good job of staying up-to-date on what's going on with web development tech (and to a lesser extent, dev tech in general), but Great Developers don't just stay current, they seem to have an instant, fundamental grasp of what a new language/framework/tool is all about, and how it might best be incorporated into various systems, be they real or imagined. Often, I've found the Greats have thought of the "next cool thing" well before it appeared, they just didn't take the time to develop it. I suspect this trait is partially a result of formal training (c.v. the next point), but I don't think that diminishes a Great Developer's Greatness a bit.

5. Formal Training :: Like any master of a trade or art, the Great Developers all seem to have had some sort of early, systematic training that augmented their own eager explorations and dealings with technology. I'm certainly not saying that formal training is necessary to become a Great Developer, but it does seem to be a common trait among all the real powerhouses I've ever had the pleasure of working with; they've all done at least some time in college as a comp sci (or similar) student. It doesn't matter if that's what their degree is in, or if they finished their degree, it's the time spent that matters, and the quality of that time. I can only think of one Great Developer I've worked with who had no systematic training of any sort.

6. Attitude :: The Great Developers I've dealt with have all been eager: eager to teach, eager to learn, and eager to do. This trait doesn't necessarily translate into business acumen or tractability, much to the chagrin of BAs and PMs, I'm sure, but I don't think it has to. I'm just talking about common traits of Great Developers here, and that doesn't entail always being Mr./Mrs. Nicey-Pants. Of course, it doesn't mean being a crabby diva, either, but that's a whole different matter of discussion anyway.

Code Stylings

Another problem with being an idiot developer is I don't have the wherewithal or academic background to really question code style. I find that for practical, in-the-trenches issues, I can often contribute something useful to how variables, classes, etc. should be named, but when it comes to things like the good, bad, and ugly of Hungarian naming, there's a high-level theoretical argument going on that I just don't grasp, and which seems to be evergreen. People were writing about it in 1998, and they were writing about it in 2004, and I'm sure they'll continue writing about it for the forseeable future. What can an idiot hope to contribute to a dialogue of such minds? I just go with whatever the conventions are in place at my current contract, and try to learn from the architects and other coders why certain decisions were made.

This applies to all types of code, too. Take this snippet of SQL, for example:

SELECT
elg.SUBSCRIBER_ID, elg.LAST_NAME, elg.FIRST_NAME, elg.DOB, en.ADDRESS1, en.ADDRESS2, en.CITY, en.STATE, en.ZIP,
p.NAME AS PRODUCT, l.NAME AS LOCATION
FROM
dbo.ELIGIBILITY AS elg INNER JOIN
SomeDB.dbo.ENROLLED_USERS AS en
ON en.ENROLLED_USER_ID = elg.ENROLLED_USER_ID LEFT OUTER JOIN
SomeOtherDB.dbo.PRODUCTS AS p ON p.PRODUCT_ID = elg.PRODUCT_ID
INNER JOIN
SomeOtherDB.dbo.LOCATIONS AS l ON l.LOCATION_ID = elg.LOCATION_ID

I don't have an issue, per se, with how this code is written. I mean, personally I find it difficult to read, but that's purely subjective. Also, I'm an idiot, so everything's hard for me. My question is more, why do it this way at all, with the TABLE as ALIAS stuff? Is there some efficiency gained by doing it this way, or is it just intended to save typing? Also, why name tables in ALL CAPS? Doesn't that make it harder to differentiate SQL key words from database objects? I always suspect that someone had a class that told them about why this was a better way to do it. It's tough to find explanations for this sort of thing by Googling it, and even when I do find an explanation, usually on an MSDN blog or something, I also usually find a Style Jihad going on in the comments that isn't helpful at all.

Process Snobbery

As an idiot, I'm used to getting goggle-eyed looks and incredulous gasps when people are introduced to the depths of my idiocy ("What do you mean you've never [insert random programming task here]? What kind of developer are you?"), and that's fine. I mean, everyone has their standard for what makes a "Real [insert profession here]," so I find this small, everyday bit of snobbery easy to ignore. It just so happens that I seem never to meet anyone's standard for what makes a "Real Developer." But one related bit of everyday snobbery that I do find frustrating is when certain activities or processes that aren't fixed or standardized across enterprises are treated as if they are standardized, and I subsequently get treated as an even bigger idiot for not somehow knowing a given group's processes without having ever been told what they are.

I mean, take functional specs as an example; I'm yet to see two companies that do functionals exactly the same. Yet when I do a functional at one company, they look at me goggle-eyed and say, in so many words: "That's not how to write a spec! What's wrong with you?" I then fight to learn their way of doing it, only to go to my next gig and go through the same thing. It's gotten to the point where I just point-blank ask people how they do specs (among other things) ahead of time to spare myself the embarassment. I mean, I'd rather have them just think I'm an idiot up front and get it over with, rather than struggle through trying to guess how they want things done and looking like a really colossal idiot.

Now, to reiterate, what bugs me here isn't that everyone has slightly different ways of doing the same thing, 'cos that's to be expected. What's frustrating is that even though everyone does it differently, they all seem to expect me to produce a perfect spec for them on the first try without them first telling me how they like it to be done, as if a functional spec was a constant across all enterprises and once you've done one, you've done 'em all. It's a no-win situation, really. Even when I ask ahead of time how a given client wants things done I still come out on the short end of the stick 'cos then they think I'm stupid for not knowing and having to ask.

I swear it feels like the upper-echelon developers have a secret club where everybody magically knows how to do everything exactly right the first time. Only, I know that's not true (duh), 'cos I hear the high-end capital-T Talents bitch endlessly about each other all the time. So what gives? Just once I'd like to have a tech lead or architect say to me "Okay, we need you to write a spec, and here's how we do specs at this company..." and then give me an actual explanation before expecting me to start churning things out. Sure would make life more pleasant.

How An Idiot Developer Solves a Problem, Part 1

The situation: I have a "contact us" web page where the list of available subject lines changes depending on what the user selects from the "who do you want to contact" drop-box. While my department is responsible for code, content is controlled by another person in a different department, and that person is going to need to be able to add and change subject lines with as little pain as possible. They'd also like to be able to add new contacts.

The thought process: I know the person who's going to be editing the page for the foreseeable future, and she's comfortable with HTML, but not with programming. I could probably get her to be cool with entering everything into an XML config file, which would allow easy deployment of new data, and be cool; because developing with XML is always cool, right? However, any new contacts she'd want to add would have to be added to the database, requiring intervention by DBAs anyway. Unless, of course, I don't use that particular database table. This is a standalone site, and one of my mandates is to make this site as hands-off as possible for developers. So if I teach the content owner how to edit an XML file, and put everything in there, effectively bypassing the DBA group, then she gets to maintain control of the content, and developers hopefully won't have to get involved so much. Also, I've heard reports that using the current method, where she edits .asp pages directly, that she's accidentally messed up code or sent the wrong file for updating. So if I do this via XML maybe that'll reduce both types of errors.

Okay, so I'll make a config file. What's at the top of my heirarchy? These things are grouped by Categories, so we'll make that the root, containing individual Category elements:

<categories>
<category>
</category>
<categories>

Lesseee, then I guess it'd make sense to have an element describing who to contact, and what the name of the category is:

<categories>
<category>
<name></name>
<contact></contact>
</category>
</categories>


By the way, I name my elements as simply as possible, i.e., one word and lower case, whenever possible because not only am I an idiot, I'm lazy, too. Now what to do about those email subjects? I could make a new file, I guess, but for this app they're bound to the category, so it makes sense to me to make them children of the category element, just like name and contact:

<categories>
<category>
<name></name>
<contact></contact>
<subject></subject>
</category>
</categories>

...and of course I can have as many subjects as I need. I'll never be transmitting these xml files as far as I know, so I'm not gonna bother writing a schema right now. I suppose I'm violating all kinds of xml best practices here, aren't I? I should probably have written a schema first, and my grammar is awfully specific. I mean, it's one thing to write an app-specific grammar, but my grammar is specific to one page of one app. That's gotta be wrong in all kinds of ways, but I'm gonna do it because it's quick, and solves my current set of problems in what I think is a reasonably elegant way.

See, this is what it's like to be an idiot programmer: I really do mean well, and I want to solve this problem in the most elegant way possible, where elegance doesn't just mean I'm programming elegantly, but that I'm also being politically elegant by making all the people happy that I need to: I'm getting done quickly using existing tools, I'm not bothering other developers and am trying to reduce further bother, and the content owner gets to keep her content. However, I always feel like there's a piece I'm missing: like there's probably some super elegant, abstracted way to do this such that the xml is reusable and infinitely extensible, and the app could be ported anywhere without any code reworking going on. But I need to get this done now. So on I go.

So but so anyway now I have an xml file. What do I do with it?

To be continued...

Writing FxCop Rules Is Really Hard Without Any Documentation

So here at work I'm currently doing lots of .NET stuff. Recently I was tasked with writing some custom rules for FxCop so we can enforce our coding standards before check-ins and builds. Unfortunately, there seems to be a dearth of FxCop Custom rules, and an even greater dearth of information about how to write them. Apparently a developer named Raymond Lewallen came right out and asked "where are the custom FxCop rules?" in Feb 05, and it seems there's still not much of an answer. If you go to the GotDotNet UserSamples area and look for FxCop samples, the results are pretty grim; fewer than 20 results, and almost nothing for the newest versions.

That wouldn't really bother me -- experience has taught me to take online samples with a grain of salt, anyway -- except for that fact that there also doesn't seem to be thorough API documentation or an SDK, and according to the FxCop FAQ on MSDN, this will continue to be the case for the foreseeable future.

So I continue to slug it out on my own. Things take a little longer for me than it probably does for most programmers, but I've managed to get a solution put together and a rule or two (all very basic and borrowing heavily from Microsoft samples) written that are working against a really simple "Hello World" console assembly. I figured out the whole where-do-I-put-my-xml-file-and-what-do-I-call-it issue through some painful experimentation and forum scouring, but when I write something like...

LocalList locals = method.Instructions[0].Value as LocalList;
InstructionList instructions = method.Instructions;

...which I got from one of the sample rules, I really have no idea what I'm doing. I can make certain inferences based on usage, but I don't know what a "local" is, or what "instructions" are, really. Is a local like what's in the "Locals" window in VS? Are instructions lines of code, or literally instructions, not to include declarations? I suppose the best way to find out, lacking an SDK (or whatever), would be to download the source code, but I don't think it's publicly available right now, or at least it doesn't appear to be. Hm. Back to trial-and-error, I guess. Maybe this is why I'm yet to work at a shop that uses any custom rules; all anyone seems to do is turn off a few of the default checks and run it like that.