How I Write Code:

1. Copy the smallest piece of code I've already written and change it slightly to do something really small. Get it working perfectly.

2. Add a little bit. Get it working perfectly.

3. Add a little bit more. Get it working perfectly.

4. Repeat until it's not so easy to add anything, even a little bit. Print a hard copy. Holy shit! Did I write all that?

5. Mark it up like crazy with a red pen. Combine similar code into common functions. Rename variables. Rename them again. Rename them again. Rename them to what they originally were, but without vowels. Restructure unwieldy functions. Rewrite the stuff I can't believe I actually wrote myself.

6. Sit down at terminal and enter changes. Save every version (even though I never look at it again). Get it to work perfectly (again). Holy shit! What did I do? It's totally broken! Debug, debug, debug. Good. Now it runs perfectly. Time to add more...go back to Step 1. (Except every 5th time through this loop: Scrap it all and rewrite it the way I should have in the first place.)

7. Repeat until dead.

My style is is a combination of both this and what is written in the article. I don't whats the best, but this seems to work for me !

Add in some 5 to 1, 2, and 3.

Does anyone else occasionally spend an unreasonable amount of time deciding how to name a variable ? :)

Selecting a variable name is actually very meaningful, and not just for maintainability reasons.

If you have difficulty naming a variable, it could be because you don't have a good grasp of either the problem or your solution, or concepts are conflated. It could be because you don't yet have a vocabulary that provides the terms you need -- imagine if you didn't have the words "result" or "set", but were trying to name a variable to hold the output of a query. It could be that your functions don't do just one thing.

It could even be because your language isn't expressive enough.

I can generally tell when I'm doing things 'right' because decomposing the problem into functions, naming them, and composing them into a solution is easy: it feels like I'm cutting with the grain, not against it.

In this way, coding is like writing a speech or a poem. Deliberating on precisely the right words to use is a key part of the process, and the better your grip on the domain and your arguments, the easier it is to find the words.

Your question may infer more than you may have meant.

Yes, I occasionally spend an unreasonable amount of time deciding how to name a variable.

But what is "unreasonable". If 30 minutes of agonizing over a name (and a standard) saves me 6 hours of debugging next month, was it really unreasonable?

At a certain point, if it's that hard for me to reason about naming something, I like to step back and make sure I'm thinking about the problem at hand the right way.

Of course, I don't work on very hard problems, so I'm sure that's different for everyone.

Elegance was the last thing on my mind. I was referring to maintainability.

Elegance of the code typically implies its maintainability. Not every maintainable code is elegant though :)

Yes, last week I spend a lot of time to decide what name to use for a method and some vars. The bad thing is that I was extending the system and the existing names for related methods where... wrong.

Yes, when I'm programming alone, which is a microcosm example of why I really like pair programming.

Oh God yes.

When I am at my desk making something out of bottlecaps, business cards and spent NERF rounds and someone asks me what I'm doing, I tell them "I'm developing software. I'll type it in later."

It's amusing because I don't write like this at all. Instead, I sit in front of my computer and refactor until I'm satisfied with the result.

I write code by analyzing requirements and then breaking them into a series of milestones and attaching requirements to each milestone. I show the client how I have interpreted their requirements and make sure we are in sync. I then delegate as much non-core work as possible to others. I tend to separate the functional and visual aspects of each milestone.

Regarding the ordering of milestones, where there is some discretion available I tend to do things that will keep the client happy. The objective is to deliver the project on time with the minimum level of stress for all involved.

I don't lie about in bed dreaming about imaginary packets.

I sketch stuff in a notebook (a whiteboard is better, when I have the luxury). If I'm doing graphical stuff (e.g. UI), it's mainly crude layout and interaction diagrams. If it's something more logic, I try and describe the high level view, then informally break it down.

Either way, at some point, I find a good place to start hacking and I feel the urge to say it in code (mainly Python, currently).

When coding, I start by doing the smallest thing that I can run and verify in some way. I keep adding stuff in small increments. I only get back at the notebook when I can't think of, or decide, what to do next.

Usually I first get a high level model working either in my head or on paper/whiteboard. I don't really care about the details, is more a general idea of the algorithm (iterative? recursive?), data access (I will need this, go to a cache or database?) and fitting it in the current environment.

Then I start working to code it. I start with the main functionality, I wrote it as I want it to be inventing the required methods. When I'm happy with it I code the required extra-methods. Write tests for them. Write tests for the main functionality. When it works as excepted, a couple iterations of reviewing and re-factoring.

I'm not sure about the details about how I code the methods, it seems I'm so focused doing it I cannot recall the how. (I guess many of us have the sensation of "OMG! How I did it?" or seeing we've wrote much more code than we thought).

I usually sit down and write something right away. As soon as I get stuck, then I think without coding, so to speak.

The unfortunate byproduct of this is that my code ends up looking very confusing, even to me, and I have to do some major cleanup on it before I let anyone else look at it.

at work I read hacker news until something clicks... kindof like staring our a window ;)

at home I just swear at my computer until things work the way I want them to.

I bet he tell good code from across the room as well.

Sounds like this guy likes to smoke some reefer before he codes. I highly recommend that strategy.