

How I Write Code - BigZaphod
http://blog.bigzaphod.org/2009/05/27/how-i-write-code/

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

~~~
edw519
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?

~~~
huhtenberg
> Your question may infer more than you may have meant.

Of course, it does. It is a simpler version of "Do you care enough to write
_elegant_ code ?".

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

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

------
jimfl
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."

------
vorador
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.

------
cosmo7
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.

------
euccastro
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.

------
edu
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).

------
javanix
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.

------
erikwiffin
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.

------
edw519
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.

~~~
vinutheraj
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 !

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

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

