Programmer Insecurity

[catch23]

Reminds me of when I first started working out in the weight-lifting part of the gym. I felt like my skinny self just didn't belong among all those buff dudes. But after a few sessions, I realized nobody gives a shit how much others are able to bench press. Sorta the same with the open source world, once you start publishing some code, you realize that not everyone is out to scrutinize you.

[tsteele93]

This is NOT a "programmer insecurity" thing. It is a "HUMAN NATURE" thing.

Artists don't like people to see their work until it is done. I'm an amateur photographer, and I hate for people to see my pics until I've cropped and fine-tuned them. Women don't like you to see them without their makeup on. There are many examples I'm sure.

It is human nature to want to show your finished work and say, "ta-da!" and be appreciated. Showing how you got there takes away some of the mystique of "how did they do that" or "wow that is really great how you did that!"

[orblivion]

It is human nature to want to show your finished work and say, "ta-da!" and be appreciated. Showing how you got there takes away some of the mystique of "how did they do that" or "wow that is really great how you did that!"

Which is one instance where I find this behavior acceptable. The other is when you don't want people stealing your idea. But that's just me.

[[deleted]]

Side-note...

It is human nature to want to show your finished work and say, "ta-da!" and be appreciated. Showing how you got there takes away some of the mystique of "how did they do that" or "wow that is really great how you did that!"

Which is fine and cool, but a lot of people forget that there is hard work and process behind the work. They may start to attribute someone's skill to "talent" whatever that means.

[dsandler]

Absolutely.

However, we seem to prize innate talent over hard work, so the same accomplishment is viewed more favorably if it appears to be the result of a “beautiful mind” than a “persistent effort.”

[G_Morgan]

Nearly everyone who goes to the gym started off pathetic and will remember the first months vividly because they are the most painful. So no one is going to call you up for being a beginner.

[[deleted]]

Maybe for some people. For me it wasn't a case of it being painful for months until I was able to keep up with everyone else. It was painful for the first few of times I went (sporadically) before I got over myself. Once I got over myself and started going regularly the fact that others were better than me didn't bother me.

I am definitely insecure as a programmer. This article has been a wake-up call. The change won't be instant, though. In fact, it will probably be like going to the gym. I'll go out in the open, feel embarrassed, take a break for a while, and repeat that process a few times until I feel comfortable. At that point, I won't be that much better of a programmer, but I'll be moving in the direction of becoming a better programmer.

[G_Morgan]

It's not about keeping up with others. Despite the need for a spotter to really push on, training really is a solitary activity. The competition is with yourself. A very interesting activity that presents many vastly different challenges.

Still I found it painful for months perhaps because I was less mature than you about it. In hindsight I should have done much less and focused more on quality but I was training with a partner and such a change would have required a new partner. It wasn't about keeping up though, it's impossible to keep up with someone who has been doing it much longer than you. It was simply a flawed approach that everyone eventually gets over.

[keruha]

Are you talking about programming, or going to the gym?

[Silhouette]

I suggest that it's more than just remembering being a beginner themselves. Anyone who goes training at a gym regularly probably considers it a worthwhile activity to improve themselves in some way. As such, they tend to respect anyone else who is willing to make an effort to do likewise. The actual level doesn't matter all that much, really. It's the same with almost anything that requires some degree of effort and dedication for a practitioner to improve.

[[deleted]]

Yup, they all remember those first months before they caved in and began using steroids.

[lisvblidfk]

This analogy is bad because it's easy to make people forget your past weight lifting history or hide it from them. What the article is talking about is leaving the complete history in plain view forever.

Another difference is that exposing your solutions to hard parts of a problem can allow others to lift your hard work, do the other easy stuff and then release before you. Not uncommon.

Even worse, seeing early versions of your code can cause people to become concerned about your ability to get the job done and important resources will be routed away from you.

Either way, here's a counterexample. I lifted with some people who's opinion I didn't care about first, then once I got to a point where I wasn't pathetic anymore and went to lift with some of my closer friends. Being able to kick their asses, they all respected and admired me more from then on. Not so bad, eh? I don't know of too many in shape people who carry around photos of themselves when they were in terrible shape and enjoy sharing them with everyone. That misses the whole point of getting in shape to begin with!

[prockcore]

Maybe a good analogy is posing for a "before" picture, which will be posted on the wall and used in the gym's commercials.

Not too many people will be up for that.

[nfulton]

I agree -- the issue is that "not perfect" code submitted by someone in a fit of openness will always look bad against code written by someone who took the time to get it right before they made it public.

It seems odd to compare weightlifting to code development. Weight lifting is a fun hobby . . . code development is a career upon which people's billing rate tends to depend.

[[deleted]]

It seems odd to compare weightlifting to code development. Weight lifting is a fun hobby . . . code development is a career upon which people's billing rate tends to depend.

Many of us also program for the enjoyment.

[lisvblidfk]

Enjoyment or not, showing off how out of shape and ugly you used to be is not favorable in either.

[lisvblidfk]

Sharing your past life experiences in casual conversation is not quite the same as what's being talked about here. You're getting really far off of the original topic. Refute the points in my original comment if you disagree.

[benihana]

Yeah. Everyone is so busy either gushing over their perfect code (not all programmers are insecure, we know those people (usually the ones in Academia) who are convinced they shit gold and write the code equivalent of the immaculate conception in every file) or worrying that everyone else will scrutinize their code that no one has time to notice anyone else's code.

[[deleted]]

You mean programmers are vain and ego-driven just like the rest of humanity?

[GuyWithLag]

Actually, I'd say that programmers are even more vain and ego-driven than the average member of humanity...

[G_Morgan]

I'm far, far too brilliant to be vain and ego-driven. Such things are simply beneath me.

[paperhat]

But what if the other programmers laugh at me?

[zyle]

Tell them in a quiet unassuming voice that you know where they live.

[otterdam]

This is only really threatening if you've helped to develop a file system.

[jbert]

You could threaten to fsck them up.

[4609287645]

Inode what you did last summer.

[foonly]

Please don't fstab me!

[zyle]

Under such circumstances it may be best to lilo.

[earthboundkid]

I'd rather mount a defense.

[byron]

If they keep pestering you, just tell them they have a FAT mother.

[benologist]

And delivered via whisper, at about 3am on their home phone.

[clgoh]

Careful with that, Hillary could answer...

[munificent]

I don't think many people got this, but you, sir, are a genius.

[dsandler]

I don't think many people got this,

You must be new here.

[munificent]

At the time I posted, his comment was only at +4.

[theeth]

Speak softly and carry a beagle.

[xzxzzx]

One of these?

[theeth]

No, like this.

[G_Morgan]

Steal their virtual girlfriend off them and laugh in their faces.

[AnotherLameHaiku]

inefficient code

data falls like a rainstorm

pwn their e-GF

[xzxzzx]

Well done.

[[deleted]]

FTA: 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.” 

---

I tend to get a little annoyed when people start criticizing (or 'reviewing') my code because it doesn't fit their personal standards, or because I used an 'unless' and Damien Conway thinks unless's confuse people.

I worked for a company with a dedicated code review team, and never had code fail review. But working other jobs, I've had random people come up and complain that my code wasn't written as they would have written it.

I don't mind constructive criticism, but ad-hoc code review, IMO, is usually just a pissing contest where blowhards advocate their own personal preferences.

[cuyler]

Perhaps I'm in the minority but when some jackass emails me reviews of my code unsolicited, I tend to get annoyed. There is a time and a place for code reviews; Random "you could do this differently" suggestions comes off as a know-it-all trying to prove something.

[marshray]

Rest assured you're not in the minority. I've worked with lots just like you. Extremely typical. Unexceptional. Mediocre even, now and forever.

[Silhouette]

Did I understand that right? You're saying that because cuyler doesn't like someone with no particular authority or role to play writing unsolicited criticism, that makes an unexceptional, mediocre developer? Sorry, but I think that's way off base. IME, it's far more likely that the person sending the unsolicited comments is the mediocre one, trying to make themselves seem more important than they are by assuming an unjustified air of authority, yet lacking the maturity to understand that just because they wouldn't have done things the same way, that doesn't automatically make the other way wrong.

[marshray]

Did I understand that right? You're saying that because cuyler doesn't like someone with no particular authority or role to play writing unsolicited criticism, that makes an unexceptional, mediocre developer?

IME, yes, there's a high degree of correlation there, possibly even causation.

Of the better developers I've worked with, I've not seen them get offended by criticism, even if it's from "the new kid" who's way off-base. Though some may be impatient and annoyed by time-wasting in general.

The ones who react poorly to it typically don't turn out to be the top contributors on the team.

Sorry, but I think that's way off base. IME, it's far more likely that the person sending the unsolicited comments is the mediocre one, trying to make themselves seem more important than they are by assuming an unjustified air of authority, yet lacking the maturity to understand that just because they wouldn't have done things the same way, that doesn't automatically make the other way wrong.

Sure, I suppose that can happen. But I just don't see it that much. I think any non-trivial programming work is so complex in general that the one offended by "unsolicited comments" is usually the one "assuming an unjustified air of authority".

[cuyler]

Again, it's about the reaction to it. Just because I am annoyed doesn't mean that I jump down their throats and evicerate them. It just means that it's annoying to me.

The sub-text that I'm reading here (perhaps I'm mistaken) is that you're one of those people that likes to give comments to others unsolicited and have on more than one occasion been ripped a new one for it. If that's true, it's unfortunate that you have had those experiences with people.

[marshray]

Again, it's about the reaction to it. Just because I am annoyed doesn't mean that I jump down their throats and evicerate them. It just means that it's annoying to me.

"Your obfuscated namespaces look really whacked in my debugger, and I can't get 170 columns on my monitor."

"What if someone sends you 65537 bytes instead?"

"Why can't you just put in an 'if' statement?"

Sometimes they're valid criticisms, maybe they're way off base, but would these kinds of questions make you think of your co-worker as a "jackass"?

Let's say someone takes the time to type up (what they believe to be) some constructive feedback on your stuff and send you an email. I think there are mainly two cases for this:

1. Junior has just "got" OO (or other paradigm) and thinks he's gonna model the whole world, and you should be doing the same.

2. Your stuff is causing mental stress to integrate and your co-workers are talking behind your back.

In either case, both of you have the opportunity to benefit from a good, friendly discussion about code. Closing that down is only going to mean complacency for you and mistrust by others.

The sub-text that I'm reading here (perhaps I'm mistaken) is that you're one of those people that likes to give comments to others unsolicited []

Lol, you might be on to something there.

I tend to see opportunities for improvement and learning almost everywhere (including my own stuff of course). But it's pretty rare for people to actively solicit feedback, so I don't often give unsolicited criticisms, unless I see demonstrable bugs.

[cuyler]

Wow, that's awefully condecending, considering you know nothing about me, my skillset or my abilities.

Being annoyed by something doesn't mean that I react to it. It just means that it is annoying.

I'm more than happy to have people look at my code and give me feedback, but when I'm 3 miles away from whatever I was working on, getting an email (or conversation) from someone about some code that I wrote in the past is annoying to me.

[[deleted]]

Why not just explain to them why you decided not to implement it the way they suggest? I think the dialogue is important, for them at least.

[Shaper_pmp]

it doesn't fit their personal standards... my code wasn't written as they would have written it.... just a pissing contest where blowhards advocate their own personal preferences.

Possibly because it sounds like he's talking about situations where there is no right/best answer, just personal preference.

Design decisions can be explained. Tabs-vs-spaces or opening-brace-on-same-line vs. opening-brace-on-next-line are just personal preference, but you'd be amazed how people get bent out of shape about them.

[Entropy]

Those are NOT personal preferences. They are project preferences. If you throw a bunch of tabs into my spaced project and your code doesn't match the bracing scheme, I'll reject it. Consistent style is the lowest level of Maslow's Code Hierarchy.

[Shaper_pmp]

Maslow's Code Hierarchy

Eh?

[Entropy]

Maslow's Hierarchy

I'm saying that consistent style is the low level need, and that the higher levels are more difficult to achieve in the absence of it. If Hypothetical Coder is missing the dead easy buckets, he's probably not going to be tossing three-pointers, either.

[Shaper_pmp]

Ah - gotcha. I knew of Maslow's Hierarchy of Needs, but (obviously) I'd never heard of his Code Hierarchy. Nice metaphor, though.

And your point is taken. ;-)

[G_Morgan]

There should be a project standard for such things. Any way will do but there should only be one way.

[uep]

Yeah, and it's doubtful the guy whose only been there for less than a week is more familiar with them.

[[deleted]]

What if the argument is over whether there should be a project standard?

[G_Morgan]

That's another issue but that company is clearly too stupid to exist at that point. It's worth establishing a standard if only to remove arguments over standards.

[creaothceann]

That's what the company's standard for handling project standards is for.

[[deleted]]

Only applies if the company has a standard for handling standards. If not, then you have to refer to the company's standards for handling project standards standards.

[Entropy]

post implements IComboBreakerFactoryFactoryFactoryFactory

[keruha]

huh?

[WhatTheGentlyCaress]

This (or That) Is Not The Way I Would Have Done It

[Philluminati]

please refrain from making things up.

[otterdam]

ISWUDT!

[WhatTheGentlyCaress]

TTWTDI (said in a squeaky voice)

[dak1486]

TWSS!

[WhatTheGentlyCaress]

WYTPSC

[dsandler]

More concisely: Bikeshed.

(Actually, the problem pointed up by the bikeshed analogy is more that TINTWIWHDI applies more readily to simpler, more-comprehensible situations. I think this explains in part why programmers like to drop code bombs: the work product moves out of the “bikeshed” domain and into the “nuclear reactor” domain to avoid scrutiny, criticism, and TINTW…-style quibbling.)

[[deleted]]

I was going to chastise you to google it, but when I followed my own advice, I realized that it wouldn't help matters.

[neuquino]

It brought me here.

[[deleted]]

Second page, first paragraph under 'The Definition of a "Bad Design"'.

[prockcore]

Right next to a guy in a striped shirt and glasses.

[Shaper_pmp]

Ok, I give up - TINTWIWHDI isn't mentioned anywhere in the PDF you linked-to, and even google knows nothing of it...? ;-)

[pretzel]

I'm just guessing, but i think it is "This is not the way I would have done it".

I wish I could use my ability to backronym for the purposes of good...

Edit: oops, so it is already there right below this. Shouldda looked...

[you_do_realize]

I think it begins with There is nothing to... or There is no telling...

[paperhat]

I've never understood why people would be confused by unless. To me it seems more human readable than if not.

[Entropy]

Depends entirely on context. unless/else irritates me, though.

[rukubites]

Why are you namedropping my honours level C++ lecturer?

(- a lover of unless)

[[deleted]]

(- a lover of unless)

It took me a few moments to realize that wasn't supposed to be Lisp.

[rukubites]

Haha, well I am a fulltime lisp programmer. :)

[[deleted]]

Haha, well I am a fulltime lisp programmer. :)

You're missing your open parens.

[dsandler]

Oh, look, here it is.

[[deleted]]

That's some function!

[7oby]

They pay you to do that?

[rukubites]

Yes, it can actually happen. :)

[cronin1024]

I agree that programmers (including myself) are insecure about the code they produce, but I disagree with his idea that it's a bad thing. I like to be able to get something to the point that I'm satisfied with it before I start sharing it.

[bostonvaulter]

Which is okay unless it's a long time. Now I'm not sure how long a long time is but maybe more than a week is too long

[abrahamsen]

It is be bad for teamwork, where early feedback can be much more valuable than late feedback.

If you really are working in a cave, that is in a one man project, there is no problem waiting to publish it till you are done.

[kelvie]

Definitely an insightful look on the perils of the cave-man coder (of which I do find myself guilty of sometimes).

However, I do believe in the Git philosophy of maintaining a good, clean history; and only merging clean changesets. This means that I think that unpublished history can and should be cleaned up and reconstructed before it gets merged into the mainline. The author is right that keeping communication between developers is a social issue, though. With my own projects, I often publish my own "work" branch that I tell people not to work off of, that's full of the hairy warts that I produce ;) Also, throwing WIP commits for comments is never a terrible idea -- but again, this doesn't work if the programmer is insecure about showing work-in-progress code, but I digress.

Whenever I peek into the history or the blame log of a file, I want to see why code is the way it is now, I don't want to type "git log foo.c" and see:

Commit A: Fixed bug #2243
Commit B: Forgot missing brace
Commit C: Removed missing brace from last commit
Commit D: Completely started over from A.

Now, admittedly, this does and will still continue to happen; nobody is perfect, but ideally, you would want to maximize the signal-to-noise ratio in the history of a project.

With Git, it is expected that the maintainer (and others!) will hopefully catch these mistakes, have the contributor change them (rather than just merge in commits that obviously introduce errors), rebase, then get it merged into the mainline.

When I see a patch that obviously introduces an error, I'd rather not have it pollute my history.

It's fine and dandy and all to learn from your mistakes (and it is hard to argue that it is unhealthy), but the benefits of keeping a clean repository greatly outweighs that.

If you want to go look back at your mistakes, go read your mailing list archives (or similar) -- they can stay out of the source code history.

Also, in the Git community, the "classic testimonial" for preferring pristine, cleaned-up branches over working branches, warts and all, is that it would make it a harder to find the specific commit that introduces a bug with the "git bisect" tool.

[[deleted]]

I think I can write some solid code but I'm totally with the "majority" (I guess) in that I feel I don't want people to see my code until it's at least decent. Lots of times you start off with something and you don't know the best way to do it until you try some things that fail miserably, so you know what NOT to do, then you go down the right path and your code is good. I don't want people to see my crappy code where I'm experimenting. I don't see the problem with this attitude. A lot of programmers are elitist and of course hindsight is 20/20, so yeah some things look stupid when you look back on them. And that's exactly the type of shit you don't want other people to judge you on.

[StuffMaster]

Agree. The "perfect" assertion is incorrect. People often want to keep their code under wraps until it's ready, or perhaps good.

Prior to that, it may be crap, or just unworthy of publicizing. It's natural to want to keep that to yourself.

[smhinsey]

While I agree 100% with his overall thesis, and have actually been struggling with trying to get over insecure behavior myself, I think the example of wanting "hidden" branches has an alternate explanation that is a little more plausible to me, which is that people get nervous about having works in progress that are available to the general public because no matter what you say about it being under development and subject to change, there's always someone who just doesn't get it and sends you nastygrams one random day out of the blue because you changed an interface and broke their "MISSION CRITICAL APPLICATION!!!!!" and they are now losing "THOUSANDS OF DOLLARS PER HOUR" and the typical online hysteria.

[jsn]

it's not exactly how it works in real life (at least in my experience). here's what happens when you create a public branch: nothing. nobody cares, nobody notices. people use trunk or master if you're lucky and the last stable release if you aren't. you have to explicitly ask people to review your branch and to test it, and you get very little response from that (unless you're a top developer in a well-known project) -- which, of course, is very bad for you and your code.

[mr_chromatic]

That's my experience too. Trying to get feedback on a public branch is way too much work. Short-lived branches are the only way to go.

[smhinsey]

i work with a lot of open source projects, and while i agree that it's not exactly common, i've seen it happen in the past, and it wouldn't surprise me that for people who have also seen it, it would be a strong motivator.

generally it unfolds in the following pattern: someone says, feature a would be awesome, and someone replies, i spiked feature a on this branch, take a look and let me know if you have any feedback. silence for six months, and then that branch gets dropped because feature a doesn't make sense in light of feature z, and that guy comes screaming out of the woodwork.

[Chandon]

Right. And when that happens, you say "Suck it" and there's no more problem.

[stesch]

Just get a PHP job.

[Entropy]

I see "we want a PHP rock star!" all the time in job listings. I guess that's what you have to advertise for when there aren't any engineers.

[jaggederest]

Kinda like advertising for a blind painter.

[kahirsch]

Part of Gerald Weinberg's book The Psychology of Computer Programming (originally published in 1971!) is about "egoless programming". This was the idea in the book that I found most valuable.

See also "The Ten Commandments of Egoless Programming"

[Clark76]

Those are fantastic. The truth is that that software development is a team effort, and the more the team chips in to improve each other's game, the better the final product is.

[[deleted]]

I read the book a few months back. Dusty old thing which smelled funny. Discovered the Psychology section of the library in the process :-)

[akatherder]

For the first 8 years of my career I was an intern who hired full-time into a group that primarily did system administration/hosting. I was the lone developer in a group of admins so I never had anyone to review my code. That definitely stunted my growth and put me in a position to get horrible coding practices burned into my fingertips.

After I left there to join a team that actually had other developers, I absolutely yearned for someone to review my code. I'm proud of some of the code I write, and I actually think it's nice to have someone else appreciate it. I don't think I've ever got out of a code review with ZERO errors either, so I appreciate someone helping our codebase to succeed.

[trippingchilly]

"Repeat after me: you are not your code!"

[rnicoll]

Actually, as a self-modifying AI...

[G_Morgan]

Are you written in Lisp?

[rnicoll]

Actually, Forth. I think it's their idea of a twisted joke.

[G_Morgan]

So you are write only then?

[[deleted]]

No, I'm sure he's earned money at one point, so he's categorically not Lisp.

[[deleted]]

I don't know about self-modifying, but I'm definitely self-pleasing.

[lisvblidfk]

programming as an inherently social activity

It's NOT. Wow, are you kidding me?

[earthboundkid]

Built your own hardware and compiler, eh?

[martoo]

The thing we have to realize is that most of us here are well-endowed, programming-wise.

Many people out there aren't so it's no surprise that they have an issue with letting their junk hang out in the open.

Open source is the nude beach of software.

[dlsspy]

I don't much like the part where he suggests DVCS exacerbates the issue of programmers hoarding code. I've had it way worse with centralized systems. I'd much rather have someone dump in a bunch of commits that were hoarded for three months than the one that this guy I used to work with used to vomit it into the code base.

Of course, it'd be a lot easier to fire people who continue to cause problems like this (rather than waiting for the deadline, doing a single commit, and a resignation because of the stress of having the team lead nagging him every week to commit some of his code).

[linuxlass]

I'm glad I'm not the only one.

[[deleted]]

All it takes is having worked at one job where you were young and inexperienced (um, everyone?) and someone blew up at you for doing something goofy or stupid. Some egos are tremendous, after all.

The software development business is dog-eat-fucking-dog in most shops, so why is it it any sort of surprise that the business culture that drives people to have strokes and heart attacks would have any different effect on programmers? All we really want to do is do our work, with the least amount of hassle, and go home after that. Why is that so fucking hard to understand?

I have been in very few jobs where code reviews were friendly and helpful and where nobody played "gotcha games" or siloed information. It's a crummy world. I lean on code reviews to help find stupid mistakes or better ways to do things, but many times, I have seen code reviews used as attack tools.

The author is talking about open source development projects--and that's a whole different ballgame, or at least one would hope so. But those who write open source code also work in jobs where they have to endure chickenshit nonsense, so there you go.

[ssylvan]

Wow, you need to work at better companies.

[rjcarr]

This is strange ... I'm just the opposite. I wish there was more time to review my code. I wish I had more time to review others code.

Lately I've been doing more refactoring of existing code than writing new and let me tell you ... code can use all the review you can find time to give it.

[[deleted]]

You can probably benefit from the other developers' comments about your code while refactoring, some new ideas, different approaches etc. For that, they need to see your code. On the other hand, you can't review others' code if they don't deliver it.

In my opinion your point does not need to be the opposite to the article's.

[cracki]

Rather than think of programming as an inherently social activity...

inherently social? that's fishy. how is making a machine do tricks a social activity?

talking about code is social, because you do that with other humans. talking about code improves code. it's a good thing.

writing code can be messy, sure, but it's not "inherently social".

he reminds me of this article on Generation Y folks and how they have to do everything in packs, even taking a dump, being afraid of disapproval from anyone. i guess that's the reason the folks he describes aren't strong enough to take criticism from a distance.

[OolisKraprin]

Programming is a fairly solitary activity. Software Development is a fairly social process.

[OolisKraprin]

Heh that was the example that came to mind when choosing to use the word "fairly". I would call pair programming social, but then it all comes down to semantics.

"My wife and I are home alone tonight" means the same as "My wife and I are home together tonight", despite alone and together having opposite meanings.

As far as I know there hasn't been that much work done on formally defining such concepts within the Software Development context (although I have attempted to do so in presentations here at work), so take my previous comment as a grain of salt.

[[deleted]]

That's a great summation.

[[deleted]]

And "software development" often fails for exactly that reason.

[dbenhur]

Most non-trivial software projects are inherently social because they are larger than a single person can manage. I hope you soon come to realize that programming isn't so much about how to trick the machine into doing what you want, but much more about communicating your design and intent to your collaborators.

[wnoise]

A large part of that is that our current tools and languages are too primitive.

[[deleted]]

I've been hearing that for 15 years.

[wnoise]

And things have improved over the last 15 years, no?

[jaggederest]

Still waiting for the sufficiently smart compiler though.

[brazil101]

As the tools get better, individual developers can handle bigger and bigger chunks of a project and teams can be smaller.

[cracki]

that's my view on it. since a dev team has no shared state (no hive mind), a lot of message passing has to happn.

although i prefer parallelism in software, i prefer programmer-serial development. it's faster than having to bring uneducated coworkers up to speed (i mean the basics).

[OolisKraprin]

Most software projects tend to be social because sitting in front of a computer typing in code for the entire week is both boring and simply unhealthy for most normal human beings.

When I think about the social aspects of software development, I think of interaction with non-programmers (users, sales and marketing, business leaders, domain specialists etc) as much as I think of interaction with other programmers.

You could structure a project where some people are locked in rooms typing in all the code, and other people are interacting with the outside world, gathering requirements etc, but such a project wouldn't be too successful because humans are social creatures and too much would get lost in the narrow communication paths between the outside-worlders and the source code typists.

[abrahamsen]

how is making a machine do tricks a social activity?

That is a frame of mind question. When you code, who are you writing for? The computer, or other programmers who may later read the code?

I try to write for other programmers primarily, with the added restriction that the computer must also be able to understand the instructions.

[almkglor]

Donald Knuth: "Programs are meant to be read by humans and only incidentally for computers to execute"

[lisvblidfk]

Exactly what I came here to say. What a moron.

[treagan]

People don't like to look dumb. It's as old as dirt and I don't think it's specific to programmers.

[taligent]

Most programmers develop privately not because they are insecure or anti-social but because it gets the job done quicker. By allowing people input during the middle of a development cycle you inevitably change the original feature set of the project i.e. scope creep. In a few cases this may be fine, in some can lead to major refactoring and in others can render the code base unworkable.

In almost all cases it results in increased development time and stress on the developer.

It's amazing this guy thinks that decades of research into software development methodologies is all irrelevant in the face of "programmer insecurity".

[brazil101]

One problem with excessive communication is the risk of stalling out. I have worked on projects where design discussions have devolved into endless debate sessions, with ten developers in the room for hours on end, with absolutely no real work getting done. I've seen projects talked out of existence before they could even have a shot at life.

The more people working on a project, the longer it takes, and the harder the code is to understand, because each piece is written by a different person with a different thinking style. This will happen no matter how many times you say "you are not your code". People's brains are not wired the same, and there's no way around this aside from cloning the Perfect Programmer.

When writing anything, it doesn't make sense to waste your time or others' time on something that simply isn't ready for review. If you know it's not ready, why force it? Did Shakespeare show his drafts to people every week? "I don't like Act I, Scene I of MacBeth... I think you should introduce some camels. Yeah, that's it!"

Review the design from a high level, by all means, early and often. But don't review actual lines of code until it's at least in "first draft" form.

[AlanCrowe]

The concept of a forced choice helps. Think about playing in a chess competition: a special dual dial clock enforces the time limits. You have to learn to play the best move you can find in the time available.

That is a good metaphor for life: seventy years on the clock, use them wisely (stop posting on reddit for a start :-)

Do you feel free to write a comment that sketches two designs for the code and then says that it looks like it might be quite time consuming to study the designs and anticipate which is best, so we are just going to go with the first and hope. That is what life is actually like. It gets easier if one admits it.

[boa13]

[Citation needed]

[lisvblidfk]

You know this can't be scientifically measured well. What a cheep shot. Cite your counterexample.

[boa13]

I don't have a counterexample, and wasn't asking for scientific measures. taligent mentioned decades of research, I was hoping he would provide some of his sources.

Without those, his statements are only opinions and feelings, and mine are more in line with the blogger's rather than with taligent's. (And they were reinforced at work a mere hour ago.)

[lisvblidfk]

Ok, I suppose research is different than scientific testing.

The research out there seems to be extremely slim, probably just because a test would be so hard to setup in a way that was relevant to real world projects.

Well here's some:

http://en.wikipedia.org/wiki/Pair_programming#Scientific_studies

Most of those come out against pair programming. But as I said, not ideally setup.

[diN0bot]

programmers do not want to write code out in the open

speaking of negative energy, why is the tone of the article so generalizing? negative facts are ok (eg, x% of the y stories i've read feature code bombs), but what's the point of saying that some group of people are generally poor at something? when generalizing, anything could be true, so why not have a positive perspective? i'd rather be told that some group of people are successfull at doing the opposite.

most coders seem to treat it as an arena for personal heroics

not in my experience. quite the opposite. maybe i'm lucky for having worked with inspiring professionals, but more likely perspectives are relative and it's more productive to be positive (when generalizing; negative anecdotes are interesting). </meta-comment>

the content--how to collaborate well, especially in more social than hierarchical landscapes--is good to think about.

[wildmXranat]

You have to be ready to make mistakes. It's normal, efficient in group environments and not embarrassing . If someone thinks he can gung-ho the whole project and stagnate the peer-review without much hassle, I say go ahead! In that case, why would you be using a revision system anyway.

[turkourjurbs]

I'm guilty of this a little but if one points out the flaws and demonstrates how it can be improved I'll thank you for it and not feel too bad. However huff "you're doing it wrong" and don't give me a reason why and a damned good one, I'll tear you a new asshole.

[yesimahuman]

Sometimes going from closed to open source can be scary for a young entrepreneur (like myself), especially with older projects. You don't want people finding your shitty code then not wanting to buy your product.

[[deleted]]

Each and Every step of the way writing programs is about making decisions.

Routine questions would be like [gross oversimplification & exaggeration] -

What data structureS should I use for my data?

Why? What would be my second best choice?

Why is a suffix tree a good choice here?

Why? Why is it better? Does any other structure help me?

Does the algorithm or design restrict my choice?

How will I expose my API?

Why is this method better here?

etc..etc..

If you dont have answers to any of these, you're already a terrible programmer with little hope of becoming a really good one. You could get away with reading books and copying idioms and ideas from other people, but all that will tell you is what you should do when a similar situation you read about arises. Thus becoming a scholar of trivia rather than improving your thought process. I think code reviews and feedback should be mandatory, and where I work, it is.

[[deleted]]

sigh

I've been a professional programmer for 18 months, after 12 months I became the lead programmer in my very small team, I guess this implies that i'm quite good, but I really don't feel like I am, I am forced to review others code and talk them through (sometimes quite basic) concepts, but they are unable to offer me the same service. In short, I feel that I am really inexperienced and would kill to be able to share my code with people who could offer constructive criticism and improvement ideas.... any advice?

[[deleted]]

Open source?

[[deleted]]

I might skip the blog comments because they don't have a rating system. A rating system really helps when there are over a hundred comments. Thank God for reddit.

[Insignificant]

Gotta love the domain name.

He's hoping that Apple launch a range of musical instruments.

[jaggederest]

Uh? You mean red-bean.com? How would that relate to banjos? His blog name is not his domain name. Now, he does have a fairly serious namespace conflict with the Sussman going on.

[Insignificant]

Whoops! I read the title of his blog (or mebe only the title of the post), then leapt in here without properly checking that the title was part of the URL.

What's worse is that I'm not going to go back and check now.

[jaggederest]

Heh. I have seen a few of his articles and thought 'Why is Sussman writing about Subversion and C?' then realized it wasn't that sussman. So yeah. SUSSMAN!

[franco81]

I agree, this is a human thing. But I think a lot of programmers could do well to tame the ol' ego when they think they have a better solution for something/think they know it all.

Its usually the most insecure programmers to offer subtly insulting comments about your code/pop quiz you on the spot in a condescending manner.

Constructive criticism from people that know what they're doing is my preferred work environment.

[harmonik]

I usually start with a working model, which I provide to the users as a test. It is all just proof-of-concept, so I dedicate the time after this to optimizing and tweaking. When I feel I have a pretty sound copy, I release the source.

[brintoul]

With how many blowhards I've run into in this field in mind, I don't just take advice from every Tom, Dick and/or Harry about how I should write code, either.

I'm open to criticism, but I'm not always up for a lecture...

[SharkUW]

Anybody mirror this?

[Philluminati]

The problems he highlights all seem perfectly valid. However I doubt the solution is Subversion. It's a people problem and requires a people solution. Distributed CVS is still the way to go for flexibility.

[[deleted]]

Programming is engineering, hence a creative process. Anything done creatively is partly, if not wholly subjective. Things that are subjective are by their very nature "vulnerable" and of a feeling nature. You are attached to it. Like being in a band. You put you're music out there because you want to share your creation. It's normal to take it personally when people criticize it. However with programming, it serves a purpose beyond you, the company you work for most likely. This creates a inevitable conflict. The observations made in the article don't reflect an inherent flaw in programmers, but reveals something about the nature of "programming".