4 ms·

Programmer Insecurity

57 points by mqt 18y ago

Hexstream 18y ago
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.
luckystrike 18y ago
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.
pavelludiq 18y ago
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
extantproject 18y ago
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/0596527055/ref=pd_bbs_2?ie=UTF8&s=books&qid=1213356181&sr=8-2 http://www.amazon.com/Myths-Innovation-Scott-Berkun/dp/05965...
- thaumaturgy 18y ago
  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.)
Tichy 18y ago
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 18y ago
  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.
- bsaunder 18y ago
  I think in our domain (software), there may be some additional rational to keeping things secret. An unpolished early revision of code may be a much better way to judge a job applicant than a resume. No one would consider publishing the rough draft of their resume. The appropriate counter argument (IMHO), is that "unpolished" is different than "poorly written", and you generally don't want to work with managers that can't comprehend and appreciate the difference.
- eugenejen 18y ago
  A counter example by Paul Graham from "Six Principles for Making New Things". "Here it is: I like to find (a) simple solutions (b) to overlooked problems (c) that actually need to be solved, and (d) deliver them as informally as possible, (e) starting with a very crude version 1, then (f) iterating rapidly."
edw519 18y ago
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 18y ago
  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 18y ago
    "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.
GrandMasterBirt 18y ago
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 18y ago
  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 18y ago
    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.
msg 18y ago
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.

57 points by mqt 18y ago

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.

luckystrike 18y ago

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.

pavelludiq 18y ago

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

extantproject 18y ago

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/0596527055/ref=pd_bbs_2?ie=UTF8&s=books&qid=1213356181&sr=8-2 http://www.amazon.com/Myths-Innovation-Scott-Berkun/dp/05965...

thaumaturgy 18y ago
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.)

Tichy 18y ago

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 18y ago
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.
bsaunder 18y ago
I think in our domain (software), there may be some additional rational to keeping things secret. An unpolished early revision of code may be a much better way to judge a job applicant than a resume. No one would consider publishing the rough draft of their resume. The appropriate counter argument (IMHO), is that "unpolished" is different than "poorly written", and you generally don't want to work with managers that can't comprehend and appreciate the difference.
eugenejen 18y ago
A counter example by Paul Graham from "Six Principles for Making New Things". "Here it is: I like to find (a) simple solutions (b) to overlooked problems (c) that actually need to be solved, and (d) deliver them as informally as possible, (e) starting with a very crude version 1, then (f) iterating rapidly."

edw519 18y ago

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 18y ago
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 18y ago
  "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.

GrandMasterBirt 18y ago

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 18y ago
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 18y ago
  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.

msg 18y ago

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.