Chad Perrin: SOB

15 September 2010

How bad a programmer am I?

Filed under: Cognition,Geek,Profession — apotheon @ 04:43

I’ve come to realize something today:

I think of myself as a worse programmer than I actually am.

I don’t get as much code written as I would like. I run into a wall a lot of the time when trying to get something done, and it feels a little like I’m running up against the edge of my own competence. I know I’m no expert, nor even “proficient” in the Dreyfus model, but I might be better than I tend to think when I have those moments of incompetence.

I’ve realized that one of the biggest problems I have with making progress on my own projects is figuring out how I want to build them — to some extent, even figuring out what I want them to do. Once I have a clear idea of some piece of functionality that needs to be built, I tend to build it; once I know how I want to organize the architecture, I put it together; once I have a theory for the project’s concept, I design it. Reverse those steps, and you’ve got a path from concept to completion.

The biggest problem for me is, apparently, developing that theory for the project’s concept. When working on a fairly clear-cut project, such as when doing something for a client who has more than a vague notion of what (s)he wants, everything flows easily, but a lot of the time the vague notion is mine, and it’s up to me to come up with something clear-cut from there.

I’ve never been a cubicle-based developer. My information technology related dayjob employment has always been focused on things like network administration, data center support, and on-site client system recovery. I have not had a straight-up development job, per se, though I have done a fair bit of lightweight development for clients (Web development, software tool maintenance, integration, and actual — le gasp! — consulting). It occurs to me that if I had at some point had a desk-and-beige-box, cubicle-embedded, corporate development job I’d probably have a more positive view of my own programming skills.

In a cube farm, doing development scut-work, expanding the code base of some Enterprisey bloatware system by working on some micromanaged little segment of it, I would have realized much sooner that I do seem to have the ability to churn out code to meet the well-defined goals set before me — and do a better job of it if I understand how it fits into the big picture. In short, while I’ve spent a long time rating myself somewhere around the level of a low-level Advanced Beginner in the Dreyfus model, I think I might actually land squarely in the Competent category. It’s just difficult to see that from where I’m marooned on the far fringes of development, well outside the kind of programming work most developers do.

Maybe tomorrow I’ll change my mind, but for now it looks like I’ve suffered under a delusion that is the diametrical opposite of the Dunning-Kruger effect.

I’ve been thinking about the Dreyfus model of skill acquisition a lot lately (I blame Andy Hunt, and his book Pragmatic Thinking & Learning). It is in part because of this fact that I’ve come to realize that my own cognitive bias in the case of rating my development skills lands me squarely in the self-underestimating camp.

Now I just need to spend a few more days thinking about it to make sure my epiphany is not just a flash of ignorance, rather than insight. If it turns out this realization is not, itself, a misperception, I then need to start working on believing it. Long habit of belief in my own relative incompetence will be difficult to break.


  1. My giant “programming god” ego is incredulous that you didn’t like the word “expert” to me. In all seriousness, though… I know exactly what you mean. For me, a lot of the self-doubt is because I never formally learned “university CS”. People start discussing nuances of things like OO theory or whatever and I feel left out. But then I remind myself, I know 100% of what I have ever needed to get the job done, as evidenced by the fact that 100% of the jobs I’ve done are complete. I know what I need to know. And most of the stuff that I am shaky about, I look at it and realize that most of it is mindless hair splitting anyways… the kind of stuff that may be aided by your erroneous Amazon recommendation. And then I don’t feel so bad about know it. Fact is, you are probably a better programmer than most 40 h/w folks, because you’ve got:

    • Breadth of experience in languages, giving you perspective
    • A concept of systems engineering, allowing you to see how the parts fit together
    • An understanding of the OS’s, networks, protocols, etc. at a deep, low level, allowing you to more easily understand why things work the way they do

    A few days ago, I was in a discussion with a C# nerd I know, real smart guy and such. But he’s only really worked with C#. I get the impression he used Delphi for a minute years ago. My brief flirtations with languages like C allow me to understand ideas in C# intuitively that he is surprised by (like why a boolean value takes 1 byte, not 1 bit). I’m sure that if you talk to enough corporate developers, you’ll see the same thing in your own knowledge set.


    Comment by Justin James — 15 September 2010 @ 05:15

  2. You and Sterling are great for my ego when it comes to software development. I know that, in terms of ability to sit down and make a project happen, I don’t have the kind of experience and practiced skill of either of you, but the fact you both have positive regard for my abilities makes me feel warm and fuzzy inside.

    There are definitely times that Sterling’s impostor syndrome article is quite relevant to my professional life. It doesn’t help that I think many people believe me more professionally successful than I actually am, regardless of skill level. I’ve had a lot of ups and downs.

    Anyway . . . I’m constantly working on polishing that crystal ball I use to try to get a clear view of my life. Today was, I think, a particularly productive day in that lifelong endeavor.

    Comment by apotheon — 15 September 2010 @ 09:56

  3. +1 for what Justin said. You’ve got a better grasp of some programming concepts than many self-proclaimed experts in the field. You’ve made me think in ways that were new to me, which made me a better developer. Although it’s true that I can learn from anyone, your track record of enlightening me suggests that “Advanced Beginner” is an unlikely categorization.

    Regarding the “theory of the project’s concept” — don’t put too much stock in it. Oftentimes, you just need to get going and let the concept develop out of the work. That’s not to say that you don’t do design — you do, but in chunks. Trying to get the whole picture up front is what waterfall is all about, and why it often falls on its face.

    Comment by Sterling Camden — 16 September 2010 @ 10:02

  4. Thanks for the linkage, BTW.

    Comment by Sterling Camden — 16 September 2010 @ 10:05

  5. You’re welcome for the linkage, of course. I really should have included it in the original SOB entry, but I’m feeling far too lazy to edit that right now.

    As for the theory of the concept . . .

    Part of the problem is that, for my own projects, I have a hard time progressing without such a theory. Often, if I do make progress without it, I then have to rewrite half of it later when I figure out what it is I’m “really” doing.

    With simple enough projects, of course, that’s not an issue. I’ve never had problems with stuff like “I need a tool that minimizes file size, doesn’t have to keep readable content, and still gives the same output with wc,” though. I crank that stuff out in minutes, theory or no theory. It’s when I’m doing something like writing a generalized toolset for dealing with a specialized flat-file database format that I find myself struggling to even know what I’m writing. That is, by the way, something I’ve been working on — off and on — for more than a year. For all that, I’ve got only about 100 lines of code, and less than half the functionality it’ll need to be a minimally complete toolset. I just feel like I’m at a loss for what needs to be accomplished a lot of the time.

    Yesterday, though, was something of a breakthrough, and I’m pretty sure that I’ll be able to make some progress in days to come. I guess, in code as in English, I’m very much an inspiration-driven writer.

    edit: Oh, wait — you might have been talking about the link I did include in the original SOB entry, and not the link from comments. Ahem. Yes, you’re welcome.

    Comment by apotheon — 16 September 2010 @ 11:07

  6. Something that has helped me a lot is using better/different/whatever tools. For Web development, switching to the Agile Platform (I’m sure you’d hate it) was a game changer because it let me focus precisely on what applications did and ignore, for the most part, technical implementation details. It was like being a BA instead of a programmer, and for Web dev projects where the technical implementation details are full of frustrating nitpicks that follow well established patterns, it works great.

    Personally, I haven’t felt truly expressive in a language since I was a daily Perl coder. That was the last time I felt like ideas could form in my mind and easily appear in code format with minimum interruption to focus on petty details. I suspect I would be the same way with Ruby, but I haven’t had the excuse to use it yet. I believe that the problem is OOP. I grew up with procedural code, quite literally. Learning how to write procedural code shaped the way I think, because it happened at a very critical time in my mental development. It’s not that I dislike OOP or don’t understand it; I am emotionally neutral to it, and I understand it just fine. But I find that being forced to think OOP-sy is this giant block. It’s like being a writing bursting with ideas, but you’ve got an injured finger and if you don’t type slowly it hurts you. That’s exactly what OOP is to me, an injured finger that hurts me badly if I don’t slow down. Even if you aren’t trying to create a Taj Mahal of objects, you still need to be painfully aware of the OOP-sy nature of a language like Java or C# for even the most trivial task.

    In terms of my personal projects, I am in a great place. With the Agile Platform, I can handle the front end stuff (at least on Web apps) really well, and do the backend, algorithmic stuff in C# if I feel like. Alternatively, I can implement it as a Web service and write it in another language, I suppose. If Ruby’s parallel processing story was a little stronger, I would love to try re-implementing the Rat Catcher backend code (currently in C#) in Ruby; that would put me in an awesome scenario, because it would make the pricing on Amazon Web Services so much cheaper it isn’t funny, and I’d put the backend code on AWS in an instant then.


    Comment by Justin James — 16 September 2010 @ 09:21

  7. That’s the beauty of Ruby — you don’t have to think OOP unless it matches what you’re trying to do. You can code procedurally, or functionally, or mix them all up. I usually avoid classes in Ruby unless they’re useful. What are they, anyway, except a way to bundle state for a group of functions?

    Comment by Sterling Camden — 17 September 2010 @ 08:09

  8. “What are they, anyway, except a way to bundle state for a group of functions?”

    In the Land of the Verbs, yes. In the Kingdom of the Nouns, they are the be all and end all and demand blood sacrifices.


    Comment by Justin James — 17 September 2010 @ 08:14

  9. Precisely why C#/Java/etc are harder to code elegantly than Ruby (or Perl, FTM).

    Comment by Sterling Camden — 17 September 2010 @ 09:27

  10. Perl and Ruby do have that in common — the largely effortless multi-paradigm flexibility of which Sterling speaks. I say “largely” because, of course, I have to make allowances for certain FP shortcomings in both (few and far between; fewer and farther between for Perl than for Ruby) and certain OOP shortcomings in Perl (obtuse syntactic form and uninspired semantics, at least for Perl 5.x).

    Doing OOP in Perl feels a bit like that injured finger analogy for me, too, though not so much with Ruby. It feels much more natural there, once one simply wraps one’s head around the idea that it all boils down to building little robots to help you do your work, and letting them do what you’ve built them to do. You don’t call a function; you tell one of your automatons “Hey, do this for me.”

    As for Agile Platform . . . I tend to find that slick, commercial frameworks usually just get in my way. It probably has something to do with the way I generally think naturally in terms of the Unix philosophy, for the most part, and those big frameworks are generally oriented toward a more Enterprisey way of building software.

    Comment by apotheon — 17 September 2010 @ 03:56

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License