Fog Creek Software
Discussion Board




What seperates Good developers from all the rest

I've been in the software industry for three years, and I’m currently studying computer science at a local college.  I've heard that education and experience = good job, but there has to be more to it than that—I continually hear that there is a lack of talent in the field, and in my job I constantly deal with clueless developers.  What do I have to do/what traits do must I posses to become an outstanding developer?  What will determine which of the thousands of CS majors graduating each year get the good jobs?

Vincent Marquez
Wednesday, December 05, 2001

Education and experience ARE very important: the first teaches you what can be done,  the other teaches you what ought not be done.  And by "education" I don't mean "gone to college", and by "experience" I don't mean "worked in the field", because it's easy just to get by without learning (as an example: I'd be willing to bet that half of my CE graduating class couldn't write a bubble sort in any language).  The ability to *learn* is what's most important.

But the thing you've really overlooked is just plain aptitude: specifically, the ability to think things through, to be thorough and suspend judgement until everything is in.  I notice that poor developers tend to latch on to the first idea that could possibly work, and then come back a week later and say, "oh yeah, but I forgot about this, and that, and that".  Poor developers generally don't know what they don't know.  Good developers are like this too -- it's impossible to be perfect -- but they do it to a far less extent.

Alyosha`
Wednesday, December 05, 2001

Keep in mind that programming well for the corporate world is different from... the other world.  I program for the corporate world, and it's really about creating code and moving on.  Totally different sort of game.

It takes intelligence, which is something one has little control over.  But in addition to that, very productive people have to be interested in the subject matter, so that their thoughts are about it and they gain overwhelming "mental experience." 

As an example of mental experience, two people may program for a year.  But as one spends her free time thinking deeply about programming while the other doesn't, she quickly outdistances him.  The main difficulty is that mental experience isn't as obvious for others to see as the normal kind, but it manifests itself in better code.

vox
Wednesday, December 05, 2001

I rather like Joel's criteria:

"Smart and get's things done." 
http://www.joelonsoftware.com/articles/fog0000000073.html

I considered myself as smart, until I found http://www.techinterview.org.

I've known for a long time that I can't get anything done.

Perhaps I don't like Joel's criteria that much.

Perhaps my old creed of 'writes code beyond the puny comprehension of others.'  (and I don't care if it doesn't work, its still very clever code.)

Ged Byrne
Wednesday, December 05, 2001

> I notice that poor developers tend to latch on
> to the first idea that could possibly work, and
> then come back a week later and say, "oh
> yeah, but I forgot about this, and that, and
> that". Poor developers generally don't know
> what they don't know. Good developers are
> like this too -- it's impossible to be perfect --
> but they do it to a far less extent.

On the other hand there are schools that favour the use of prototypes and doing things like the Japanese Kaizen: many small evolutionary steps rather than big inovation jumps.

This seems to apply to extreme programming and also to the way that is mainly associated  with open source development.

Marc van Woerkom
Wednesday, December 05, 2001

So long as you keep all such prototypes away from CEO's and VP of Sales as they'll go ahead and sell the damn thing if they have the slightest opportunity.

Simon Lucy
Wednesday, December 05, 2001

Outstanding developers never stop learning. They investigate new languages and libraries, keep up with at least some of the literature *about* development, tinker with new ideas, and, yes, read Joel on Software. From my own sample of developers that I've met, that's a necessary (but not sufficient) condition of being an outstanding developer.

Mike Gunderloy
Wednesday, December 05, 2001

If you've gotten down this far, please go back up and read Alyosha`'s last paragraph a second time.  It really jibes with my experience.  Good developers will spontaneously self-assess.  They're looking at what they're doing, and analyzing how what they're doing is great, and in what ways it sucks.

Good developers have minds of their own.  A few months ago our company went hunting for new hires.  It turned out to be really hard to find someone who had their own stuff to say about software development, rather than just repeating what their professors and textbooks told them.  How often do you think -critically- about the work you do?

One of the things that irks me is that some of my cofounders didn't quite grasp this!  They didn't see anything wrong with a programmer that followed orders.  My point was: I'm not as afraid of getting a programmer that won't do what I tell him to do, as I am of getting a programmer that will do ONLY what I tell him to do.  I'm inclined to say that this fear was borne out.

Paul Brinkley
Wednesday, December 05, 2001

Speaking as one of those sometimes loose cannons it takes a lot of self confidence in a manager to employ someone that can bring the spice of danger with them.

That that danger can also leapfrog them in ways they never considered is the blessing.

Playing safe, especially in the existing climate is probably reasonable even if it affects people like myself.

Simon Lucy
Wednesday, December 05, 2001

To Alyosha's second point, my favourite ever Larry Wall quote (taken from the end of  http://www.ddj.com/documents/s=923/ddj9802a/9802a.htm ):

"Assume that your first idea is wrong, and try to think through the various options. I think that the biggest mistake people make is latching onto the first idea that comes to them and trying to do that. [...] Take a good look at what you want to do, and try to come up with the long-term lazy way, not the short-term lazy way."

I had this plotted and taped on the wall at my previous job!

rOD.

rOD Begbie
Wednesday, December 05, 2001

I guess I should be a little bit more clear ... I didn't mean
to denigrate incremental or evolutionary development ... in fact I'm a staunch advocate of it.  I realize that it would take superhuman ability to design a large software project and to think of everything the first time through.  Still, some developers are better at seeing the consequences and ramifications of a design change than others. 

I think it's like chess -- good chess players have a great potential to become good software engineers and vice versa because it requires the same talent of holding several different candidate moves in the mind and analyzing them several moves through -- and then biting the bullet and choosing one under time pressure.  Good chess players don't see everything, but they sure see a whole lot more than poor chess players.  Poor chess players tend to just latch on to the first one-move-threat they see, which is usually very short-sighted.

I should point out that planning ability isn't always the same thing as raw intelligence.  Sometimes sheer intelligence just enables people to make more sophisticated mistakes no mere mortal could duplicate.  You see this typified in what Joel calls "architecture astronauts" -- or the flip side, which are designs where extreme cleverness was exercised in working around design oversights that would have been more easily addressed by scrapping, reworking, or refactoring the infrastructure.  Joel's right to say that you shouldn't rewrite good, working, tested code, but like the man said, sometimes you can't pour new wine into old wineskins -- or as a slightly more modern writer said, "plan one  to throw away, you will anyhow."

Software is a bit better than chess, at least sometimes you can take back moves.

[Disclaimer: the above opinions are not necessarily the opinions of my employer.  It is the opinion of my employer that I should be working.]

Alyosha`
Wednesday, December 05, 2001

So far you everyone has been helpful in their answeres to my questions, and I do feel better about my future as a developer.  I have always help myself to a high standard; critiquing myself often, and writing and re-writing code until excellence when time allows it.  I guess a follow up question would be—how do I make sure my skills are recognized? Most of the companies I have worked for hired me out of desperation, and I’ve worked my way up to lead positions (all for small companies though).  Will my non-ivy league degree and thick resume be enough?  To the managers and directors out there...what do you look for when comparing two graduates for an advanced postion?

Vincent Marquez
Wednesday, December 05, 2001

Ah, if only I knew the answer to that question, I wouldn't be stuck in the code monkey role that I find myself in now! 

I think you actually have very little to worry about, Vincent; it seems you're already been recognized by the employers you work for.  Don't worry about only working for small startups -- you probably don't want to work for a large corporation anyways.  I've worked for a startup, and I've worked for a medium-sized company, and I have to say I really agree with what Jamie Zawinski once said:

"There exist counterexamples to this, but in general, great things are accomplished by small groups of people who are driven, who have unity of purpose. The more people involved, the slower and stupider their union is." [ http://www.jwz.org/gruntle/nomo.html ]

If you have the right stuff, other people who have it too will recognize your talent; those that don't, won't, and you don't want to work for those people.  Being hired from the outside is a more difficult problem: it's easy to weed out the slow and stupid from a merely good engineer in an interview, but the difference between a good engineer and a great, management-quality one is hard to tell unless you've worked with them for a while.

At most companies, upper management are often cronies and friends-of-friends from old jobs, probably for this reason.

Alyosha`
Wednesday, December 05, 2001

As someone who's sat on both sides of the interviewing table many times, here's my two cents.

When I'm looking at people at an interview, I pay no attention to their degree, no matter how prestigious the school.  I'm also unconcerned with where they've worked.  What I want to know is WHAT have they worked on, and what did they learn from those projects?  If a candidate can white-board a simple diagram of the project, and answer questions about details on it, that goes a long way with me.  I'll ask why certain things were done, and I expect a reasonable answer, even if it's "seemed like a good idea at the time", although in that case, I'll expect some detail on how it worked out, and how it may have been done differently.

What I loath when being interviewed are the dreaded "programming tricks" types.  Those people who seem compelled to try and trip me up with some obscure bit of knowlege about the interviewer's favorite language.  In my mind, knowing a given language in extreme depth is relatively unimportant.  Programming is programming, up to a point, and they're going to have to learn our API, and codebase, anyway.  When I have to assess ability, I'll come up with a generic problem and ask for a solution in whatever language they like (language choice is often instructive).

James Montebello
Thursday, December 06, 2001

A little background:  I've worked on everything from very expensive (MES) enterprise software that sells a hundred copies at $100K+ a pop and on mass-market consumer software (we sold 1M copies of our "easier to use than Access" database package).  Now I have a small "enterprise P2P" company that is just getting rolling... which is not entirely dissimilar from the business model that Joel has instantiated.

So having worked with lots of different teams on lots of different types of software (that must, by definition, be bullet-proof and also extremely challenging in terms of complexity), I've found several traits to be required:

1)  The ability to PRIORITIZE.  Your code _always_ has 5,000 things you want to fix in it.  Being able to determine which 10 are most important NOW seems to be a gift.  I think maybe 2% of professional programmers have this ability.
2)  The ability to DEAL WITH ADVERSITY.  Your code _always_ has 5,000 things wrong with it.  When your best customer calls and has found a bug he needs fixed... and you simultaneously get three emails from QA people demanding resolution to their top issues... and someone knocks on your office door with a change request from marketing... you need to have...
3)  A good sense of HUMOR.  Life's too short to get crazily stressed out about all of these issues.  Every software shipping cycle is in CRISIS MODE all of the time.  The sooner you realize it, the better.

Oh, and it doesn't hurt if you can type 100+ words a minute.  You can be the best developer in the world, but if you type 25 wpm...

Cheers.

D Ross
Thursday, December 06, 2001

"... and I work with clueless developers all the time" or something like that.

Welcome to reality my friend. Most of us are clueless about one thing or the other. I suspect you are young and that's a great asset to any organization. Most young folks are bursting with great ideas that need tempering. The great part about getting older is that you slowly realize you don't know it all. You will discover that the more you know, the more you don't know. I've rarely found great developers who didn't have a healthy respect for their lack of knowledge. It's the ones who think they know it all that scare me.

Doug Schwartz
Friday, December 07, 2001

*  Recent Topics

*  Fog Creek Home