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.
Friday, February 2, 2007
Wednesday, January 17, 2007
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.
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.
Tuesday, January 2, 2007
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.
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.
Subscribe to:
Posts (Atom)