Programmer Insecurity

This entry was posted by on Thursday, 12 June, 2008 at

I’ve got a lot to say today!

I want to chat about something that I’ve never noticed before, but probably should have. There’s always been a stereotype out there of programmers being nerdy, anti-social people (Q: How do you know when an engineer is outgoing? A: He looks at your shoes!). But my revelation of the week is that most programmers seem to be really insecure about their work. I mean: really, really insecure.

My buddy Fitz and I have long preached about best practices in open source software development — how one should be open and transparent with one’s work, accept code reviews, give constructive criticism, and generally communicate as actively as possible with peers. One of the main community “anti-patterns” we’ve talked about is people writing “code bombs”. That is, what do you do when somebody shows up to an open source project with a gigantic new feature that took months to write? Who has the time to review thousands of lines of code? What if there was a bad design decision made early in the process — does it even make sense to point it out? Dropping code-bombs on communities is rarely good for the project: the team is either forced to reject it outright, or accept it and deal with a giant opaque blob that is hard to understand, change, or maintain. It moves the project decidedly in one direction without much discussion or consensus.

And yet over and over, I’m gathering stories that point to the fact that programmers do not want to write code out in the open. Programmers don’t want their peers to see mistakes or failures. They want to work privately, in a cave, then spring “perfect” code on their community, as if no mistakes had ever been made. I don’t think it’s hubris so much as fear of embarrassment. Rather than think of programming as an inherently social activity, most coders seem to treat it as an arena for personal heroics, and will do anything to protect that myth. They’re fine with sharing code, as long as they present themselves as infallible, it seems. Maybe it’s just human nature.

Check out some of these stories I’ve collected:

  • Requests at the Google I/O booth: A couple of weeks ago when my team was at the Google I/O conference, we ran a booth demonstrating our Open Source Project Hosting service. Over and over, we kept getting requests like this:

    “Can you guys please give subversion on Google Code the ability to hide specific branches?”

    “Can you guys make it possible to create open source projects that start out hidden to the world, then get ‘revealed’ when they’re ready?”

    Translation: “I don’t want people to see my work-in-progress until it’s perfect.”

  • Requests on the Google Code mailing list: Sometimes users need their svn repositories wiped clean. Legitimate reasons include the accidental commit of sensitive data, or the need to load code history in from a different svn repository. But most of the time we get (invalid) requests like this:

    “Hi, I want to rewrite all my code from scratch, can you please wipe all the history?”

    Translation: “I don’t want people to be able to find my old code, it’s too embarrassing.” Call it vanity, call it insecurity… the bottom line is that coders want prior mistakes or failures to be erased from history.

  • Code-reviews taken as personal attacks. Fitz tells a funny anecdote about a friend of his who went from the open source world to a corporate software job. Vastly paraphrased:

    During his first week, he started emailing friendly code reviews to each of his coworkers, receiving strange stares in turn. Eventually his boss called him into his office:

    “You know, you really need to stop with the negative energy. Your peers say that you’re constantly criticizing everything they do.”

    Moral: not only is code review not the norm in corporate environments, most programmers are unable to separate their fragile egos from the code they write. Repeat after me: you are not your code!

  • Distributed version control — in a cave. A friend of mine works on several projects that use git or mercurial. He gave me this story recently. Basically, he was working with two groups on a project. One group published changes frequently…

    “…and as a result, I was able to review consistently throughout the semester, offering design tweaks and code reviews regularly. And as a result of that, [their work] is now in the mainline, and mostly functional. The other group [...] I haven’t heard a peep out of for 5 months. Despite many emails and IRC conversations inviting them to discuss their design and publish changes regularly, there is not a single line of code anywhere that I can see it. [...] Last weekend, one of them walked up to me with a bug [...] and I finally got to see the code to help them debug. I failed, because there are about 5000 lines of crappy code, and just reading through a single file I pointed out two or three major design flaws and a dozen wonky implementation issues. I had admonished them many times during these 5 months to publish their changes, so that we (the others) could take a look and offer feedback… but each time met with stony silence. I don’t know if they were afraid to publish it, or just don’t care. But either way, given the code I’ve seen, the net result is 5 wasted months.”

    Before you scream; yes yes, I know that the potential for cave-hiding and writing code bombs is also possible with a centralized version control system like Subversion. But my friend has an interesting point:

    “I think this failure is at least partially due to the fact that [DVCS] makes it so damn easy to wall yourself into a cave. Had we been using svn, I think the barrier to caving would have been too high, and I’d have seen the code.”

    In other words, yes, this was fundamentally a social problem. A team was embarrassed to share code. But because they were using distributed version control, it gave them a sense of false security. “See, we’re committing changes to our repository every day… making progress!” If they had been using Subversion, it’s much less likely they would have sat on a 5000 line patch in their working copy for 5 months; they would have had to share the work much earlier. Moral: even though one shouldn’t depend on technical solutions to social problems, default tool behaviors matter a lot. This was my main theme way back when I wrote about the risks of distributed version control.

OK, so what’s the conclusion here? People are scared of sharing their unfinished work, plain and simple. I know this isn’t headline news to most people, but I really think I’ve been in deep denial about this. I’m so used to throwing my creative output up for constant criticism, that I simply expect everyone else to do it as well. I think of it as the norm, and I can’t comprehend why someone wouldn’t want to do that… and yet clearly, the growing popularity of distributed version control shows just how thrilled people are to hide their work from each other. It’s the classic “testimonial” for systems like git (taken from a blog comment):

“Don’t tell me I should cooperate with other people at the beginning and publish my modification as early as possible. I do cooperate with other people but I do want to do some work alone sometimes.”

Hm, okay. Please just don’t work alone for too long!

Sidetracking a wee bit, I think this is why I prefer Mercurial over Git, having done a bit of research and reading on both systems. Git leans much more heavily towards cave-hiding, and I don’t like that. For example, the ‘git rebase’ command is a way of effectively destroying an entire line of history: very powerful, sure, but it’s also a way of erasing your tracks. Rather than being forced to merge your branch into a parent line, just pretend that your branch was always based on the latest parent line! Another example: when it comes to pushing and pulling changesets, Mercurial’s default behavior is to exchange all history with the remote repository, while git’s default behavior is to only push or pull a single branch — presumably one that the user has deemed fit for sharing with the public. In other words, git defaults to all work being private cave-work, and is happy to destroy history. Mercurial shares everything by default, and cannot erase history.

I know this post has been long, but let me stand on my soapbox for a moment.

Be transparent. Share your work constantly. Solicit feedback. Appreciate critiques. Let other people point out your mistakes. You are not your code. Do not be afraid of day-to-day failures — learn from them. (As they say at Google, “don’t run from failure — fail often, fail quickly, and learn.”) Cherish your history, both the successes and mistakes. All of these behaviors are the way to get better at programming. If you don’t follow them, you’re cheating your own personal development.

Phew, I feel better now.

(This page has been translated into Spanish language by Maria Ramos.)

99 Comments to Programmer Insecurity

  1. Bryan O'Sullivan says:

    June 12th, 2008 at 10:48 pm

    Nice article! If I had a penny for every time I’ve seen one of those sins committed, I could melt them and make a nice, heavy, copper clue mallet.

  2. Sam says:

    June 12th, 2008 at 11:00 pm

    So true! This could have been written about academia — no one wants to show work in progress, in part because people are often downright mean about it. Or maybe that’s just our institution…. :-) Seriously, advice early on is more useful and far less painful, because there is less at stake.

  3. Eric Hanchrow says:

    June 12th, 2008 at 11:09 pm

    OK, I’m guilty. I’ve been using git recently, and did pretty much what you are describing. (Actually, I pushed all my git commits into a subversion repository, and wished I had “squashed” them all into one commit instead … not so much out of shame for their contents, but also to reduce the noise in the commit logs.)

    But in general, I gotta say, it’s embarrassing letting the world see my pathetic fumblings! Particularly when they’re preserved for all eternity in the repository. It’s sort of like stage fright.

  4. Voyagerfan5761 says:

    June 12th, 2008 at 11:10 pm

    @Bryan: Clue mallet? Nice. :D

    This has reinforced my desire to begin using a version-control system for one of the projects I’m working on, which is a website (plain and simple). I’d try Google Code, but the site’s not exactly open-source. Maybe I’ll talk to the other tech people and see if our server admin can get a DVCS running for us to use. It would make it easier to collaborate with the other team member who’s supposedly helping me (but since it’s hard for both of us to work on the code he hasn’t done much).

  5. Mere Code » Blog Archive » Aren’t code reviews great? says:

    June 12th, 2008 at 11:37 pm

    [...] Sussman-Collins writes about programmer insecurity and how a lot of programmers dread having others see their [...]

  6. Leo Katzenstein says:

    June 12th, 2008 at 11:54 pm

    The behavior you describe is very similar to how math papers are produced. The author tries lots of stuff in private, exploring all sorts of dead ends, but in the published paper absolutely no hint of any of the exploration is given. The paper is written as though the solution was obvious to the author and should be obvious to any intelligent reader. The fact that the author spent quite a bit of time finding the path or the transformations that make allow the proofs is almost taboo. And for mathematics research, I do not think this a serious problem.

    But code is not math, and early exposure and feedback are important.

  7. Jason Robbins says:

    June 13th, 2008 at 12:00 am

    Inspired by Ben’s piece, here is my note to all those people who have said something like “I have an idea for a new PHP content management system, but I would want to keep the project private for a while until it is good enough”:

    You *should* be embarrassed about your code… if you don’t start with a clear vision and work through some requirements and design first. Even before forming your project vision, take some time to look around: is your thing really going to end up surpassing what is out there already?

    If you have an itch to scratch, scratch it with a good bug report or even a patch, not a whim project.


  8. Bertie Ahern says:

    June 13th, 2008 at 12:13 am

    Computers aren’t very forgiving. When you work with something that tells you “you’re wrong” all day, you’re bound to get a bit touchy. It’s not like being a manager where everyone tells you you’re great even when you screw up.

  9. Name says:

    June 13th, 2008 at 12:15 am

    I disagree that Mercurial enforces sharing of modifications any more than git does. In your example, it would be just as easy for the hg user to create a fresh branch from trunk, diff -u | patch -p0, and push their newly sanitized branch. I’ve never used git, but from what I understand, this is effectively what rebase does.

    I also disagree, strongly, that DVCS makes code hiding any more difficult than single-branch VCS. When using a single branch, it’s usually a very small group of people who are allowed to commit. Any patches from non-core contributors get lost in a tangle of IRC pastebins, mailing lists, bug trackers, and blog posts. Furthermore, even if these patches are eventually committed, they have lost all their associated version information — the destructive rebase you complain about. DVCS allows anybody to branch from trunk, record their changes, and publish their branch in a service like Launchpad or github. For an example of this, look at the mass of user-created branches for popular projects like GNOME Do[1] or AWN[2].


  10. C. Michael Pilato says:

    June 13th, 2008 at 12:19 am

    Great post, Ben!

    I was at a conference last year which concluded with a panel discussion. I can’t recall the details, but I remember that at some point the conversation turned to an audience member’s apparent need for offline commits. A panelist asked why he didn’t just use a public branch. The audience member was visibly disturbed by this suggestion, indicating that publicizing imperfect code would be a really bad thing. The implication was that he feared his employer’s evaluation of his skill set based on commits that weren’t perfect every time.

    And I confess, I’ve had to deal with the same insecurities at times, too. After all, it wasn’t for no reason that I didn’t make the source code for ThotKeeper public for such a long time. The lie I told myself was, “Who cares if it’s public? Nobody but me is interested in this little toy project anyway.” Fortunately, I was proven completely wrong. Since the project has been publicized on Google Code Project Hosting, it’s attracted a fantastic volunteer who’s already finished most of my TODO list! Does he care that my coding isn’t perfect, and my use of the wxPython library not ideal? Of course not.

  11. Ted Lemon says:

    June 13th, 2008 at 12:22 am

    Too true. Two observations, though. First, sometimes it’s hard to get anyone to look at your code and criticize it. And second, it’s not paranoia if someone’s really out to get you. Sometimes we fear sharing our code because we have the expectation that our fellow geeks will criticize not wisely but too well.

    I’ve gone both ways, and I think your philosophy is the right one to choose, but I’ve also been driven out of open source projects because of excessive and unhelpful criticism. I think that I was better off withdrawing, so being open was still the right thing.

  12. Sara says:

    June 13th, 2008 at 12:37 am

    This is really true actually. I know I get SERIOUSLY insecure about people looking before something is done. Like they are going to seriously judge me and think I’m an idiot. The thing I always catch myself at is getting mad at people that test my code when it breaks, don’t ask me the logic behind it.

  13. Webiest : iBanjo » Blog Archive » Programmer Insecurit says:

    June 13th, 2008 at 12:42 am

    [...] [...]

  14. robertlipe says:

    June 13th, 2008 at 12:51 am

    Well said.

    I’d *much* rather a fellow developer point out that I (or one of my peers) screwed up in the source tree and have a chance to fix it before it goes “official” than the other way.

    I have low self-esteeem and no fear of public failure. Bring on the criticism!

    Signed, a few hundred feet away from you at Dev i/O and yet your brother in solidarity.


  15. Douglas Squirrel says:

    June 13th, 2008 at 1:44 am

    If you’re working with programmers who are shy about their code, a great way to get them sharing is a code dojo. See and Five or ten minutes of live coding on a toy project is not so scary and it loosens them up to share more.

  16. Ralf Schneider says:

    June 13th, 2008 at 2:05 am

    The attitude to not show unfinished code is understandable and IMHO a good thing.

    Think about an author writing a book. A painter painting a picture, etc. Most times these people don’t like to share their unfinished work… The same seems to be true for developers.

    Personally I’m not interested in code which has not at least reached a specific quality level. During initial development code is often redesigned, rewritten etc. I don’t want to criticize someone who is in the middle of a thought process which is reflected in the source code.
    I even think the best architectures, designs, libraries, … are done by a single person, may be two or three people. Too many people arguing over the architecture leads to the “designed by committee” problem.
    Later “the community” can to jump in to the project and continue the work, but at this point the project has already set a solid base.

    Of course there is a high chance a isolated group may produce crap that sucks. This can always happen. It will be ignored by “the community” anyway. It’s evolution – the best projects/ideas will in the long run survive.

    Another point is: YOU and I is not the (OSS-)COMMUNITY!!! We are individuals. Sometimes “with ego like a small planet (Linus on himself)”. Not everything has to be shared and discussed to death. Everybody has its secrets and (hopefully) its own agenda. Probably all innovations have been achieved by individuals and not by a community. Sometimes you have to protect yourself from outer opinions and think on your own. …Later your idea/product/whatever can be discussed, criticized and compared.
    If you present your idea to early there is a very high chance to lose your focus and get distracted by too many opinions until you finally loose all your motivation.

    - Ralf

  17. Jose Hevia says:

    June 13th, 2008 at 2:54 am

    You are making oversimplifications here:

    I am geek, and yes I don’t show my code until is finished.

    Why? Because I had shown it a lot of times, I loved to make aircraft, ship and landscapes modelling in light weight materials with my hands. I used to tell my friends when 95% of the work was done. It was BAD, people said WHAT IS THAT SHIT!! I continued my work and a day later I had my model finished: OHHH, MAN THAT’S FANTASTIC!!! HOW DID YOU DID THAT. I showed you, and you said it was SHIT. THAT WAS THIS??? Impossible. You are the man…

    If I had listen to them, I would never had made anything of value. And they were my friends, they loved me.

    Sorry but when I program I only listen those who I respect because are better than me. In my experience when I showed them my ongoing code they don’t criticize, and they used to be busy making things happen, not correcting another one program methods.

    It is not insecurity, it is the simple fact that you are not good enough for them to respect you and that people don’t like to be micromanaged like an SLAVE (the micromanager adopts a superior level over them that they obviously don’t like).

    If you want to be respected in the OSS world you have to had done something of value, if google founders advise a geek of something, geek will listen, if someone of the same OSS group tell the same thing, he will care less.

  18. Thomas Kjeldahl Nilsson says:

    June 13th, 2008 at 4:02 am

    Great post. I see this character trait in myself and my coworkers regularly. :)

  19. John says:

    June 13th, 2008 at 4:14 am

    Who isn’t for transparency?

    Programming culture is about The Right Way (TM). They quiz you in job interviews. Not knowing how to do something correctly is heresy.

  20. retsoced says:

    June 13th, 2008 at 4:57 am

    With open-source, in some case the fear can be justified. Too often I have seen people get lynched for (perceived or otherwise) writing poorly thought out, linear code.

    In the corporate world, it’s a simple lack of time and resources for doing the job right. In-house teams can be very small, and time is generally far too short, with no written requirements. So the focus is on getting the app out the door, rather than using an open development paradigm.

    This isn’t limited to programmers either, designers get into the same funk. No one wants to hear that folks don’t like what you are doing, or that you are doing it in an inefficient/incorrect manor – it’s taken me a long time to divorce myself from my designs and code, but it still stings a bit when I work hard on something and it gets picked apart. But, in the end the majority of the time the work is better for it…..

    Good post.

  21. Jeroen Ruigrok van der Werven says:

    June 13th, 2008 at 5:06 am

    Hi Ben!

    Hope my fellow polyglot’s doing fine. :) (For your reference: asmodai.)

    It is funny that you mention this distinction in Git and Mercurial, it is actually something I pointed out to my colleague yesterday in that I found Hg to emphasize pushing back patches/code more than git.

    And I agree with your assessment that people should not be afraid of committing their stuff. For my own local projects I commit everything to SVN. In a sense I use the repository as both a backup mechanism as well as a normal repository. By committing my parts to the repository it also forces me to start committing semi-working prototypes and build it out to a working version and take it from there.

  22. Paul Moore says:

    June 13th, 2008 at 5:08 am

    Hmm, interesting article (as was the “risks of DVCS” posting). In principle, I agree, but there’s one aspect of coding “in private” that I think you missed – which is the difference in granularity of commits that are appropriate.

    For example, when coding locally I like to commit very frequently, often simply because I want a break. Commits here are very much my personal savepoints, and log messages can often reflect this (commit -m “Stopping to watch Stargate”…) In particular, I don’t expect commits to pass the test suite every time, or even to compile. Log messages like “fix some more typos, doh” are common.

    On the other hand, many projects expect commits to (generally) pass the test suite – at least on the mainline. So pushing a big batch of commits like the above is inappropriate.

    Now I’d be the first to admit that I’ve no wish to show off my lousy typing (or my viewing preferences!) to the world, but equally I don’t know that *that* level of detail is necessary in a public repository. The problem (which as you say, is social) is deciding what *is* the right level of detail. And then, coming up with a tool or process to allow for both levels (personal and project).

    That’s an area where DVCS tools should be looking to address, IMHO. They are great at capturing the “personal” workflow, and fine for publishing that detail. But maybe some sort of command to “roll up” a series of changes into a single group would help. Something to manage the transition from purely personal to public.

    Or maybe I’m still in denial, and the world does need to know how bad my typing is :-)

    Thanks for a thought-provoking article.

  23. Thomas Guest says:

    June 13th, 2008 at 5:09 am

    Yet another interesting read, thanks.

    Is it fair to suggest distributed version control encourages cave-dwelling? The “everything-is-a-branch” model should make it easier for sub-teams to collaborate and experiment. You can share what you want with who you want, and lose nothing if and when you merge back to the trunk. My impression is that dvcs users are at least as comfortable with exposing their work as svn users (but I defer to your experience here).

    As you say, it’s more of a social problem. I think there’s also an important technical aspect, and that’s to do with how you architect, develop and maintain software. An incremental development model helps defuse the “code bombs” you mention.

    I think we also need an environment where small improvements are welcomed: if you see a typo, fix it — don’t just wait to roll it in with more substantial changes.

    One thing I’ve come across is

  24. Ovid says:

    June 13th, 2008 at 5:13 am

    While I generally agree with this, I can understand why people want code to not be revealed until it’s “ready”. I’ve already had problems with releasing alpha code and having others get mad when the interface changes (sometimes radically). By taking the time to quietly work on it until I know at least that the interface is relatively stable, I can free myself up from a lot of concerns about breaking things at will.

  25. Jim K says:

    June 13th, 2008 at 5:26 am

    I think this is a very useful article – clearing recognising issues that most developers are aware of, but perhaps choose to ignore.

    Personally, I believe that I started to overcome my fear of others seeing my code-in-progress when I first engaged in ‘pair programming’ on a regular basis.

    Perhaps this is because we were constantly seeing each other’s design decisions – I certainly found myself learning new design ideas from other developers, and I got feedback that many of my ideas have some value.

    Perhaps pair-programming is a microcosm teaching tool for the macrocosm of sharing code in an open source project?

  26. Jack says:

    June 13th, 2008 at 6:33 am

    Isn’t one of the problems with software engineering is that there is no standard practice everybody can subscribe to. So, the person wielding the “clue mallet” against you may just happen to have a difference of opinion with you over exactly which practice is best.

    A lot of programmers can be extremely personal in their attacks when performing code reviews…so, whilst you and I may be capable of separating an engineer from their code others quite often are not.

  27. » Blog Archive » Programmer Insecurity and Mea Culpa. says:

    June 13th, 2008 at 6:33 am

    [...] Sussman-Collins put up an excellent blog post on programmer insecurity – this rings particularly loud with me for a few [...]

  28. Dave’s Tech Blog » Blog Archive » “Be transparent. Share your work constantly. Solicit feedback. Appreciate critiques.” says:

    June 13th, 2008 at 7:17 am

    [...] transparent. Share your work constantly. Solicit feedback. Appreciate critiques.” Published in:Uncategorized |on June 13th, 2008 |You can leave a response, or trackback from your [...]

  29. Mayson Lancaster says:

    June 13th, 2008 at 7:18 am

    If you’re not making mistakes, you’re not writing enough code. The value of collaborative work methods (pair programming, code reviews, etc) is so high – in terms of code quality, design quality, and morale that I find it hard to see why people don’t routinely use them.

  30. Bjartr says:

    June 13th, 2008 at 7:44 am


    Pennies are only copper coated nowadays…

  31. Giulio Petrucci says:

    June 13th, 2008 at 8:10 am

    Hi there!
    Great post!
    In my experience, I’ve learned to criticize other’s developer (mostly collegues) code without critizing *them*. For instance, saying “this piece of code should have been like that…” instead of “*you* should have done like that…”. Maybe it’s quite a silly thing… but I think it could be important, expecially when leading a team of young (and not-so-skilled) developer.

  32. Barry Sekulow says:

    June 13th, 2008 at 8:12 am

    The devious and the borderline personalities seem to manage to become the chief programmers and architects and project managers, this is the nature of the office world. Honest little mice stay little mice, for the most part.

  33. Allen Short says:

    June 13th, 2008 at 8:55 am

    Improvements to an existing project definitely benefit from being developed in the open, especially since good integration of code requires good integration of developers.

    However, I still think that it can make sense for unfinished new projects to be only released when they’re at some minimal level of functionality, because one only gets one chance to make a good first impression. Some projects don’t have any value to the community until they reach a certain level of maturity. But more than that, the author might change his mind about the direction of the project — one’s initial vision can be subject to a lot of modification once one is halfway into the project and reality sets in.

    As my friend Glyph has put it: Much like in the world of Frisbee, developers on a new project should not make a statement with more predictive power than “Watch this”!

  34. John thomas says:

    June 13th, 2008 at 9:26 am

    I guess it all boils down to the finished product.


  35. Airs - Ian Lance Taylor » Public Development says:

    June 13th, 2008 at 9:48 am

    [...] been my habit to track other blogs closely, Ben Collins-Sussman wrote an interesting post about Programmer Insecurity. The gist of the post is that programmers need to share code early in the development process. They [...]

  36. vlad says:

    June 13th, 2008 at 10:40 am

    great advice, sometimes we just need to be reminded of these things explicitly, though they seem like no-brainers.

  37. Jonathan Starr says:

    June 13th, 2008 at 11:08 am

    I think the insecurity comes from some of the feedback you get when you post code. Some coders will absolutely flame bad code.

    I am just so happy that there are enough of us thick skinned bloggers and coders to make a vibrant programming community.

    Also, as “bad as it is”, if you compare and contrast the amount of cooperation that exists between coders and then again between other industry practitioners (say lawyers), you may be favorably impressed with the degree of cooperation that does exist in our industry.

  38. On CollabNet says:

    June 13th, 2008 at 11:30 am

    How community happens…

    My friend Ben Collins-Sussman illustrated — just last night — one of the key tools of building and maintaining community in an open- or inner-source world: open-source conversations about open-source relations. And boy, this source is really open! As…

  39. Joshua Drake says:

    June 13th, 2008 at 11:32 am

    @ Leo Katzenstein

    It IS a problem for Math papers. Imagine how many other people may go down those same dead ends on their own, what a waste of time. Or what if someone else could have crossed that last barrier to a more elegant solution? How much faster could Math, or any science for that matter, advance if everyone were not so cloistered?

  40. jeremiah says:

    June 13th, 2008 at 12:17 pm

    programmers want their crappy code hidden because they themselves judge other programmers on their code quality. Also, programmers know they can do better most of the time, and spend time trying to get results rather than making perfect code. I don’t know why this is viewed as shameful behavior (aiming for results rather than perfection) but somehow it is.

  41. Rotten Apple says:

    June 13th, 2008 at 12:39 pm

    It would have been nice if you had not tried to weave the DVCS vs CVCS argument into this post – it has diluted and lowered the credibility of the post.
    And pray which features of subversion were developed in full public view ? Are design decisions taken debate on public mailing lists ? Is the usage of WebDAV something that was debated and voted upon ? What about committer-only mailing lists? …

  42. Joey Hess says:

    June 13th, 2008 at 12:41 pm

    Ben, I think you’re pretty much spot-on in the analysis of why coders do this. I doubt that blaming it on DVCS is useful, even if it’s true that git rebasing has made it much easier to go off in a cave. (And I know cave-dwellers who work on svn projects using git-svn too..)

    You’ve inspired me to look at coders’ commits and see if they’re behaving as cave dwellers or not. Actually, this seems easier to tell if they’re using git, since they’ll probably post a beautifully formed patch series that was clearly artificially constucted after the fact. When I know one of my collaborators is working this way, I’ll try to nudge them to being a bit more open, and a bit more self-assured. Can’t think of any better way to attack the problem.

    Myself, I’ll keep ‘git push’-ing out my “oops, typo” commits on an hourly basis. I’m insecure in a different way — if my code is not pushed out, my laptop could die at any moment and destroy my work. I’d much rather face embarrasment than have to code something twice.

  43. Wolter says:

    June 13th, 2008 at 12:44 pm

    It’s a matter of human nature.

    Yes, life would be a nice big bowl of cherries if people didn’t attack others for political gain.

    But here in the real world, your success in the industry depends largely on your popularity, and any weakness you show is an avenue of attack for your enemies.
    It’s not right, but it does happen. Not a day goes by that I don’t witness yet another ad-hominem attack on someone’s work or ideas.

    Obscurity is safety from the ravaging hordes of idiots and assholes who would rather see a good project burn than see someone do better than they can.

  44. » Blog Archive » On Programmer Insecurity: Is it Personality or the Market? says:

    June 13th, 2008 at 12:58 pm

    [...] a wonderful blog post by Ben Sussman-Collins, “Programmer Insecurity”, to which Jesse Noller has responded with “Programmer Insecurity and Mea Culpa”. (I [...]

  45. Ben Heidorn says:

    June 13th, 2008 at 1:00 pm

    Awesome article. As a student programmer, I don’t often work in projects with others. However, your article is helping me understand the merits of OS, which will become increasingly relevant. Thank you.

  46. D says:

    June 13th, 2008 at 1:02 pm

    This isn’t just a problem for developers. If you ever want to piss off a group of network engineers, just make a comment (any comment) about what they could have done differently. And I don’t mean a six-of-one/half-a-dozen of another comment, but something that is deficient. I was shunned by a group of established network engineers when I joined a company because I told them what was causing their problems. They had problems large enough to take down the entire network multiple times a week, but I was the asshole for pointing out how to correct the problems. These people could not even be civil after I gave my design recommendations.

  47. Donovan Walker says:

    June 13th, 2008 at 1:23 pm

    I’m with Ralf Schneider (comment 16) on a lot of this.

    There are times to be collaborative and there are times to be isolationist.

    Sometimes code is more than engineering. When there is more than one way to ‘do it right’ working alone for a time can be a good thing for a developer. I know alone time at the beginning of a project helps me figure out what I really mean in a piece of software, and how I’d like it to grow.

    After that, where scalability and integration are concerned, bring on the audience! Infact, maybe we could get 10 people to suss the details and I’d just tell ‘em what to do. That would be perfect.

  48. Ben Collins-Sussman says:

    June 13th, 2008 at 1:35 pm

    Rotten Apple wrote:

    And pray which features of subversion were developed in full public view ? Are design decisions taken debate on public mailing lists ? Is the usage of WebDAV something that was debated and voted upon ? What about committer-only mailing lists?

    (1) All of them. (2) Yes. (3) Yes. (4) There are no commiter-only lists. (OK, well, there’s only one, and it only exists as a way to discuss adding new project members.)

    I’m not making this up, go look at the last 8 years of archives.

  49. JimJ says:

    June 13th, 2008 at 1:35 pm

    Paul — I think a rollup command would be very important. For the most part, that isn’t me the original developer talking — it is me the reviewer and me the later maintainer.

    At work, some of our code has includes the cvs log in a bug comment at the front. This (normally useless) comment section can be much longer than the actual code, so it is often just distracting clutter. (And when it isn’t, I often want a diff.) The very fact that the comment cruft will grow acts as a deterrent against checkpoint checkins.

    When browsing, say, the python svn archives, there is a policy against breaking things with a commit, so intermediate checkins are even more rare. But that is actually useful when researching something old.

    So yes, the rollup command (allowing access to the intermediates) is probably a very good idea.

  50. vmonter says:

    June 13th, 2008 at 1:55 pm

    I had a brief stint as a corporate programmer for a finance company before deciding I wanted to be a lawyer because of my social and community involvement, but I can certainly attest to the corporate software job stereotype noted above.

    I was in the QA-group-that-does-programming for automated interface testing (cue Ugh!s) and we worked with some oracle stored procedure programming teams, and our “code reviews” were more like “code presentations” and critique was really not desired by the other team. I was fresh out of college, and my persistent critique was “where are the comments?” especially when coders at corporate financial companies are gray-haired bicycles and a revolving door of H-1b Indians. Good people, sucky organization.

    Did I mention I bailed on that industry? Heh.

  51. kml says:

    June 13th, 2008 at 2:34 pm

    Yow, I’m all for early and often, but it does depend on the project. I remember presenting some early benchmarking results and getting feedback from the junior member of the team about how I should use different gnuplot commands and change the wording of the surrounding verbiage slightly. All this when I’d just thrown something together so that we could discuss the numbers and the implications of the numbers.

    By the same token, I’m gonna check in my prototype code, but I don’t appreciate somebody critiquing my proof-of-concept as though it were the finished product. “Gee, why not make that green, and use a different font here?” “Uh, because the basic functionality isn’t there yet?”

    I can deal with (and appreciate) “Your code sucks, and here’s why, and here’s how to make it better,” but “You should really do this, this, and this next,” is annoying when “this, this, and this” is the plan, but I’ve not done it yet ’cause I’m still working on it.

  52. LewCPE’s Blog » Blog Archive » Egos says:

    June 13th, 2008 at 2:37 pm

    [...] LewCPE’s Blog « Wow Index Egos most programmers are unable to separate their fragile egos from the code they write iBanjo [...]

  53. Hey Developers — Good Stuff — Reid Carlberg: Misc. Notes says:

    June 13th, 2008 at 2:53 pm

    [...] I found it on Reddit but it’s useful.  If you’re a developer, take a look at the bolded items.  If you’re on my team at work, take a good look at them. :)   And have a good [...]

  54. Raphael says:

    June 13th, 2008 at 2:56 pm

    Great article, I really enjoyed it.

    I used to work in a regular shop with lots of developers who were significantly better than I was, and could get feedback from quickly and easily.

    Now I am working on a web application with a designer, but I’m the only programmer. Sometimes I get very nervous about what I’m doing and would love to get regular sanity checks, but I don’t see how it is feasible.

    Any suggestions?


  55. Kyle K says:

    June 13th, 2008 at 3:02 pm

    Everything in this article rings true.

    There’s a pervasive elitism at work in the programming community. Add anonymity to the mix, and everyone is suddenly elite.

    Unlike most other professions where the apprentice is expected to make mistakes and learn from them, only absolute and immediate perfection is accepted (or at least that’s the assumption and thus is becomes a self fulfilling prophesy)

    Online, the people with the most wisdom and experience do not share their knowledge in a friendly manner. They are the arrogant hard-ass black belt grandmaster who beats you with a stick for not getting it right the first time, as opposed to the wise Buddhist philosopher who teaches from the heart because he truly wants you to learn, improve and succeed.

    You’re right. It comes down to insecurity. The true master wants his student to eventually surpass him. The insecure master seeks to undermine and inhibit his student for fear of becoming yesterday’s news.

  56. Rand Branigan says:

    June 13th, 2008 at 6:37 pm

    Software developers are human, what an amazing discovery.

  57. Spiceee Mont Alegre says:

    June 13th, 2008 at 6:47 pm

    There is also the Alpha Male coder, the territorial one that thinks the code is only good when he did some, albeit minimal, changes to it.

  58. Don’t ever be ashamed of your code | Cyde Weys Musings says:

    June 13th, 2008 at 7:24 pm

    [...] you ever ashamed of your code? Don’t be! Being ashamed of your code is harmful, as artfully explained by Ben Collins-Sussman. It’s better to make your mistakes in the open where they can be quickly corrected than in [...]

  59. links for 2008-06-14 says:

    June 13th, 2008 at 7:33 pm

    [...] iBanjo » Blog Archive » Programmer Insecurity (tags: blog code development distributed opensource programming sociology work) [...]

  60. sharkfish says:

    June 13th, 2008 at 10:41 pm

    You know, Google Code is a steaming pile of crap.

    Can’t delete. Can’t select a branch to remove from public view. Confusing, limited interface.

    Fail. Big time.

  61. Ben Collins-Sussman says:

    June 13th, 2008 at 10:47 pm

    @sharkfish: nice try. ;-)

  62. Some call me Tim says:

    June 15th, 2008 at 1:54 am

    There’s a reason that it’s nice to be able to make changes to a DVCS.

    Sure you can look at the crap programmers who build terrible code for months and drop it as a bomb on the repository, but what about features that really can’t be brought in incrementally? What about forks that are made for a good reason–is there no value in keeping the source control connection between the two projects, so that they can trade fixes and features back and forth, even if they remain distinct?

    What about the dozens of programmers who want their work to be tracked by source control, but never actually finish their work? Should that code be tracked in the main repository? Should those programmers need to beg commit permission before even starting on a feature? And what about their commits that will inevitably break trunk–that doesn’t exactly help them gain friends and influence people (or the project).

    So you want them in their own (public) branch, as part of the main repository? Sounds like a recipe for a cluttered repository. Either way, it makes for a lot of programmers who won’t want to put in the effort to become “blessed” by the maintainers, and so therefore a lot of projects that won’t even get off the ground for lack of the necessary activation energy. I find myself on the outgoing end of the programmer spectrum, and yet haven’t ever asked for commit permission–even on projects that I’ve (successfully) submitted code to.

    Sure it’s good to commit early and often, and code review is great. Just KNOWING my code will be reviewed makes me write better code. But if I’m thinking about taking a project in a new direction, I’m going to want to experiment without either a) Abandoning source control for my experiments, or b) Bothering the current project maintainers with my (possibly crazy) ideas.

    I guess I have such a project in mind, though I haven’t started it yet. The nature of the project is “Change the underlying GUI implementation of a project from Windows-native to wxWidgets,” so it’s not something I would want to start randomly submitting snippets of to the main code line–or even try to convince them that they need a branch in their public source tree for, if they have no interest in such a port. On the other hand, before I start I’ll try to have a discussion with the current maintainers–and I’ll share any code that I can make work, if they’re interested. Because I’m not afraid of others seeing my code. But I am afraid of cluttering up their source control system, or breaking their current build for no good reason.

  63. Vince says:

    June 15th, 2008 at 2:51 am

    Nice post. I feel like such an asshole now! I think I should change my ways.

    Let me ask this though, what if you have a unique idea and you want credit for the idea? Should code be shared early?

    There are some serious coders out there that could accomplish something in two weeks that would take me a month.

    Whats your take in that situation?

  64. Dan says:

    June 15th, 2008 at 7:42 am

    While I agree with your point, the guy that started a new job and immediately started mailing his new colleagues criticising their code needs to learn some people skills. What kind of reaction did he expect? You need to earn people’s respect before they will accept your criticism.

  65. Commit Early, Commit Often - The Sane Way To Work : David Stanek’s Digressions says:

    June 15th, 2008 at 9:34 pm

    [...] recent post by Ben Collins-Sussman talks about the benefits of frequent commits. This is a must read for all [...]

  66. links for 2008-06-16 « The Adventures of Geekgirl says:

    June 16th, 2008 at 12:30 am

    [...] iBanjo » Blog Archive » Programmer Insecurity Be transparent. Share your work constantly. Solicit feedback. Appreciate critiques. Let other people point out your mistakes. You are not your code. Do not be afraid of day-to-day failures — learn from them. (tags: programming development opensource versioncontrol code bestpractices psychology collaboration career) [...]

  67. adding to the “Going Dark” and DVCS debate / Justin Mason's Weblog says:

    June 16th, 2008 at 3:51 am

    [...] I don’t think he realised that the Jeff Atwood story he responded to was in fact an echo of Ben Collins-Sussman’s original article, where he specifically picked out DVCS as a source of this [...]

  68. Shlomi Fish says:

    June 16th, 2008 at 9:35 am

    Nice article. Thanks for writing it.

  69. links for 2008-06-17 | Bieber Labs says:

    June 16th, 2008 at 10:34 pm

    [...] iBanjo » Blog Archive » Programmer Insecurity “Be transparent. Share your work constantly. Solicit feedback. Appreciate critiques. Let other people point out your mistakes. You are not your code. Do not be afraid of day-to-day failures — learn from them.” (tags: codereview collaboration development git openness philosophy programming social) [...]

  70. Jakub Narebski says:

    June 17th, 2008 at 4:35 am

    About wanting to have some branches hidden in Subversion repository on Google Code:

    I think it is not about “I don’t want people to see my work-in-progress until it’s perfect.” but rather “I don’t want people to see my work-in-progress until it’s ready.” Or at least it is IMHO *legitimate* concern.

    One would want to have his/her work in progress (WIP) protected by version control system, but with ability to go back and forth to make first draft of series of commits introducing some feature into series of small commits, logical steps in introducing feature, without “oops, there was bug in second commit in series” etc. And I think one solution would to make use of distributed SCM and make changes available to some subgroup, without pushing them to “official” server.

    About using centralized SCM like Subversion offering protection from “hiding in cave”:

    IMHO it is simply not true. The only thing that using centralized SCM does it making ‘cave-work’ submitted as huge single patch, instead of series of commits (patchbomb). One can always use some private SCM, e.g. SVK / SVN::Mirror / git-svn clone of repository do do “work in a cave”.

    Distributed SCM, and especially free DSCM hosting sites offer another solution: you can work on your project “in a cave”, without ‘pushing’ into point-of-distribution official repository (although preferable sending some RFC and WIP patches to git mailing list for review), but with pushing changes into your public repository / your “fork”, of course mentining that in this repository given branches are in flux.

    About git-rebase:

    First, Mercurial has Transplant extension, and Bazaar grafts plug-in, which are equivalent to git-rebase. Second, usually rebase (or some patch management interface like Mercurial queues, or StGIT or Guilt for Git) has its place either in early stages of branch development, or if you are contributor who sends his/her commits by emailing patches (great for code review, by the way). Third, rebase based workflow, as opposed to merge based workflow, has its advantages and has its disadvantages, like every technique.

    About Mercurial exchanging all history, and Git exchanging single branch by default:

    First, you have outdated information about Git. Currently preferred and “best practice” way of adding new repository to pull history from is to use “git remote add”, which sets up nickname (shortcut) used to pull _all_ [regular] branches. Thanks to globbing refspec fetch picks up new branches (you can use “git remote prune” to remove branches which got removed on remote).

    Second, I wonder how many Mercurial repositories use multiple branches per single repository approach. Isn’t it usually singe branch per repository?


    Learning to share your contributions early and often is as important as releasing (creating releases) early and often (release early, release often).

  71. IanG says:

    June 17th, 2008 at 4:58 am

  72. wrs says:

    June 17th, 2008 at 12:17 pm


    The point for why I often refuse to reveal in an early stage what I am working on is that in that stage you’re rather vulnerable to discouraging — and people are not mean giving one discourage. Like the short-sighted ‘that’s impossible’, ‘alone, you’ll never make that’ etc.

    If I knew a chance how to fix that, I’d gladly appreciate it.

  73. New Adventures in Software » Software That Won’t Die: FSA goes Open Source says:

    June 18th, 2008 at 1:55 pm

    [...] FSA because I didn’t feel that the source code represented the best that I was capable of. I was insecure. I didn’t want to be judged as a shoddy programmer. Now I don’t care what you think so [...]

  74. Don’t Go Dark | The CyberwBlog says:

    June 20th, 2008 at 11:54 am

    [...] Collins-Sussman on programmer insecurity: What do you do when somebody shows up to an open source project with a gigantic new feature that [...]

  75. Anthony Howe says:

    June 21st, 2008 at 1:51 am

    As someone with both commercial and free code (not open source) I have mixed feelings about this article.

    For the free and commercial source, I don’t mind getting patches and suggestions concerning the code, but I chose to control design and implementation. That’s just me and how I prefer to work after many years of coding. I take a lot of pride in my work since I do see it as an expression of myself. It also reflects past experience in business, I don’t want to be responsible for other peoples failures, only my own.

    On the other hand, especially when you think your ideas might be the next Google, Facebook, Twitter, whatever, you want to play your cards close to your chest. You want to develop something and be first out the door with something novel. For myself, I share with my team, but not the world. I know I’ve written some crap code in the past, sometimes because speed was more important; “publish or perish, refactor after” (though this refrain can also support your point too).

    You perspective is “open source, open mind, open attitude”, but there are those who have a different history, different experiences, different character who might be willing to share once they reach their an internal milestone. Writing code is a lot like writing a book, some authors want to present “a fait accompli”, while others will send chapters for review to their publisher.

    I guess my point can be best expressed as “open choice”.

  76. Don’t Go Dark | Techno Portal says:

    June 23rd, 2008 at 2:36 am

    [...] Collins-Sussman on programmer insecurity: What do you do when somebody shows up to an open source project with a gigantic new feature that [...]

  77. Stop Being Carbon · Things I wanna read in the next few days says:

    June 23rd, 2008 at 3:55 pm

    [...] Process Diary of a failed Startup Who needs a Computer Science Degree when there’s Wikipedia Programmer Insecurity Metaclass Programming in [...]

  78. Webiest : Links for June 27th says:

    June 26th, 2008 at 5:00 pm

    [...] iBanjo » Blog Archive » Programmer Insecurity – I want to chat about something that I?ve never noticed before, but probably should have. There?s always been a stereotype out there of programmers being nerdy, anti-social people (Q: How do you know when an engineer is outgoing? A: He looks at your sh [...]

  79. Ted says:

    June 28th, 2008 at 9:19 am

    Agree in large part but I think the primary motivation for secrecy is the type of negative, geeky, point scoring criticism I sometimes see. Basically it is easier to criticise than to create and too many focus on the former rather than the latter. Making sure your code review is well thought through and positive even when disagreeing is the best way to encourage others to publish work in progress.

  80. Wait till I come! » Blog Archive » Release early, release often is not as easy as it seems says:

    July 5th, 2008 at 8:38 am

    [...] Subversion godfather and one of the men behind Google Code wrote an interesting article about Programmer insecurity in which he realizes that the whole concept about “Release early, release often” is not [...]

  81. » Link Flood 07/05/2008 says:

    July 5th, 2008 at 4:09 pm

    [...] A lot of programmers need to gain a pair. [...]

  82. » links for 2008-06-14 | Paul Cowles says:

    July 6th, 2008 at 7:21 pm

    [...] iBanjo » Blog Archive » Programmer Insecurity (tags: funny programming versioncontrol psychology) [...]

  83. Programmer Insecurity « IgorShare Weblog says:

    July 7th, 2008 at 11:02 am

    [...] with co-mentors of GSoC (Google Summer of Code) the communication channels and practices a “Programmer Insecurity” blog post was mentioned – great article and right to the [...]

  84. The Punch Barrel / Programmer Insecurity says:

    July 11th, 2008 at 4:22 am

    [...] iBanjo » Blog Archive » Programmer Insecurity [...]

  85. DVCS and its most vexing merge says:

    July 11th, 2008 at 7:04 pm

    [...] recently was this argument about DVCS encouraging “code bombs”, a.k.a “crawling into a cave”. I [...]

  86. Rein Henrichs says:

    July 13th, 2008 at 7:33 pm

    Whie I agree with the general thrust of your argument, I find it incredible that you would claim that any technology can cause or exacerbate what is clearly a social problem. Social problems such as this are not created by technology and, likewise, cannot be solved by technology.

    To suggest or imply that people should not use Git because “Git leans much more heavily towards cave-hiding” is a dangerous red herring. The issue here is a dysfunctional culture, not a dysfunctional tool. You (and everyone else facing this sort of issue) would do far better to address this directly rather than project the cultural and social failure onto mere tool.

  87. Respect for People, and Mean-Spirited Trash Talk « Martin Cron says:

    July 17th, 2008 at 10:56 am

    [...] culture of harsh criticism is what leads people to be generally closed and insecure. Personal example: I thought about releasing the source code to my little Survival-Horror Asteroids [...]

  88. Mercurial Woes at Toolness says:

    July 27th, 2008 at 3:52 pm

    [...] of hg fetch). The disadvantages of the first approach are nicely explained by Ben’s post on Programmer Insecurity; the latter approach is bad for obvious [...]

  89. When Is Low Quality Good For Your Project? « Leadership in Social Networks says:

    July 28th, 2008 at 4:49 pm

    [...] Ben Collins-Sussman from Google’s Open Source Project Hosting project shares his view on why you should allow early collaboration on your project, even when it means releasing a [...]

  90. malvasia bianca » Blog Archive » random links: september 1, 2008 says:

    September 2nd, 2008 at 12:06 am

    [...] Programmers, insecurity, source control. [...]

  91. epic fail!» Blogarchiv » Releasing Software is hard… says:

    January 17th, 2009 at 1:54 pm

    [...] on post 0.2 features rather than finishing up that release. On the other hand it was clear that “release early, release often” (metalink ) is not just phrase, but a necessity if you want to draw peoples attention to what we [...]

  92. vishal says:

    April 6th, 2009 at 2:59 am

    but doesnt google do the same.
    they never release a project until its in a working condition?
    the entire project is a code bomb in this case :)

  93. Rob’s Higher Ed BI Blog » Protracting Peers says:

    April 19th, 2009 at 7:25 am

    [...] can read Ben’s post in its entirety, complete with the subsquent 90+ comments here, but for me, the closing paragraph says it all. Be transparent. Share your work constantly. Solicit [...]

  94. punit says:

    July 13th, 2009 at 1:25 pm

    well, in actually i need some help , i am new in programming , right now i am trying to design a programme over a problem ,

    i am trying to make a programme which can find the all possible unique sequense combinations ,

    as a example :

    there is a block of few characters:

    0 1 2 3
    0 | A T G C
    1 | A C T
    2 | G

    1*2*2*3 = 12 ,



    1: ATGC
    2: ATGT
    3: ATGG
    4: ATCC
    5: ATCT
    6: ATCG
    7: AAGC
    8: AAGT
    9: AAGG
    10: AACC
    11: AACT
    12: AACG

    i am clueless so please if any body can suggest, give any logic over this pls.

  95. When should you commit source code? « Deliberating On Software Development says:

    March 7th, 2010 at 9:30 am

    [...] mantra is repeated all over the internety-thing here, here and here.  The biggest mistake that programmers make when working with a version control [...]

  96. Why committing early is anti-social « Software Whys says:

    July 8th, 2010 at 1:55 am

    [...] committing early is anti-social July 8, 2010 kbielefe Leave a comment Go to comments This article expresses concern that distributed version control encourages the anti-social behavior of [...]

  97. Burning Chrome » Commit very early, commit very often! says:

    July 30th, 2011 at 12:51 am

    [...] probably heard it before: “Commit early, commit often“. It applies to teams, and it applies to [...]

  98. joocom Technologie Blog» Blog Archive » Link: Programmer Insecurity » joocom Technologie Blog says:

    January 13th, 2012 at 3:58 am

    [...] interessanter Artikel von 2008: Programmer Insecurity von Bel Collins-Sussman, über die Wichtigkeit Code früh und oft zu teilen, und mögliche Gründe, [...]

  99. 11DigitPrime says:

    January 22nd, 2013 at 10:53 pm

    [...] spring “perfect” code on their community, as if no mistakes had ever been made. Guilty. (via iBanjo) June 13, [...]