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.
Wednesday, January 17, 2007
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)