January 02, 2006

The language of interviews

When I interview someone, I usually let them use the language of their choice with between C, C++, C# and Java. There are several reasons for that:

  • I want them to be comfortable.  It's already hard enough to be in an interview, much less being forced to use a syntax or an API they are not familiar with.  Of course, I don't pay too much attention to syntactic details or making sure they use the right method name as long as the logic of what they write is sound.
     
  • It's not that I have something against Ruby or other fourth generation languages, but I found that these languages work at a level of abstraction that is a little too high to give me a meaningful insight on the candidate for a forty-five minute interview.  There are plenty of very interesting problems that are hard to solve even in Ruby or Python (and actually, it's quite likely this is the kind of problem that the candidate will be struggling with if she gets hired), but formulating the question and writing the solution would take several hours.

The real challenge is therefore to find a problem that is very easy to express and which solution in one of the languages mentioned above will give me enough information on this candidate to formulate a verdict.

Interestingly, the choice that the candidate makes already reveals a few things on their abilities.  I found that typically, C/C++ people tend to be very comfortable with low-level algorithmic questions ("pointers and recursion", to quote Joel) but fare very poorly as soon as we "move up the stack" (object-oriented design, design patterns, enterprise frameworks, etc...).  Conversely, Java/C# people are more comfortable with these concepts but get easily stumped on "tight memory" types of questions.

Of course, great candidates excel at both, which brings me to my next point.

Good developers are born good.  Their brain is wired a certain way and they can chew on any CS concept thrown in their direction and spit it out with a bow tie.  Most of these developers then go to school and move from the "gem in the rough" state to that of a "pure diamond".  School accelerates and expands their knowledge.  Of course, there is hardly anything they learned in school that they couldn't have learned by themselves, but the formal process of learning, reading book and listening to teachers saves them years and years of work.  It also expands their minds to concepts they would probably never have encountered in their professional career.

With that in mind, I find Joel's obsession on pointers and recursion quite baffling.

There are two important facts to keep in mind about pointers and recursion:

  1. They are important concepts and any serious developer should probably be comfortable with them.
  2. You will hardly ever use any of these concepts for today's typical programming jobs.

How's that for a paradox?  How do you interview for this?

Well, it's actually very easy to do a quick check on pointers and recursion, even in Java, but it's equally important to spend most of your interviewing time on other areas that are more relevant to the job the person will be asked to do. 

One of my friends pointed out that what we are seeing today is a more distinct separation between "system programmers" (kernel, device drivers, etc...  which require C/C++ and pointer juggling) and "application programmers" (for which pretty much any programming language will do, including Visual Basic).  What's really puzzling is that Joel's company produces a bug-tracking software, and it's hard to imagine why you would need an army of superstar programmers .  A few selected senior tech leads and designers?  Sure.  But an entire team of them...  doubtful.

As for Joel's reference to Paul Graham's vastly over-hyped essay "Beating the Averages", I am still trying to decide which of the following two quotes is the most ridiculous:

  • His start-up had an edge over its competitors because of the implementation language they chose.
  • Because of this choice, they were able to implement features that their competitors couldn't.

Actually, I'll call that a tie:  both claims are equally preposterous.

Paul Graham has been a dinosaur for a long time and his disturbing elitist stance ("if you don't know Lisp, you're an idiot") oozes from every paragraph of every single programming essay he has ever authored.  So far, Joel had managed to remain reasonably objective and interesting in his posts, but his extremely narrow background (Microsoft technologies in C/C++ and bug-tracking software) is beginning to take a toll on his objectivity and I find that most of his writings are more and more missing the big picture.  I hope he'll turn around soon and open up to modern programming topics, because frankly, I am having as much fun using Ruby on Rails or Eclipse and EJB3 today as I did writing Copper list based demos on my Amiga fifteen years ago or coding floppy disk drivers in 6502 on my beloved Apple ][ twenty years ago (gasp).

 

Posted by cedric at January 2, 2006 07:43 PM
Comments

I like to see developers know lots of languages, but I tend to only interview them in one - the one I need them to use (Java, for where I am these days). Very few of my questions are language specific, anyway, and I want to make sure they can work comfortably in the primary language we work in.

Paul Graham made one really good point with his "Python Paradox" - good developers tend to be interested in lots of things, and often go out of their way to learn. One of the best ways to learn more about programming is to learn new languages, to get exposed to new ideas. Ergo, a developer who knows Python (or Ruby, or Smalltalk, or Lisp, etc, but probably not just Perl) is _probably_ a developer who likes to learn, and thus is probably good.

As for Joel... I'd just wish he'd quit bashing Agile development using strawman arguments.

Posted by: Robert at January 2, 2006 08:49 PM

Good developers are born good. Their brain is wired a certain way and they can chew on any CS concept thrown in their direction and spit it out with a bow tie.

i feel this is true, but that truth makes me crazy and angry.

i love programming. i love to create something useful using a keyboard. but no matter how hard i try i feel like i am never going to be a great programmer. my brain just doesn't work in that "CS concept" direction. my brain doesn't work recursively.

and here is the one-million dollar question for me: how can i still continue programming with an expectation of turning a good programmer someday?

Posted by: nec at January 2, 2006 10:31 PM

Ok, this is a bit dissing, however I have to agree: reading Joels Blog gets really boring lately, because no new Ideas for the overall concepts can be found. The Start-Up stories are quite enterteining, but it is not the guru ideas I would expect from him.

Same is true for your Graham comments: I really like his book, but this Viaweb Story is torally overrating Lisp. The "success" (which is not really complicated in that days) was due to smart people, not due to exotic languages.

Gruss
Bernd

Posted by: eckes at January 2, 2006 11:00 PM

BTW: can you give us a sample Question/Problem you let your candidates solve in a job interview?

Gruss
Bernd

Posted by: eckes at January 2, 2006 11:01 PM

I think that in many cases the software developers do not get a chance to use a cool tool or technology because they are too busy doing mundane things. So I think we should also consider this. People forget things not because they are forgetful or dumb but because they don't use it. Mine is the perspective of an offshore developer.
How do you handle this ?

Posted by: at January 2, 2006 11:16 PM

I agree with nec. I have a bachelor's and a master's in Chemical Engineering, and have a job programming in Java. I love programming, and while it's almost all application programming, much of it not too low-level, it has it's own challenges. I spend much of my time not working actively on reading up more about software development. I think I do a better job than lots of my colleagus, mots of whom are armed with CS degrees.

About the only time I miss having a CS background is when I can't follow along with obscure technical discussions, whether among my colleagues or from the likes of Paul Graham and Joel Spolsky.


Posted by: Sumit at January 2, 2006 11:18 PM

> but the formal process of learning, reading book and listening to teachers saves them years and years of work. It also expands their minds to concepts they would probably never have encountered in their professional career

I completely agree with this. I've always been convinced that self-teaching was a very admirable task, but also an infinitely long one :-). In my own experience for example, in fact I think it would have taken a lot more time than 5 years to learn all I learnt at school.

Posted by: Batmat at January 3, 2006 12:07 AM

What doesn't match with my experiences is the need for "working" with a programming language in an interview. I mean, what sort of people are you looking for? Are you looking for programmers who don't need to have a higher education? BTW: In my studies we didn't learn any programming languages by instruction. We had to learn them by ourselves (of course the freaks already knew them beforehand, except something like Eiffel).
What I wanna say: If someone is a good software developer, then it doesn't really matter if he/she is an expert in language X. But it does matter that he/she knows about the language itself or any other language conceptually related to the requested one. Additionally the person in question will usually convince by projects completed and by his/her attitude about software development questions in general (even that is something I would not really expect in an interview, although it wouldn't irritate me).
Maybe I'm missing your point. But when talking about interviews in which to search for good candidates, I would expect some higher-level questions.

Posted by: Klaus at January 3, 2006 01:19 AM

Excellent post, Cedric. Paul Graham's a pimp, trying to skim away what he beleives make up "the cream" of ivy league schools but he keeps falling short presicely because of the reasons you gave, man's a dinosaur. He's hung up on trivalities mostly because of ego, he managed to sell a shopping cart to yahoo in 1995 which he now claims to have been "the first Web-based application" (the first??? in '95?!? even Amazon.com was around back then).

And don't get me started on Spolsky, the armchair quarterback that keeps rehashing the same microsoft stories from a bygones era.

The sad part is that today's slashdoters/diggers are looking up to these folks as heroes and worse father figures. The real heroes have exited the building, long live the real heroes.

Posted by: Ron McDermot at January 3, 2006 04:14 AM

and here is the one-million dollar question for me: how can i still continue programming with an expectation of turning a good programmer someday?

Can an average pro-musician/painter/writer continue doing what he does and hope one day he will wake up with a genius of Mozart/Rembrandt/Shakespeare? Well - no, that kind of stuff is 100% genetics.

Being simply "great", otoh, is much easier, but I can't really tell if it's possible to "learn" it or not. I must admit I never met anyone who was "average" at the begining and grew into "great". I saw people grew from "clueless" to "average" and "average" to "above average", but not to "great". (That doesn't mean it's not possible, I just say I never saw such a thing.)

Posted by: Dejan at January 3, 2006 05:36 AM

I'm going off on a bit of a tangent here. Someone commented on how programmers' value get diluted by doing mundane things.

I think the work environment is incredibly important. An average programming in a good environment will be more productive than the best programmer who has to suffer constant interruptions, meaningless meetings and lack of direction and/or vision.

So when I interview, I make sure that people have the right attitude, good enough skills and then I fight the battle of giving them that environment that will allow them to step up and deliver.

Posted by: Alwyn Schoeman at January 3, 2006 05:42 AM

Cedric: FogCreek sells Desktop Content Management system called CityDesk; as I understand, the Bug tracking software somehow happened while doing that.
Also: FogCreek has the CoPilot to facilitate remote controlling of a desktop for support purposes. This is mostly aimed at end users and tries to remove all the little obstacles for that... if you've followed the Aardvark blog (code name for CoPilot), you'll see that that wasn't completely trivial, especially for details (like how to deal with firewalls).

Posted by: murphee at January 3, 2006 05:53 AM

The use of closures in LISP significantly simplified the development of web applications that need to maintain session state between pages, according to Paul Graham. Instead of writing a lot of code/database work to deal with it (remember this is '95 so there's not really any language with built-in facilities to do this), you simply throw the problem at the LISP interpreter using closures. Execution waits for user input, then picks up immediately where it left off. All of this comes basically for free with LISP. I'm sure there are other examples of where LISP made it easier to quickly and correctly develop features.

Posted by: Evan at January 3, 2006 07:10 AM

In response to nec's question:

"and here is the one-million dollar question for me: how can i still continue programming with an expectation of turning a good programmer someday?"

I think anyone can be great at what they are doing. The key is to do something that you are proud of. Start small, and work on something until you are proud of it. Your successes will build your confidence and ability to do even greater things. You can only do something great if you have passion.

Posted by: Dusty at January 3, 2006 08:55 AM

I enjoyed this post.

> [...] I am still trying to decide which of the following
> two [Paul Graham] quotes is the most ridiculous:
>
> - His start-up had an edge over its competitors because of
> the implementation language they chose.
> - Because of this choice, they were able to implement
> features that their competitors couldn't.
>
> Actually, I'll call that a tie: both claims are equally
> preposterous.

Maybe Paul Graham is wrong, but he's not "preposterous".
Would you call it preposterous if Viaweb's competitors had
been using assembly language and Graham talked about the
competitive advantage that Viaweb got by using Fortran
instead?

The difference in level of abstraction between Lisp and the
C, C++, and Perl used by Viaweb's competitors is maybe not
as big as that between assembly language and Fortran, but
it's clearly in the same direction.

--
Aaron

Posted by: Aaron Brown at January 3, 2006 09:43 AM

Isn't Joel's point on the pointers that schools have an obligation to provide students with the fundimentials of computing and isn't he just saying that most of then are failing to do so? Isn't his posting a very very long story to say such a simple thing?

Posted by: Kirk at January 3, 2006 11:26 PM

"Good developers are born good."

Sounds like some kind of technological Calvinism. You seem to be saying that Good developers were predestined to be good developers.

Nature vs. Nurture. The age old question.

I tend to agree that there are some who are born with tendencies that can help them more easily become good developers. However, I also think that it's possible for those who aren't endowed with such good fortune at birth to become Good developers (even Great Developers) by working hard at it. I also believe that it's possible that a born-good developer might never graduate to Great developer status. Some things aren't inate. Other things can't even be taught; they have to be absorbed through real life experience. Your so-called 'born-good' developer might be able to absorb faster, but if they are not exposed to certian things they'll certainly not attain higher levels of acheivement.

So I have to conclude that it takes a mix of both nature and nurture to make a great developer and thus it is not true that good developers are born.

Personally, I don't know if I was born with good developer tendencies or not. Lately I'm coming to the conclusion that it takes a good 10 years to develop a reasonably good programmer. More like 15 to 20 years to attain the level of craftsman. I thought I was a pretty good programmer 5 years ago. Now I look back and think that I still have a lot to learn before I'll reach that point.

Curiosity. That's what eventually makes good developers.

Posted by: Os at January 4, 2006 01:40 AM

The funny thing is that Joel would probably hire the guy who would implement the Fibonacci function like this:

fib(n) {
if n is 1 or 2, return 1;
return fib(n-1) + fib(n-2);
}

i.e. the worst possible implementation, that does not do any memoization and ignores the fact that an O(log N) implementation can be achieved like explained at http://www.nist.gov/dads/HTML/fibonacciNumber.html

In an interview, I would not expect a candidate to know this by heart BUT I would expect him/her to tell me that the 2-line algorithm is naive/inefficient + be able to at least add simple-minded memoization + tell me where he would look (book, on-line resource, whatever) for a better algorithm.

Posted by: Alain Rogister at January 4, 2006 08:09 AM

my choice of language is java, because i have been earning my bread and butter through that, and cause its prevelent in todays environment.
Well for starters i dont like to ask questions on api, thats what javadoc there for and you can look over anytime, i might ask questions beginning on concepts like oops, polymorphism and abstraction, if all goes well jump the questions on enterprise level, later move on to listen a personnal problem they might have faced in there projects and how did they handled that,
I also might agree with Sumit above ,well no personnel grudge against CS degree holders , I tend to find guys from diffrent backgrounds such as mechanical engineering etc to be more innovative in there approach primarily to the fact that they have learned there stuff through the hard way and not through some institution.

Posted by: at January 4, 2006 08:34 AM

my choice of language is java, because i have been earning my bread and butter through that, and cause its prevelent in todays environment.
Well for starters i dont like to ask questions on api, thats what javadoc there for and you can look over anytime, i might ask questions beginning on concepts like oops, polymorphism and abstraction, if all goes well jump the questions on enterprise level, later move on to listen a personnal problem they might have faced in there projects and how did they handled that,
I also might agree with Sumit above ,well no personnel grudge against CS degree holders , I tend to find guys from diffrent backgrounds such as mechanical engineering etc to be more innovative in there approach primarily to the fact that they have learned there stuff through the hard way and not through some institution.

Posted by: Amit at January 4, 2006 08:34 AM

Hmm, I must admit that I liked Joel's rant on JavaSchools even though I spent the entire article thinking that harping on about pointers won't get you any new fans Joel. As an earlier poster said, I think that Joel is looking for an understanding of the basics in those that he hires. I think that this is important, many do not.

An old friend left permanent employment to join the (then) burgeoning contract software business. His first contract, with a top-tier bank in the UK, was agreed after a 30 seconds hallway inteview - the manager was running late and was very busy that day. I can't remember what question he was asked but his answer was enough to get the contract.

Now before people get all worked up about bad interview practice, I should point out that this project was enormous. Each individual contibuted a very small amount to the overall whole. For me it would be a nightmare project, but for my friend and many of his co-workers, it was ideal. Excellence was not a prerequisite, competence was.

Many of the articles I read these days go to great lengths to emphasize how important it is to hire the *best* but this is only true for small organisations where people dominate over process. In large organisations where process rules, brilliance/excellence is not as important since the process ensures success albeit one based on average inputs.

Small organisations (or small teams in large organisations) need excellent people to make up for their lack of numbers. Small organisations have fewer communication paths to deal with and the org chart isn't strictly enforced. By strictly enforced, I mean that internal communication is not always along hierarchical routes through the chain-of-command but is more organic and has a coffee machine nature to it. You get to talk to the CEO/COO on a regular basis as you both make coffee/tea using the same kettle. He/she is not hidden away in some executive suite that you are rarely allowed to visit.

Anyway, back to Joel's article.

I agree with him that knowing the basics is good. My degree is in Natural Philosophy (i.e. Physics). For a long time I was not au-fait with many CS concepts. I have picked up what I needed as I went along. In some cases, I have had to hit the books to understand but in many cases, the concepts have not been hard to understand or pick up.

Personally, I think that my degree has prepared me well for my current career. I have a good understanding of electronics, I know more than most about computer hardware and architecture, and my having spent most of my life working on embedded systems rather than PC-type applications has given me a good understanding of what happens beneath the application level. I consider myself a good systems engineer and a better-than-average applications developer.

I have to say that I find the way many recent CS graduates ignore the underlying platform and its capabilites worrying. Languages like Java and C# seem to encourage this with their VM platform.

Yep, I'm beginning to sound like that old dinosaur Graham but he still makes a good point: use the best tools you can and the best people you can find.

Now, I'm not much of a LISP fan but you have to admit that many languages these days are moving toward what LISP had over 20 years ago. This is not a coincidence.

I can feel myslef about to start ranting so I will leave you with these thoughts:

1. Knowing the basics is good.
2. Understanding the underlying platform is good.
3. Abstraction is good.
4. Langues that give you powerful abstraction is good.
5. Failure to recognise the points above is bad.
6. Failure to recognise that you will often be wrong is bad.
7. Failure to recognise that your experience may be just as worthy as others is bad.

I have to say that I still struggle with number 7 but then wrong/mistakeb but confident-sounding people have that effect on many people.

Posted by: Gordon J Milne at January 4, 2006 01:55 PM

Hmm, I must admit that I liked Joel's rant on JavaSchools even though I spent the entire article thinking that harping on about pointers won't get you any new fans Joel. As an earlier poster said, I think that Joel is looking for an understanding of the basics in those that he hires. I think that this is important, many do not.

An old friend left permanent employment to join the (then) burgeoning contract software business. His first contract, with a top-tier bank in the UK, was agreed after a 30 seconds hallway inteview - the manager was running late and was very busy that day. I can't remember what question he was asked but his answer was enough to get the contract.

Now before people get all worked up about bad interview practice, I should point out that this project was enormous. Each individual contibuted a very small amount to the overall whole. For me it would be a nightmare project, but for my friend and many of his co-workers, it was ideal. Excellence was not a prerequisite, competence was.

Many of the articles I read these days go to great lengths to emphasize how important it is to hire the *best* but this is only true for small organisations where people dominate over process. In large organisations where process rules, brilliance/excellence is not as important since the process ensures success albeit one based on average inputs.

Small organisations (or small teams in large organisations) need excellent people to make up for their lack of numbers. Small organisations have fewer communication paths to deal with and the org chart isn't strictly enforced. By strictly enforced, I mean that internal communication is not always along hierarchical routes through the chain-of-command but is more organic and has a coffee machine nature to it. You get to talk to the CEO/COO on a regular basis as you both make coffee/tea using the same kettle. He/she is not hidden away in some executive suite that you are rarely allowed to visit.

Anyway, back to Joel's article.

I agree with him that knowing the basics is good. My degree is in Natural Philosophy (i.e. Physics). For a long time I was not au-fait with many CS concepts. I have picked up what I needed as I went along. In some cases, I have had to hit the books to understand but in many cases, the concepts have not been hard to understand or pick up.

Personally, I think that my degree has prepared me well for my current career. I have a good understanding of electronics, I know more than most about computer hardware and architecture, and my having spent most of my life working on embedded systems rather than PC-type applications has given me a good understanding of what happens beneath the application level. I consider myself a good systems engineer and a better-than-average applications developer.

I have to say that I find the way many recent CS graduates ignore the underlying platform and its capabilites worrying. Languages like Java and C# seem to encourage this with their VM platform.

Yep, I'm beginning to sound like that old dinosaur Graham but he still makes a good point: use the best tools you can and the best people you can find.

Now, I'm not much of a LISP fan but you have to admit that many languages these days are moving toward what LISP had over 20 years ago. This is not a coincidence.

I can feel myslef about to start ranting so I will leave you with these thoughts:

1. Knowing the basics is good.
2. Understanding the underlying platform is good.
3. Abstraction is good.
4. Langues that give you powerful abstraction is good.
5. Failure to recognise the points above is bad.
6. Failure to recognise that you will often be wrong is bad.
7. Failure to recognise that your experience may be just as worthy as others is bad.

I have to say that I still struggle with item 7 but then confident-sounding, but wrong/mistaken, people have that effect on many people.

Posted by: Gordon J Milne at January 4, 2006 01:57 PM

> Sounds like some kind of technological Calvinism.

Alain, I think you hit the nail on the head. I think you have to remember that Cedric in french and, you may not know this but the entire french education system is suffused with exactly this sort of predestination ideology (only it's more jansenist than calvinist).

Posted by: nother frenchman at January 4, 2006 03:06 PM

Nothing beats copper demos and cpu/copper/blitter memory clearing 68k code ;-) Seems like a lot of c64/amiga/... people have moved up the ladder in the last 20 years. Same here.

Posted by: Stephan Schmidt at January 5, 2006 02:30 AM

>> how can i still continue programming with an expectation of turning a good programmer someday?

Cedric is right, good programmers are born and, pretty much, can't be made, however...

You have to remember that people all develop. Even a good programmer has to learn. In the beginning you see many ways of doing something. For instance, you might hear your teammates or your boss saying that C&P is the quickest way to code.

This is where the "Genetics" kick in, you either feel in your bones that something is wrong with that statement, or you don't.

You eventually decide for yourself, and incorporate tools into your knowledge base.

I think that a really good programmer is just someone who's gut feelings are usually right. The gut feeling is actually your sub conscience normalizing/factoring the problem and giving you a hint which way to go.

Even if you have the "Gene" (I prefer natural talent), you won't become a great programmer without a lot of experience. When you do make the wrong choice, you have to see the results of that choice and be able to learn. Being open minded and constantly re-evaluating your concepts is critical.

You will see a lot of people who don't agree with this by the way, but I guarantee, it's as rare to find a master programmer as it is to find a master painter in a room of house-painters, or someone who can play piano concerts at the age of 5. It is just not possible for most people to do. If they don't understand that programming is just as much of an art as painting or music, perhaps more, then they tend to object.

But then if you think about it, how many great musicians have you met? Maybe these people just never met a truly great programmer, or didn't recognize it when they did?

Posted by: Bill Kress at January 6, 2006 11:33 AM

Everyone wants to hire superstars. Maybe it's just me, but I have trouble understanding that. I've worked on a lot of different teams in many different companies - ranging from consulting firms to large utility companies to small bleeding-edge development. One thing has always been consistent: a room full of "geniuses" gets nothing done.

There are so many common sayings around this point - "too many cooks", etc - and yet everyone in IT forgets these simple axioms during the hiring process.

A good team should be composed of 15% seniors, 50% intermediates and 35% juniors, with 1 team lead who acts as architect and final arbiter of disputes. There are simple reasons for this:

1. There is a lot of grunt work to do on an average project (even bleeding-edge ones) and seniors hate doing that kind of work.
2. Seniors need growth opportunities. That means that you need to provide them with people to mentor and more responsibility to make key decisions.

The balance within the team is important. Too many juniors will bog the team down in mentoring activities. Too many seniors and you will end up in power struggles and religious wars based on ego.

It may sound like I am suggesting that we pander to the whims of seniors. Not at all. However, I recognize that seniors have come a long way and they deserve to be able to make key decisions, take on more responsibility and move into more mentoring. Of course, in exchange for that, they should be expected to pull their own weight and get dirty.

The problem is that a team full of geniuses basically reduces everyone to the same level. Everyone now becomes the equivalent of a very knowledgeable junior with no rank, no responsibility, no mentoring ... nothing. The structure that allows for effective decision-making has been removed along with any source of motivation.

Someone once said that it was a miracle that the Manhattan Project ever produced anything at all. I tend to agree with that.

Posted by: Jonathan at January 9, 2006 02:13 PM

Just a note about becoming a "great" developer.

I had a good aptitude for science and math in high school, but went for music in college and then dropped out (repeatedly). At 25, I went to a technical college for a year and received a certificate. Not a lot of training, considering. However, I was a lead designer with my own team in 5 years. I've been doing high-level design and architecture for some time now. How did this happen? Is it just "good genes"? I don't think so. :)

I don't mean to demean my abilities, but I don't believe that ability is the primary factor. You have to have some amount of ability, but you also need opportunity and support - lots of support.

My first job was a great company that I was lucky to work for. They taught me a lot and allowed me to explore in all kinds of different directions. However, what I learned most was how to rise above poor design. Spaghetti code was everywhere and there were cases of deliberate efforts to avoid proper design in order to defend job security.

Other jobs were just as instructive - in the politics that lead to failure, the consequences of inadequate testing, the constant short-sighted designs that are punctuated with "oh, that will never happen", etc. It is interesting to note that most of what I learned were "negative" lessons - i.e., what to avoid and why. Those are probably the most valuable lessons because they help to sharpen those famous "instincts" that "talented" developers are supposed to have. The fact is, good developers are not born with those instincts - they learned them through hard experience.

Another valuable form of education comes from companies that place you in a team with more experienced mentors. A good boss will recognize the value of this. A bad boss won't care. There are not a lot of good bosses out there, so don't expect this too often. When it does happen, take advantage of it.

So, is there anything that a "talented" developer can claim to have? I can only think of one or two - and they are not that critical:

1. Discipline - you're going to need this to keep up with the self-education that we all have to go through on a regular basis
2. Thoroughness - a good developer finishes what they started and produces the documentation to go with it
3. Clarity - if you can't communicate your ideas to someone else, then you may not be able to code them clearly either
4. Aesthetics - this is more difficult

Let me explain what I mean by "aesthetics". I have found that there is a certain aspect of programming and design that is more of an art than a rigid science. This is where the "elegance" of a solution comes into play. At its core, programming is like math: the effort is successful if the code achieves the desired results. However, it may not be elegant. Elegance can come from the use of design patterns or best practices, of course, but it often requires a certain "sense" of elegance. Defining what makes a solution "elegant", however, is where religious wars begin. But most people that I know will usually agree upon whether a design is "bad" or "good" (they just can't seem to agree on "elegant").

In the end, I suppose that it's like designing a building. Most people are able to agree that a given building is "ugly" or not. However, they may not agree that the same building is "beautiful" or "spectacular". It's as subjective as art.

If you want to produce elegant designs naturally, you need to have an artistic sense, the right opportunities and the right mentors to learn from. And you need to want to learn.

I am sure that there are those that disagree with me, but that's what I believe.

Posted by: Jonathan at January 9, 2006 02:55 PM

I ran across this job posting the other day. It asks that the interested person(s) to submit a solution to the stated problem:

http://www.itasoftware.com/careers/eng/9948.php

Interesting

Posted by: Mike Jasnowski at January 11, 2006 09:17 AM

Ron McDermot wrote:

> [...] which he now claims to have been "the first
> Web-based application" (the first??? in '95?!? even
> Amazon.com was around back then).

In "The Other Road Ahead" (http://www.paulgraham.com/road.html)
Graham writes:

> For the first week or so we intended to make this an
> ordinary desktop application.

What would the desktop version of amazon.com have looked
like?

--
Aaron

Posted by: Aaron Brown at January 11, 2006 10:28 PM

Cedric and I exchanged a few emails on this and he seemed to
be saying that it was not a competitive advantage for a
company to be able to do something with less man-hours than
another company. (He can correct this if he feels it's an
inaccurate summary.)

The summary of my position was:

One explanation for the apparently low number of companies
using Lisp to kick butt in the marketplace is that Graham is
wrong. But if he's wrong, it's not because the effect he
describes doesn't exist, it's because it's smaller than he
imagines or counteracted by other things.

--
Aaron

Posted by: Aaron Brown at January 11, 2006 10:30 PM
Post a comment






Remember personal info?