I’ve been noticing that often times, when getting or giving feedback on code, or browsing my favorite programming forum, or just reading posts about programming, that people often get very emotional about their code. I was wondering why this is, and because I am not a psychologist, I’ll just give you my thoughts.
Coding to me is like creating art, and there’s a great quote that backs me up on this:
Programming is an art form that fights back. —Unknown
Because code is like art, I get very attached to my code, as well as my style of coding. My code is like my baby, my something from nothing that wouldn’t be there if it weren’t for me. It’s just a bunch of characters on the screen that, from somewhere in the blue smoke, creates a function, or a game, or a website. I have received criticism on my code (as everyone has), as well as given criticism on other’s code (as everyone has), and those times when I’ve received criticism on my code, depending on how it was delivered, or what was said, it was almost like a personal attack on me. And I’ve noticed a few other coders react the same way to criticisms on their code. It’s like the person who called your code ugly or inelegant was saying that your child was ugly (and those of you who have kids know… that’s a huge no-no, punishable by any means available).
It may be because I think that my coding style is the best, it’s what I’m used to, and it’s the format I use because it’s the easiest for me to get at the information I need as fast as possible. I know this because I’ve tried other styles (sometimes flipping back and forth in the same day), and looking at someone else’s code that uses a different style from me, is often times hard to peruse easily. It’s what I like, and sometimes I have to hold myself back from reformatting code I come across into my own style.
So maybe we should stop thinking of code and coding styles as being “right” or “wrong”, and think of them more like the tool that they are, a means to an end. And the way you react to someone else’s means should be a little more like a suggestion for a different method of painting. Not a matter of fact, but just another tool for the tool box.
To continue the art analogy, it’s like everybody is given all the art supplies in the world, and told to make/paint/draw/create a box. Everyone will come up with a different way of doing it, some will be huge and bright red; others will be small and drawn in pencil; others still might be made of clay or brick. No matter what, it’s the way you chose to do it, and it’s no better or worse than the person’s next to you. You might think so because yours was faster, fancier, more elegant, or more “boxy”; but they might think the opposite. In the end, you still have a box, and so do they.
Tags: Coding, coding style
I’ve definitely had the urge to reformat other people’s code before. The times I resist are when it’s different, but not necessarily “bad”. There’s definitely some gray area when it comes to defining the best practices and standards, but so long as the code is well organized and getting the job done correctly, I usually leave it be.
However (and as long as we’re using analogies), you could also compare coding to climbing a mountain. There are lots of different ways to get to the top of a mountain, but there are definitely more efficient ways. You could scale up the steep backside with an ice pick and a machete, or you could take the paved cutbacks that scale up the front. You both get to the top of the mountain, but the coder who adheres to standards, uses frameworks, etc. will be halfway up the next mountain before the other guy ever reaches the summit.
I am not a coder but I thought this analysis was very well stated because it applies to almost any field where there is creation. There is a maturity that comes with the understanding that different is not necessarily “wrong”. Especially in our field of web development where a client may want something designed a certain way and our experience tells us that it may not fly as well that way, ultimately we are obliged to give our client what they want. In the end, if our client is happy with what we built, we have succeeded and that client will more than likely work with us again when he learns through his own experience that we knew what we were talking about from the get go (but we didn’t force the issue) and he is now ready to do it another way. Thanks Benjam!
@Mike- I agree, there are more efficient ways of doing things. The point I was trying to make was that, while someone might be doing things in an inefficient manner, they are no less valid if it gets the job done. If that person is a new programmer, they might not know all the tricks you do. And instead of just dismissing the code as garbage, it would be better to offer suggestions, and do it in a way that doesn’t offend the other programmer or hurt their feelings.
To use your mountain analogy, that other person is trying to climb a mountain, and it helps no one to walk past on the paved path and yell down “You’re never going to make it.”
Throw them a rope.
Well said Benjam… and I very much appreciate all the ropes you’ve thrown and will surely throw my way again.
@Mike- Nobody ever said I was holding on to the other end… ;)