
Programmer Insecurity - mqt
http://blog.red-bean.com/sussman/?p=96
======
extantproject
I hadn't thought of programming this way but it rings true. Call it the
"genius complex" or "hacker complex": wanting to create something great alone
and in a short timeframe then "unveil" it and bask in praise from peers.
Unfortunately for self-approved geniuses and hackers, great things are built
incrementally.

"The Myths of Innovation" by Scott Berkun has something to say along these
lines but in general terms rather than in terms of programming. Check it out:

[http://www.amazon.com/Myths-Innovation-Scott-
Berkun/dp/05965...](http://www.amazon.com/Myths-Innovation-Scott-
Berkun/dp/0596527055/ref=pd_bbs_2?ie=UTF8&s=books&qid=1213356181&sr=8-2)

~~~
thaumaturgy
I agree that projects are best developed and released incrementally, but I
don't see that as being the same as releasing unfinished code, or code which
otherwise doesn't meet the developer's own expectations of fitness.

I read the article, and he makes good points, but he was also concentrating on
a specific subset of software development, and I don't think the principles
apply equally well to individual projects or projects developed by small
teams.

Also, it glosses over the reasons that we all developed those habits in the
first place: the software development community is notoriously acerbic.
Although most of the time nobody may care about your unfinished code,
eventually you'll post something, somewhere, that will elicit an ugly response
that could have been avoided if you'd just rolled out something a little more
polished. (See also: the OpenBSD development community.)

------
luckystrike

      Be transparent. Share your work constantly. Solicit feedback. Appreciate critiques. Let other people point out your mistakes.
    

I agree with this fundamental thought expressed in the post.

But sometimes making the decision of 'when' to open source your code, does
also have to take in to account the 'community acceptance' factor. If the code
is of not that great a quality, it can put off potential key contributors, and
actually wrongly tag that product with a hard to get rid of 'below average'
kind of label.

Of course, once its out, or if someone is contributing to an existing open
source project, throwing 'code-bombs' isn't a great idea at all.

------
Tichy
On the other hand, most artists like to keep their work secret untill it has
reached a certain level of readiness, or am I mistaken? Unfinished paintings,
books, poems...

~~~
pm
It's a natural reaction for any creative to keep their work under wraps until
it's ready, but ready is relative to the medium (and the creator).

Having worked professionally as an illustrator before becoming a programmer, I
can confidently argue most illustrations don't look close to complete until
you've laid down 95% of the paint. If you've worked all week on an
illustration, and it doesn't meet your expectations, more often than not you
need to begin with a clean canvas.

Code, on the other hand, can be functional in as little as one line.
Functionality can be built upon that, and you can refactor code more often
than not without destroying the functionality that relies upon it. Code is an
infinitely more flexible medium.

The impulse to shelter your work from critical eyes is powerful, but
"unsightly" work can be altered at the drop of a hat. Perhaps programmers need
to be a little more open.

------
Hexstream
I'm better at realizing most of my code is shit than I am at producing great
code so I'm hesitant to share because that could "promote" bad programming and
people might be misled about my taste. That also means I don't need reviews
that much, I'm already busy improving my skills/codebase for things I know are
sucky.

------
msg
I work on a small team with a large legacy codebase in ClearCase. Builds take
long enough that it is easier to work on a large chunk and do a clean build
once the couple of libraries and executables I'm working on are in good shape,
then deliver the blob.

I check-in on my own branch on a feature-by-feature basis, but in practice, no
one sees my work until a large blob is out there. There's limited opportunity
to second guess people (this cycle, we had one formal code review per
developer).

At my work I am just stuck with these limitations, but I don't recommend
working this way.

------
edw519
I understand about not wanting to share code in progress. Even though there
are 427 coding methodologies, each of us still wants to work in our own style.
Chances are likely the _someone_ won't understand what we're doing even if we
do. If I want feedback, I'll ask when I'm ready.

Finished code. OTOH, is a totally different animal. Not wanting your code to
be peer reviewed is indeed insecure, stupid, and in many commercial shops, a
violation of protocol. Only a fool expects no feedback.

Junior Programmer: "I'm not sure it's right."

Mediocre Programmer: "It's not right until I say so."

Good Programmer: "It's not right until _you_ say so."

~~~
fendale
This is something I can relate to very well - I work for a large company that
out sources lots of work to India - some of the developers are good, some
terrible (as they are everywhere) - but without fail they refuse to show you
anything until its all done. There are at least two problems with this:

* Often they make poor implementation decisions that as the 'designer' (I hate branding myself with that term) I don't like and know it could be done a different way, but now that X weeks of development work have been done, its too late to change it.

* Reviewing a big blob of code like that is a nightmare - easier if I get drip fed it feature by feature. Also, often when reviewing code I have noticed a junior developer will use the same anti-pattern over and over again - so they have to refactor all through the code - if such an error was noticed early, it would have resulted in much less work overall.

~~~
edw519
"Often they make poor implementation decisions"

Are they coding to a spec? If you're outsourcing you better be or you're just
asking for trouble.

"Reviewing a big blob of code like that is a nightmare"

Right. That's why "big blobs of code" are _never_ acceptable. Use whatever
strategy you want: structured code, object orientation, reuseable components,
etc., but use _something_.

The problem isn't outsourcing. And it isn't lack of incremental reviews. The
problem is in standards, methodologies, and project management. You'd think a
"large company" would know better.

~~~
jimbokun
"Are they coding to a spec?"

A spec is a description of the expected behavior of the program, NOT a
description of what the code will look like. Unless we have a different
conception of "spec"?

If you are specifying the entire, detailed "design" upfront, you are not
allowing for Hacking as a valid methodology (specifically, Bottom Up
Programming). As we are discussing this on "Hacker News," I'm not sure we want
to discredit Hacking as a valid model for software development.

"And it isn't lack of incremental reviews."

Aren't incremental reviews a valid part of project managemnt and software
methodology?

~~~
etal
For a couple of projects weren't particularly big, we required this set of
"specs" before release (for internal use):

\- Requirements specification

\- Design specification

\- Use cases

\- Test plan

Plus some reports. The design included a functional specification, but all of
these documents evolved iteratively, so as it turned out the design document
was mostly an after-the-fact record of what we did. But I don't think anyone
here is an avid supporter of BDUF, so what else can a team do to prevent
foolish code, other than requiring everyone to show their stuff and explain
themselves regularly? If your up-front specification is comprehensive enough
to prevent any bad future programming decisions, you don't need a programming
team to implement it, you just need a compiler for it.

Maybe that's the deep secret to "Worse is Better": bad ideas are exposed to
the harsh glare of other developers early on, but it doesn't sting so bad
because nobody expected perfection. Humble is better.

------
GrandMasterBirt
I always felt that if I can't put my code to others' scrutiny and live with
the fact that it has errors and be glad that others spent THEIR time to help
ME find problems, then I am a pretty crappy programmer. After all I can't
expect myself to be the omnipotent programmer who writes perfect code.

Edit: I always felt that if someone did not look at some code and find a
problem with it, they just didn't look hard enough :)

~~~
jimbokun
I think I would feel I was making other programmers do too much of my work if
I just sent them code that I new was bad, and have them waste time to look at
it and just confirm that, yes, it's bad.

That's different, of course, from making your best effort and then asking
someone who you think is good at programming to find all the places you could
do better.

~~~
GrandMasterBirt
My friend's company has a policy: Everyone gets code reviews all the time by
peers.

The benefit is, the reviewer gets to learn a different part of the system, and
the person getting reviewed gets his code scrutinized. It is a very beneficial
system.

As far as showing bad code: There is a different between delivering crap and
delivering code you are satisfied with. If you are satisfied with it, thats
when scrutiny is necessary. You need to get a feel for when the code is good
enough, because you can spend all your life making it just a bit better. Same
kind of stuff applies to artists, you just need to know when to stop improving
and start letting others scrutinize the work.

------
pavelludiq
I once posted allot of code from my misc directory and it was just generally
useless code, some of it was just unfinished, and some of it wasn't supposed
to do anything so it couldn't be finished and some of the code worked, though
most of it was just some stuff i wrote as fast as i could type and not even
run it later to see if it works. Like some form of instant poetic inspiration
witch you might write down or record in a dictaphone on the street but not
publish it in a book or even read it to your friends. I have a lot of those
and i am not afraid to share them just for the fun of it. I also share my not
useless code(witch isn't much). I also wrote one of my school exams in python
and showed it to some friends(i think it was a biology exam or something) :D

