Writing code with pencil and paper (2022) | Hacker News Reader

Writing code with pencil and paper (2022)

css-tricks.com

164 pointsraytopia93 comments

I only use pen and paper for sketching diagrams and graphical relationships between things. This is probably the main use for paper & whiteboards - they are MUCH cheaper than their digital equivalents for drawing regardless of size.

Writing out pseudocode on paper is… okay… although not my preference. It’s okay if you get stuck and want a context switch.

Writing out syntactically correct code, including commands like “sudo” on paper on the other hand is an enormous waste of one’s own time. God help this man if he ever takes up Java programming. Just type actual computer code like this on computers so you can run it and see if it works. Then if it doesn’t you can just use backspace instead of an eraser.

So while I'm not going to disagree that writing with pen and paper can be a valuable exercise, the assertion that it's inevitable is utterly false. I am far more effective in sketching out my code design in an IDE than I am on paper, and never in my professional career of 23 years have I had to write out code in pen and paper for a job interview, or even in the job.

Any discussion of handwritten code is incomplete without mentioning Edsger Dijkstra's approach, demonstrated in this beautiful interview: https://youtu.be/mLEOZO1GwVc?t=246

I'm surprised no one has mentioned it here yet.

What a great watch, thanks for sharing. I liked his metaphor of music and transcription to programming. Writing of music is not the main function of a musician in the way that writing programs is not main function of a programmer.

Nice!

However i fear his message is lost on the young'uns today (witness the comments in this thread :-). As he says in this interview, while the trivial/easy parts of programming have been automated (using IDEs/tools etc.) the hard parts will always remain and that is where thought and rigour are needed. This is where paper and pen/pencil reign supreme. They engage the whole mind and body to focus on one single task in a totally natural and free manner.

Mozart programming versus Beethoven programming

> If you’re unsure, think about the last job interview you did, and remember how there was no computer around in the interview room — just your interviewers, a blank sheet of paper, and a blue ball-point pen.

I haven't had an interview like this in about 10 years

5 years for me, but yeah live coding is always done on a screen these days. I mean

- whiteboard / paper is just so slow

- extremely poor editing functionality on whiteboard / paper

- some people's handwriting is not legible

Yeah, I struggle to read my own handwriting sometimes. If an interviewer would require len and paper it would be ... interesting.

Also unrealistic and non sensical exercise. Feels like it would be much easier to bs as well. When you have actual compiler and tests, try to bs that.

I'm trying to think... I've had about 30 contracts and a lot more interviews than that.

The only one I remember that involved a sheet of paper was 20 printed pages of code which I had to find the bugs in. And that was actually quite a fun exercise. (I did apparently find more bugs than most, I also subsequently found some bugs in their contract and NDA.)

I had one a few weeks back like this.

It was a strong signal I didn't want to work there.

There were even stronger signals that followed. It was by far my worst interview ever, I haven't really gotten over it yet.

It even caused me to sign up to glassdoor just so I could leave a negative review.

Had a couple like that, the relief from not ever having to work with those people lasted longer than the trauma from the interview. Look on the bright side, at least you didn't get the job!

Yeah the last job interview I did was me and two other developers on a zoom meeting, with me sharing my screen while I typed out puzzle solutions in codepen.io

I can’t even think of the last time I did an interview without a computer in the room.

Really not sure this is relevant to me.

When I was learning to code, I didn't have a computer of my own. So I wrote the code out on paper. This worked because fundamentally, it's a way to communicate ideas in a way that is generally unambiguous and precise. It's rare these days, but something like the act of moving a pencil/pen over the hand written code and working through the state can be helpful at times too.

Same. I could only access computer at university, so I wrote programs at home and then just typed them in when I got access.

Me too. I would write out a basic program on lined paper at school, and then when I visited my brother I would type it in to his Ohio Scientific Challenger 2p:

https://www.vintagecomputer.net/browse_thread.cfm?id=372

I remember the moment it clicked that "if statements.. strings... I can make a text adventure!"

It feels like that experience helped me develop, but on the other hand, don't we all think that about most of the hardships we experienced when young? It's hard to know for sure.

Its amazing how useful it is to slow down and just write out some problem with pen(cil) and paper. This has help me get unstuck form some bad habits after year of speeding past them.

I couldn't disagree more.

If you're finding yourself reaching for pen and paper to write actual code, then your tooling sucks.

Your IDE isn't suitable for prototyping, or something else is going wrong.

I'm not suggesting that nothing in the planning phase should be white-boarded, but pen is the wrong medium for code.

You should have a tool where you can fire up your tooling and be writing the same thing you would write on paper, but with autocompletion, error feedback and browsable interactive output.

In my experience that's far more appropriate an environment for rapidly getting something down and working through the problem.

By all means, start with pen and paper to get a feel for the problem domain, but that process should stop short of actual code, and this article doesn't really sell me on the benefits.

I'd rather test my assumptions in something like LinqPad, where I'll get real feedback not just a "feeling" about what I've written.

I don’t know if it’s from Calm Technology, but here something that i read about recently: Don’t make humans act like a computer and don’t make the computer act like a human.

The first part is something I believe in this case. It’s ok to think with pen and paper (and I do when trying to find an algorithm) But I stop short of implementation details, instead typing out code. Why? Because text editors is much more flexible in this particular case (live programming environment, REPLs, or a quick code-compile-run cycle are much more useful)

And the second part is why I don’t like LLMs for code generation. Snippets are more deterministic. I’m ok with it for suggestions of ideas I can explore (in books, not with the LLM)

If you're finding yourself reaching for pen and paper to write actual code, then your tooling sucks.

Or maybe it's horses for courses?

Personally I found the idea of going beyond prototyping on paper as a rule not for me, though there are sometimes final snippets reveal themselves better away from the screen when I'm stuck in the mud on something.

My point is though that we really ought to allow others to find their own way and what is best for them rather than dismissing it so emphatically because we don't personally get it.

You can take as read that all my posts are prefixed with "In my opinion". I find it unnecessary to type that out on every post.

Taking a format that only a computer can interpret, code, and choosing to write it down on a medium a computer can't read, hand-writing, is not typically a productive exercise.

Even in interviews I'd rather hand a candidate a laptop.

There are more worthwhile things to hand-write, such as sequence diagrams, and there are more worthwhile places to write code, such as an IDE.

If someone is finding it easier to write code on paper than in an IDE, I'd rather not ignore that signal and try to discover why their IDE is proving such an impediment.

Maybe it takes 10 minutes to start up, maybe it throws up so many errors for each syntax mistake that it's distracting and hard to see the wood for the trees. Maybe it doesn't actually produce useful output. Maybe it doesn't have real time debugging and step-through.

Who knows, but something is causing it to be mentally easier to write down the same code on paper than the IDE, and that's not something that should be ignored, that's something that should be fixed.

I personally tend to think better when I'm away from the computer.

Coding on the IDE helps me to experiment and quickly put something together that works.

But thinking while writing things down or while walking is a slower process, so it helps me focus on nothing but the problem obvious edge cases, different solution designs, etc...

So by thinking about the code away from the IDE first, then by polishing my ideas on the IDE, I usually end up with higher quality code.

But since it's less fun to do things that way, I just tend to do everything on my IDE.

You can take as read that all my posts are prefixed with "In my opinion". I find it unnecessary to type that out on every post.

Its obviously a given - except where people are commenting in a way that indicates they are expressing the one true way, as you did, and have done again.

The OP's way is not for me, but I'm ok with it being for them.

I agree that if there is a problem in their process or workflow that is influencing an inferior (for them) approach it is better to try to help them fix it.

> If someone is finding it easier to write code on paper than in an IDE,

The post isn't about writing code on paper, but about the planing and ideas collection before writing effective code.

> write down the same code on paper than the IDE,

No, pseudo-code and notes and flowcharts aren't the code (maybe the later on some visual language environment.) You're missing the whole point, sorry.

You haven't mentioned pseudocode ?

Pseudocode isn't coding, but sufficiently advanced pseudocode is indistinguishable from Python.

Regardless, I don't see why the parent would have necessarily mentioned pseudocode for any reason?

Because that's a huge part of what the article talks about ?

(Also, even Python is at more risk of funneling you in some direction that might be suboptimal, at least more than pseudocode.)

Oddly, for me the feedback of the computer is too fast for thinking. I like being able to write a bit before thinking about some details.

More, I find that forcing myself to run the code in my head is a good idea.

That all said, I don't do the paper thing often. Really only when thinking at a level other than the symbolic of text. Some system diagrams. Sometimes numeric. I suspect if I got good at Mathematica, I'd do more numeric thinking there.

Honestly, if anything I'm trying to do is sufficiently complex, I reach for pen and paper and use drawings, abstract ideas to have a better idea of what I'm going to code.

Actually, this way you catch a lot of poor design decisions that you would otherwise fall into. If starting out with code, I might attempt to "fix" poor design through hacks due to the "sunk time fallacy" of code already written, that kinda works, but isn't maintainable.

Honestly, no "tool" on a computer would let me print my imagination as easily as pen and paper. Perhaps a drawing tablet, but that's an additional thing I would need to plug into my PC.

> If you're finding yourself reaching for pen and paper to write actual code, then your tooling sucks.

Oh bull. At the level of thinking where you’d pull out pen and paper, ALL digital tooling sucks. Not one single solitary tool can beat pen and paper at that level. Not one.

Rather than "bull", I suspect we're already in agreement, given your statement, "At the level of thinking where you’d pull out pen and paper".

We appear to agree there's a place for pen & paper, and we appear to agree that's a different level to coding implementation.

Writing down code, complete with correct syntax, parentheses, indentation, etc, as the article wants, is not in my opinion that level.

At that level, the tooling does not suck.

So yes, I agree, "At the level" where pen & paper shines it should be used.

That level is not writing correct code, unless you can convince me otherwise?

For myself by writing prototypic code correctly with pen; not only does it keep my vision straight, it also gives myself clarity and a sense of sanity of say, what that function does.

With the hard evidence you can then refer back to. So, when you are ready to expand your design you already have the foundation on page.

It acts as a pillar to the psuedo code that comes with design later on. If that is the going to be foundation to that function, it might as well be written correctly on paper.

This makes sense to me if the problem I'm solving simply devolves to code and I want as short a path as possible to completing it. I really don't see that much anymore, other than basic bug fixes.

Not every problem I'm solving is just a hunt for the code implementation. I like to reason about solutions beyond the syntax. I use pen and paper a lot, including for code, and I'll use shorthand to represent longer-form code blocks. I find that approach better because I can hide the noise that code blocks can introduce in an IDE. I want code to support my solution -- not a solution to fit into code. IDEs and frameworks can have that affect on people, in my experience.

As with this comment and the one preceding it, your mileage may vary.

It's like you and many people didn't read and understand the post.

> but pen is the wrong medium for code.

Pen & Paper is really excellent for many people, maybe not you but it's fine some others. You may use an electronic device (some people are using Remarkable and alikes) or chalk and black board, or MindMapping app; the key idea is to first forethink and analyse the problem before diving into coding.

> your tooling and be writing the same thing you would write on paper, but with autocompletion, error feedback and browsable interactive output.

What kind of tooling do you use for pseudo-code (not a real language, but textual informal prose) with that features?

I agree that there's not much point in writing actual literal semantically correct code on a piece of paper, but I don't think that's at all the point of the article. The author talks about understanding the problem space, getting their ideas organized, and (if I may charitably interpret the article a bit) even go as far as scratching out some ideas of what the code might look like.

I mean people are free to do that but the last time I had to was in 1985 and that's because I was programming a KIM-1 by typing in hex codes through the keypad and I didn't have any sort of terminal.

https://blog.jgc.org/2013/04/how-i-coded-in-1985.html

I did the same in 1979 on an Acorn System One. Couldn't afford colour pens though so didn't have syntax highlighting like you did.

When I was growing up, my family was too poor to afford any kind of computer. Finally, I built a computer from scrap parts but I could not run it because we could not afford electricity to run it.

For many years the only way I could program was pen and paper, and a bit later a Citizen SRP-175 programmable calculator with mind-blowing memory to run 128 instructions. I would go to a library, borrow a bunch of books some of which were programming, and knock myself out writing programs on paper that I could only ever "execute" in my mind.

If you have an old computer, there probably is a child who would give an arm and a leg to have a chance to have fun with it.

To each his own. I went the opposite route, now, I don't even have a pen and paper on my desk. I still carry a pen in my bag for signing documents and stuff, but I don't remember the last time I scribbled something on paper.

I usually take notes or lay my thought using a text editor, I find it easier to edit, manipulate, and store. I occasionally use a graphics tablet or my phone with a stylus when I need more than text (ex: drawing schematics), essentially like paper, but more editable and I can save it as a file.

But if you find that pen and paper works best for you, go for it. Maybe one reason I went the opposite route is that the author likes to think in advance before going for the implementation, that's a top down approach. Mine is very bottom up, I go straight to coding, sometime even before reading the specs. It feels like putting ideas into code makes me think more clearly. I can always scrap that code later, I often do, it is cheap when things are just getting started. And pen and paper is not really suitable for that kind of rapid prototyping.

I upvoted the "I couldn't disagree more"-post, but now I regret it (edit: oh, there's an "unvote" button). One can do a lot more with a pencil and a piece of paper than with a blank text entry. Drawing figures, arrows, etc. There is even undo, thanks to rubbers. But it sucks that one can not insert lines in between.

> that one can not insert lines in between

Ok, not easily.

The new writing tablets are good at this. Circle the text to move it. If you have a Wacom on your computer, very similar.

I recently saw Theo using https://excalidraw.com/ in one of his YouTube videos. I like that one.

Yeah, I meant stuff like the Remarkable. I have a Kindle Scribe. Amusingly, the scribe was not good at this at launch, but has gotten some good updates. My understanding is the Remarkable is head and shoulders better.

Sure, If you have bought something like this already, it can do you a good service.

Certainly, I wouldn't go buy one if you didn't want it already. I did the kindle as I was happy to have a large screen kindle. :D

The problem I have with a ton of computer based sketching tools, is that I just don't sketch with a mouse that well. And doing it with the keyboard is ridiculously difficult for me. The Wacom can mostly work, but it takes a ton of getting used to having the pen detached from what you are drawing. Easier than the mouse, but still hard.

I grew up drawing a lot and doing a lot of stuff on paper for thinking so it's natural for me to solve harder/more complex programming problems on paper before writing up the code. It helps me wrap my head around it.

I got blacklisted from an MNC in India because I was writing up the logic for the algorithm problem on paper and the camera flagged me as cheating on the coding test. Its weird cause since childhood we were forced to use pen and paper to solve math/physics/chemistry problems and now you get flagged on online tests for using it. I just cannot do the "thinking" part of the code with my keyboard and IDE.

If you have cameras on tests auto-flagging you, then you have much worse problems to deal with anyway...

During Christmas vacation while in college, I didn't have access to a computer. So I'd fill spiral notebooks with code.

Even in college, the computer was in the computer center. So in the dorm I'd still code in spiral notebooks, listening to ELP and Jethro Tull.

I kinda miss that a teensy bit.

I remember one Easter break (1987) spending a couple of weeks at my parents working through lambda calculus examples by hand - which was extremely laborious and used lots of paper but actually got me to really like the topic.

I'd argue it's even more valuable to learn to code without paper. Many of us formed habits of thinking with paper in school and freeze up a bit in front of the screen. I think it's better to work to eliminate that freezing up than to accommodate it.

I understand using paper for Diagrams and arquitechtual design, but for coding?

On college I remember having to code on paper and you simply can't test your code for typos or small error, even if your logic was perfect professor give you marks for a missing ';'

note: the class was evaluating the Logic / algorihtm not basic code syntax

In mentoring engineers I've found that some are doing what amounts to advanced pattern matching. They memorize the syntax for a for loop but never really internalize what it does (they just seem to know write these letters if you want things to repeat). Not dissimilar to what I suspect LLMs are doing when they generate code.

By contrast when I write code I see in my minds eye what the code should do, tinker with it, formulate an algorithm, and only then do I try to translate what's in my head into syntax.

When asked how people can learn this skill (or get better at algorithms in general) I always say they should practice writing code by hand.

I've seen the same tutoring math. It's tough to get through, as it's a learning style that got them this far. Of course, not they are needing tutoring, so it's stopped working.

How does writing code by hand fix this? They can still write the same things from the same understandings. I've had some luck having people explain things to me, without looking at the code/math.

The value is in getting them to write down what happens step by step as their program executes.

Writing things by hand can just help facilitate that because it removes the ability to run the program and get the final result.

People can lean on their tools to 'guess and check' their work. Write a loop, run the program, and get an out of bounds error. They'll have learned oh this error means I need to subtract one from my loop bounds. And sometimes that works, though many times, it means there's an edge case they didn't properly handle.

When you only have pencil and paper and you need to explain to me what your code does you have to write down a representation of what's in memory and then how it changes step by step as the code runs.

I would be way too impatient to write code like this. It is hard for me to imagine how anyone could do this. I guess I do not really get this, it almost feels to me like people want to be hipsterish a bit. But of course I am likely wrong.

I have no citation, but I’ve been told that writing something out by hand stimulates different parts of the brain, as does explaining that thing out loud.

The expressivity of pencil and paper are so much better than data input on a computer. It's great for creative thinking. Between humans, it's so much faster than anything that is intermediated by screens.

The main benefit is getting things generally straight in your head before committing to data entry into a tool or coding.

It's a false saving to spend days / weeks at a computer to save a few hours of design time.

It IS useful - for interviews. I have a whiteboard at home just for that. It's amazing how stressful it is to write code by hand without someone breathing down your neck.

Outside of that - life is short, and this is waste of it.

Last time someone try to interview me with a pen and paper, I walk the door laughing... It shows how little they know about the job, major red flag!

He doesn't seem to use pen and paper to actually write the code, more to design the algorithm and logic he wants to achieve instead.

I mostly work with a whiteboard and then photo and print out the board, and work from the paper to see if I can then make further refinements by writing on the board again, and so on and so on, until I feel like I understand the problem/solution and then get started working on the computer to code.

Agree it has its usefulness.

Job interviews with pen and paper are hardly a selling point for me, I had one 10years ago and still dreaded it. My 2 cents are, if a company hires you to work on a computer in X environment then that's what they should test you on - or as close to it as they can.

Due to having to share a small number of refrigerator size computers amongst all the programmers I started out writing assembler on coding forms by hand. The natural unit of what you can get done in 30 or 40 lines of assembler on one page was quite a good way of modularizing code into functions or subroutines as we called them.

Later when code was typed in at the terminal, I used a notebook and pencil to record bugs one per line which is still the best bug tracking system for initial development IMHO. Checkmark on the line when it is fixed, and capital T when it has been tested as fixed.

> If the thought of handwriting code seems silly, it might surprise you to know that it’s inevitable. If you’re unsure, think about the last job interview you did, and remember how there was no computer around in the interview room — just your interviewers, a blank sheet of paper, and a blue ball-point pen.

This was written in 2022??

Such a complete turnoff right off the bat, how out of touch do you have to be to write something like that? Maybe the author should have spent some time hand-writing their article first. /eyeroll

I can relate to this. IMO in the title there is a WHEN. Missing. If you are using pencil and paper every time (even for the 100th little API variation) you are doing too much planning haha

“If the thought of handwriting code seems silly, it might surprise you to know that it’s inevitable“

It doesn’t seem silly but saying it’s inevitable does seem silly…

I do not remember the last time I or someone else has had an in-person interview; saying impossible would have been more accurate than saying inevitable

However, I do see this being possible and beneficial for students who are at the whims of the professor and if the professor prefers the old-fashioned approach; you will end up writing some logic by hand

I "write"code in my head. On walks/runs. In the shower. At the gym. Mostly at the keyboard but for hard problems, I benefit from stepping away from it.

This is why I keep a dry-erase in the shower next to the soap-on-a-rope.

I can use the tub surround as a white board for my "ah-ha!" shower moments.

You're probably joking, I don't know, but I am now thinking about doing this.

I can see the book title now "Naked Programming" LOL

I haven’t done this a single time in my life and I’ve interviewed for no less than 25 positions.

Throwback to my Functional Programming course during Uni years. Writing OCaml code on paper wasn't fun. I think it helped to cement some concepts, but the extent of said help it's not clear to me. In fact, I also believe the same could have been achieved using a text editor.

I write Haskell on paper all the time! Especially very type-oriented stuff. When you get that all looking good, usually the actual implementation is trivial. You just black out and build it without thinking. Because the design was so provably good on paper in types.

I can see this for Haskell. It probably ends up looking like a math exercise problem.

A friend of mine, in the 80s, wrote machine code on paper (calculating offsets in his head) having memorized all op codes, and drawing the graphics for a game for a Sharp MZ-800.

I always admired his patience and skills, me using an assembler on an Amstrad to write my games.

I think better in pen and paper somehow. I don't know why. Whenever I need some serious thinking and designing, I reach out to paper and pen. My brain just wire differently on keyboard. I'm surprised to learn many feel differently

Pencil? you can easily Ctrl-Z.

nah, wanna go old-school, use inkwell pen, or better still feather + ink for hard-core hackers! focuses the mind, you've gotta know your grammar, syntax etcetera. non of that autocomplete sorcery for me

I think it is crucial to learn how to code with pen and paper. All computerization adds a mental burden, that shouldn't be there. Also this is a nice way to connect computer science with mathematics.

I disagree. All code is useless without computers. We should use every single tool that can boost our efficiency and allow us to make less errors. Copilot, autocomplete, intelisense, etc… It’s a waste of your time and you will write worse code if you just use pen and paper. Guaranteed.

Agreed. The faster you implement and correct the better it becomes. It's quite improbable that you'll catch a logical error in writing and not catch it while coding it up. It's also quite unlikely that a sketch of your plan will help you more than a debugger will.

I disagree, if you get into this habit, you risk missing the forest for the trees, which is much more dangerous : for instance that you should have used a different programming paradigm, a different programming language, a completely different approach at solving the problem than coding that, or even sometimes solving that problem might be an actual waste of effort, better spent elsewhere !

Design, tooling, relevance != implementation.

And not saying don't think just pointing out that careful handcrafted logic takes almost the same time to implement anyway.

Most problems are such that it's hard to know what really needs to be accounted for initially due to some janky interface or the language not behaving as you expected which can nuke the whole plan.

Writing stuff down can make you more confident about the approach and ironically lead to a dead end because you assumed everything was accounted for.

I can't tell if this is sarcasm or not, you have the word "pen" in your name!

Anyway, not sure if it's "guaranteed" to be worse than using a computer. Yes, you'll definitely get less help with pen and paper. But you'll probably end up understanding the problem better, without relying on GPT completion of code etc...

> All computerization adds a mental burden

Even if it did, having to write down thoughts or code by hand at slow speed and without convenient way to modify it is significantly worse. Not to mention I'd constantly get distracted by my ugly handwriting.

If you prefer doing it the oldschool way that's fine, but don't force it on others assuming their brains work the same.

I'm not much of a programmer but also find this much better for my thinking process. I'm much more creative and likely to think bigger-picture.

But then i can't use copilot

My first code was done with a graph paper notebook, and a pencil.

It was Machine Code.

Am surprised by all the negative comments about writing code by hand. Many of the comments here speak about moving or thinking faster, but where I have always found pen and paper most helpful is when I've needed to slow down, focus, feel out edge cases, and give my intuition and experience more chances to engage with the problem. Occasionally for purely algorithmic things I've written out an entire function or loop, but more often it's a table of the program state during an iteration, or a diagram of how two things talk to each other, or what calls what in what order... just the little bits I need to think about, get clear on, before I go back to my editor for the next steps to address the problem. If you've ever driven a manual transmission, it feels a little like downshifting to get extra power on a steep hill climb.

It has been suggested ([1],[2]) that writing by hand helps with memory retention and probably other aspects of cognition; in my case, it may just be that writing [edit: by hand] "feels calmer," so, if I have a hard problem to think through, the pen usually comes out.

[1] https://pubmed.ncbi.nlm.nih.gov/33815075/

[2] https://journals.sagepub.com/doi/abs/10.1177/095679761452458...

I’m the same way. Different strokes for different folks, I suppose.

I need to write down my thoughts for everything on paper, sticky notes or drawing boards if I want to be sure that Ive thought about it well enough. I find most people don’t have this immediate drive for quality, though. Most developers just want to splash words on the keyboard and see an initial result to see if it works. I work the opposite way, I need to see it work in my mind or on paper before coding it. But neither of us is right or wrong, we just work differently.

Often when I can't think of a solution, and my attempts have failed, I inadvertently stop paying attention and just start messing around with words on the screen in the IDE. Pen and paper helps me focus on the problem.

Also, when thinking of a solution, and I'm starting to form an idea in my head, typing it into an IDE can make me lose focus unless the idea is already very clearly outlined in my head. It's happened to me before that while I have a partially formed idea in my mind, I type it into the IDE, and a large window of completion suggestions, or a red underline from a typo, distract me and I forget the idea I was thinking about, and I have to start over.

I was diagnosed with ADD; it could be I'm just more easily distracted than other programmers.

And yeah, I draw tables, write pseudo code, draw outlines of the program, sketch data structures, etc.

Reply on news.ycombinator.com