views:

454

answers:

21

One colleague compared programming to the clay molding process - first you define rough shape of the mass, then carve smaller and smaller details. What's Your take on programming, which metaphor would you use to describe programmer's work?

+4  A: 

"Engineer".

I get an order, build something new, test it, then release it to a customer for money.

Andrew Keith
+2  A: 

Architecture.

I call myself an information architect - trying to mould the current environment (in my case chemical information) into something usable. It involves design, engineering and working closely with people.

The result must be usable and ind my case must be re-usable. Its shape is unliekly to be clear at the start. It also depends on how the world develops during the time of the work. In my case it is never finished but we build (hopefully usable) things along the way.

peter.murray.rust
+1  A: 

Clay molding is actually a very good description i think, though for me i'd use cooking. You start with a recipe (or maybe just a vague idea) then get some ingredients, mix together, cook, do other things to them, and see if it worked. Depending on how well you then have something you can tweak for another run at the same problem, or maybe a finished solution with only a couple rough edges.

RCIX
+5  A: 

"Gardening" - your code base grows and grows but without careful weeding and care. It becomes an unmanageable mess.

John Nolan
In gardening, stuff grows by itself.
Pavel Shved
In bad gardening.
Stefano Borini
So does code, as long as you keep it well fertilized, and keep the pests away. Haven't you ever come across a bit of code and wondered "Who wrote that!!?"
Breton
You seem to misunderstand me. In programming, if noone writes the code, you can be *sure* that it won't grow.
Pavel Shved
And yet the code seems to attract bugs over time...
Lasse V. Karlsen
Your code doesn't grow? Maybe you've just planted your code is some clay, or perhaps someone has salted the repository? I usually spend most of my time deleting code, there's too much of it usually. Writing more would just add to the problem. Yep, this analogy is flawless.
Breton
@Lasse: except in gardening, it's the good plants and beautiful flowers that attract the bugs, not the unmanageable mess of weeds.
DisgruntledGoat
+2  A: 

Plate spinning: trying to get a whole lot of things working at once without letting any of them drop....

Tim
+5  A: 

"Dr. Frankenstein"

We, the programmers, are actually crazy people who give life to these cold pieces of metal, silicon and plastic. After we set a couple of experiments, involving some metaphysical work, these pieces begin to talk to people, to communicate over the network, learn how to wake up and sleep, to learn and forget, to emerge out of a CD and to die.

And it's we who make them do it.

Pavel Shved
... and one day, out creations will kill us.
Martin Hohenberg
+2  A: 

I'd say it's like building a house. You establish a plan, a rough idea of what you need. Then overtime you develop a more refined plan. Slowly tou piece it all together and start building the house. There are little problems along the way, but you can usually deal with them. Finally after all your hardwork you have a house people can live in and use.

Monty Python and the Holy Grail

When I started here, all there was was swamp. Other kings said I was daft to build a castle on a swamp, but I built it all the same, just to show 'em. It sank into the swamp. So, I built a second one. That sank into the swamp. So, I built a third one. That burned down, fell over, then sank into the swamp, but the fourth one... stayed up! And that's what you're gonna get, lad: the strongest castle in these islands. --

Dominic Bou-Samra
And occasionally (actually more often than not i bet) you end up with a crazy mess that no one thought you would get...
RCIX
+2  A: 

Writing

Here are the steps to the writing process (seem familiar?):

  • Pre-writing / Drafting
  • Writing
  • Sharing / Responding
  • Revising
  • Editing
  • Evaluating
Even Mien
+1  A: 

Creating software is like composing music for an orchestra. There's an overall conception, accomplished with a careful weaving of themes and rhythms. Musicians learn their individual parts, and collaborate under the leadership of their conductor.

Done well it sings and soars, energizing players and audience members alike.

Dave
A: 

If you consider your computer like the musical instrument, a program is like the melody that can make the same instrument plays differently everytime you play a new melody or tune, the programmer is the composer who spent nights and days chasing the right note in his melody.

bashmohandes
+1  A: 

Ceremonial magick -- "Magick is the Science and Art of causing Change to occur in conformity with Will." as Crowley put it.

Programming too is both science and art, and causes change through the expression of intent -- and just as in the normal understanding of ritual, you must be exact in your incantations (the story of Sorcerer's Apprentice is, of course, a familiar example of an infinite loop or unbounded recursion).

Steve Gilham
+23  A: 

Schitzophrenia. You spend a vast amount of time talking to and manipulating things that don't really exist outside of your head, and nobody believes you.

Or maybe it's like working in a factory full of robots, and one of the robots halts the whole factory floor to tell you that this bolt is entirely the wrong shape, size, and color, while showing you a dismembered thumb.

Or it's like if putting a decal on a car in slightly the wrong place would cause the engine to fall out.

Or it's like cooking dinner for someone who's obsessive compulsive. Really obsessive compulsive. like, you didn't follow the RECIPE. it asked for 250 grams of flour, and you clearly put in 251!

Or maybe it's like painting, that is, if you were painting blindfolded, and were only allowed to look at the thing you're working on once every 10 or so minutes, after some compilation stage, and even then, it might lock up your easel, forcing you to track down some paint leak, so you blot out half the painting with gray paint until you isolate the part of the composition that's exhibiting the... uhmm... scumbling behavior? and. .wait... no this is a good analogy I'm sure of it! Come back! PLEASE BELIEVE ME!!!

Breton
Who are you talking to? There's nobody here.
jleedev
+1  A: 

Daydreaming with rules. LEGO.

Jurily
A: 

"Driving Blind"

We are on the back sit, and the computer is the blind driver who has the control.
If our instructions are not precise, we're going to crush :-)

Nick D
+1  A: 

"Pulling human carriage over rough terrain"

One person is sitting in the carriage, and another is pulling it. Destination point is far ahead, and all their work would be for nothing if they can't achieve it. Carriage turns only when stopped, so they must travel in sprints, by maximizing the velocity and distance after every turn.

Sitting person (boss) spends all his time on planning the route and trying to consider all the possible suprises on the road. His mass (salary) slows down another person, and he can't talk much either, because carrier must concentrate on what he is doing. So sitter announces his decisions to turn only when there's an obsticle on the road.

Pulling person can be strong and smart at the same time, but he can't think and pull at the same time. So, when turning he must rely on decisions from sitting person. Thats why decisions come from someone who doesn't really know much about pulling carriage through rough terrains. And alone carrier could travel twice the distance, or make twice the amount of turns (mistakes) compared to travelling together. And putting sitting person to work doesn't help either, because he's not as strong as carrier.

Situation changes then there are multiple pulling and one sitting person. But even then it's hard to understand why sitting person should get the best salary of them all... that lazy fu%#head... (luckily I'm in the business of programming and not pulling carriages :))

AareP
A: 

I usually draw analogies to building structures/houses/buildings/cities, etc.

the levels of complexity scale nicely with the analogy.

Tim
A: 

Car driving

You start in point A and decide to take direction 1. the closer you get the less choices you have to get to point B. And if you've miscalculated yourself. you may run empty befor getting to point B. In that case you will build a gas station on the way to get you to point B or start anew with a different route.

Robert Koritnik
A: 

Software development is like golf. A very long shot to start the game approachs you near of the objective. Then, you need to start making a lot of short shots to get the ball into the hole, and all those short shots takes as much time as the first one...

My answer is more related to the whole software development process than the individual programming activity. I know it, but I think still a good analogy to think about it.

The concept come from this old post that is not longer online, buy was kept by the web archive, take a look at it: http://web.archive.org/web/20070629105558/http%3A//rc3.org/2007/04/how%5Fprogramming.php

JuanZe
+1  A: 

Programming is like being God with a very limited scope.

tsilb
A: 

"Jungle mess" - you start gardening one little tree and have plenty of time to water and take care of it. At some point there's an explosion of growth, tree becomes a jungle, and you find yourself lost in green mass of trees and plants. Your movement is obstructed and you can't control what happens anymore. Final output is this uncontrolled jungle mess, that takes hundreds of people to upkeep, and that sucks everybodies time and money. At some point lighting strikes, and to everybody's relief jungle burns down to the ground. Unfortunately there's always those naive new gardeners that are eager to start all over.

AareP
+1  A: 

Being an artist that nobody knows about. You can create crap or masterpieces, no one will know who you are. I've also heard it called "the most fun you can have with your pants on, although pants are not required."