Steve Yegge on the average programmer



  • Programmers who haven't read this before really ought to:  http://steve.yegge.googlepages.com/being-the-averagest

    Its long, but worth it.  Key quote:


    Last year it finally dawned on me, after 16 or 17 years of this, that I just might possibly still be clueless about something important that I really ought to know, something that would make me a much better programmer. . .

    So now I have no idea how far along the programmer-proficiency curve I am, but I can at least see that I'm nowhere near the high end; I'm not even to the halfway point. My ego still assures me I'm past the 25% mark, but realistically, I doubt it. I'm probably flush with the y-axis.



  • Maybe I'm cynical, but I've noticed that if you can do everything, you will end up doing everything.



  • This is a great article. I'm sure that it resonates with a lot of people here. The way it resonates, however, is probably that they see a lot of Bobs around them. There's a Bob in the room here with me right now. He learned C# in school, and hasn't learned a new language before or since then.

    There's another developer that has real potential with a real desire to learn and advance himself. He's always asking questions about what the best way to do something is, and what some chunk of obscure code does.

    The Bob, on the other hand, is our go-to guy with general .NET questions... but he never asks anybody else for advice and will continue doing things the way he knows, wether it's the best way or not. In fact, if you tell him he's doing something in a less-than-desirable way, he'll just respond with "well, it works for me."

    I wonder how long he'll last. Maybe 10 years? Then what? With no desire to learn or grow he'll just stagnate.



  • Yeah, thats right - I imagine the average reader here is at least a few steps ahead of Bob (and I think Alex sees it too, what with the HiddenNetwork and all).  Recently, I have been motivated to go back and look for gaps in my knowledge.  It's surprising the basic computer science that you forget when you're writing high level code all day.  At the very least, being very knowledgable will give you a big advantage when you're competing against 'Bobs' for jobs.



  • @rmr said:

    At the very least, being very knowledgable will give you a big advantage when you're competing against 'Bobs' for jobs.

    At least you'd hope so. I've actually found a lot of competition from the Bobs out there, because a .NET Bob will get the .NET job before you if you're a "jack of all trades." Know what I mean? They have one skill set, and they are very confident in it. I'm not as confident as Bob in any [i]one[/i] skill set, but I [i]am[/i] confident that I can learn to do something new, and do it better than Bob already does.

    Unfortunately that sort f talk falls on deaf ears in an interview with an HR guy. They just smile and say "so... you're saying you don't have experience?"



  • This is the same thing that we've been saying here for a while: It's called "Wearing the juice". (<font size="-1">www.apa.org/journals/features/psp7761121.pdf) </font>In brief, the skills required to judge your competence are the same skills that your competence is based on. Thus, most people see themselves as above average at any task or skillset that they have even a moderate amount of competence in. That's why everyone thinks that they are above average drivers.

    I know my code is "better than most". My old employer was paranoid that I was sabatoging the code (an accusation so offensive that I ... deep breath... polite version: former employer.)  They hired an external auditor to come in and review what I'd done, and he said it was "better than most code I've seen". I used the auditor as a reference.

    I'm required by my profession to keep my knowledge current. I'm also supposed to remember that the sum total of my knowledge is zero. 



  • I wish 'Bob' wasn't the name of choice for bumbling average people!



  • [quote user="djork"][quote user="rmr"]At the very least, being very
    knowledgable will give you a big advantage when you're competing
    against 'Bobs' for jobs.[/quote]

    At least you'd hope so. I've actually found a lot of competition from the Bobs out there, because a .NET Bob will get the .NET job before you if you're a "jack of all trades." Know what I mean? They have one skill set, and they are very confident in it. I'm not as confident as Bob in any [i]one[/i] skill set, but I [i]am[/i] confident that I can learn to do something new, and do it better than Bob already does.

    Unfortunately that sort f talk falls on deaf ears in an interview with an HR guy. They just smile and say "so... you're saying you don't have experience?"

    [/quote]

     Unfortunetly that's very true, I recently applied for a .Net postion, and was confident, being a programmer, with a few years of VB 6 in the past, that transfering all my skills from C++/java etc.. that .Net wouldn't be a problem. I did not get the job because quote "We are looking for somebody with 3-5 years experience in .Net". 

    I don't know maybe I am taking it too far but if they wanted a jr.-mid level .Net person chances are that's all they know and will *place witty remark about using a certain tool for every project here* the team to death. The company produces a diverse set of bioinformatical or statistical software. So, C# pretty much fits the bill in most cases.

    For me, when I get a project, I look at the requirements of the project and choose the best language for the job, if I know the language or not, because after all it's jsut syntax learning at it's basic level. unfort. this does not equate to HR or a team of .Net Bob's  "well we really need him to know C#" ... I'd say true to some exent don't get me wrong there is probably a lot in C# that jsut doesn't equate. But, on the other hand, there is nothing I couldn't learn by picking up a book within the 2 weeks notice that wouldn't get me up to speed.

    Bottom line, I am willing to bet a "real" programmer would have no problems with .Net, learning the funky object tree, having the ide genreate code, code completion and would be miles ahead of somebody who ONLY knows .Net only for the simple fact the.Net provides you with what you "expect" from a language as far as libraries and syntax and that programmers should be familiar with basic concepts of data modeling, etc. Am I wrong? How easy is is to write code that "works" in .Net for a novice, that eventually winds up most likely on this site?

    Along the "you don't have expereince" lines ...  I interviewed in NC for a Programmer position in which the IT department was the IT manager and a Senior programmer. They flew me down, had lunch with the IT manager, and then began interviews with various people. Sizing up the senior programmer, he had lots of old school programming expereince in probably C, C++, RPG COBOL, FORTRAN, AS/400 etc...  I looked at his desk and it was literally PILED up with .NET, VB, PHP etc .. books. So, while he is interviewing me, he is physically trembling. He had been asking me questions like "What IDE's do you use for your Java development?", "Do you have any .Net expereince?"  "To which I replied something like "I use vi for most things, IDE's tend to write bad code for you and you end up writing most of it by hand anyways" and "I have VS 6.0 experience but never liked re-writing my code over again when Microsoft changed things in the OS or VB itself or the DLL's and the customer wanted to upgrade"  I later went into my expereince with Unix, more on Java, PHP, scrtiping etc..  I later recieved the inevitable "We just don't think you would be comfortable working in a windows environment"  How could I not be? If I can do things on the command line, isn't that 10x (at least) than if I don't understand why the IDE was writing the code that way because "Well it does it for me so why do I need to understand what it's doing?" I heard from my friend that set me up with the interview that they hired a.Net "Bob", maybe related to the Java Wizard ...

     I actually look back and am glad I did not get these jobs.



  • [quote user="Bob Janova"]I wish 'Bob' wasn't the name of choice for bumbling average people!
    [/quote]

    Well, you always have 'Janova.' 



  • Tomorrow is actually our foremost .NET Bob's last day. He'll be going to a good "Bob job" where he can do .NET for the next few years. I really hope that they involve the other developers here in the interview process for his replacement, because I'd love a person that is flexible and well-versed in programming as opposed to someone who just has the right buzzwords on their resume. We've had two incompetent coders come and go in a year (where our average development team size is 4) that could have been avoided entirely by having developers on the interview.



  • What every programmer needs is a good solid understanding of why he sucks.

    The fact is, we all suck. The industry moves, and it moves fast. Tomorrow, your skills will be worth less than they are worth today. If you're not deliberately improving them every single day, you are falling behind. But where most developers screw up is in improving the things that they are already good at doing: a Java developer will go and learn some new Java-based framework, for example, instead of learning PHP or C#. That's where things are comfortable. But in the end, it's by going out and learning the new stuff - Ruby on Rails, perhaps - that will keep your skills relevant.

    Which is why I'm taking my project management certification exam tomorrow. I'm beyond the whole "learn technology X" aspect of software development; my career doesn't depend on whether I know the language or the architecture anymore. If you want XML web services in COBOL on an AS/400, I can do that, even though I've never heard of such a thing. I know XML. I know COBOL. I know AS/400. I can connect the dots. With well over a dozen architectures, thirty languages, and several hundred technologies under my belt... look, I don't care how new it is, it's going to be similar to SOMETHING that I already know.

    Where I suck is in my ability to manage projects in a large corporate setting. I can do it just fine when nobody questions me because I own the company, but if I'm going to build anything of note, I need to interface with other projects and their managers - so we at least need to speak the same language.

    And there's the other problem with the programmer-proficiency curve: it's not a curve. It's a field. You have how much you know *and* how many things you know. That same breadth of knowledge and experience I have isn't always an asset; sometimes you need someone with massive technical knowledge about one very specific thing. I don't have that. When Java programmers want to argue about GC algorithms, I don't really care. My understanding of GC is only as deep as this: "if the language is garbage collected, I don't have to worry about releasing memory". I have a vague awareness that sometimes your GC blows and you should jump through a couple hoops to make the GC work better, but I really don't care about the specifics. I just want to know where I can find an expert who can point out the hoops. But if your project happens to be a new garbage-collected language, you'd better find someone who's an expert on garbage collection, and that will almost certainly not be me.

    Eh, I don't really have a point here. I'm just rambling to hear myself talk. Er... watch myself type, rather.



  • [quote user="CDarklock"]My understanding of GC is only as deep as this: "if the language is garbage collected, I don't have to worry about releasing memory". I have a vague awareness that sometimes your GC blows and you should jump through a couple hoops to make the GC work better, but I really don't care about the specifics. I just want to know where I can find an expert who can point out the hoops. But if your project happens to be a new garbage-collected language, you'd better find someone who's an expert on garbage collection, and that will almost certainly not be me.[/quote]But the fact that, say, Java and C# are garbage-collected and C++ is not has direct bearing on writing correct code when you're dealing with resources and when to close them.  In C++, you must ensure that the destructor properly releases your resources, and that you properly scope all your object instances, otherwise you'll get leaks.  In Java, there are no destructors and you don't necessarily need to explicitly scope objects, but you can't assume that everything will get collected in a timely manner or you'll get short-term resource leaks.  So you don't need to know the details of the GC itself, but the implications of what the GC does have important implications on the code that runs under it.

    I find it's the ones who know just enough about something to be dangerous that are often the source of some of the more frustrating bugs.  Off-by-one errors are common enough with junior developers, but it's the more-seasoned ones that are less experienced in a given environment that cause deeper errors.  The following were done by supposedly-seasoned developers:

     * Code in Java that used JDBC objects without explicitly closing connections, statements, or result sets.  This bears directly on the "short-term leak" thing above, as these automatically get closed when they're finalized by the GC.  However, if you don't close them when you're done with them, those resources on the database server continue to be allocated until you happen to run out of memory in the **JVM**, rather than running out of cursors in Oracle.

    * Code in C++ that stored references to stack-scoped objects.  Most of the time, these would get consumed before the stack-based objects got trashed, but once in a while not.  This would result in low-frequency, unpredictable, hard-to-reproduce errors.

    * Code in C++ that had template parameters on a base class for the sole purpose of adding unnecessary parameters on some of its methods.  Some of this was to emulate covariant overrides, but other times it was to avoid extrapolating a base class for other method parameter types.  All this really did was increase the code size dramatically, as all of the methods in the base class needed to be instantiated again for each derived class.  This isn't arguably a bug, but it produced bloated code that was harder to maintain and sucked up page memory like a sponge.

    Yes, one can program with a broad understanding, but I think one needs deeper subject knowledge more frequently than your comment suggests.  It doesn't necessarily need to reside in each developer, but you should then have an expert doing code reviews to make sure esoteric language-specific details don't bite.


Log in to reply