[davismwfl]

I keep notebooks still for most things. I use them to jot down ideas, sketch out designs and just generally write down my thoughts so I don't forget them, I usually have one to many per company and one per project. I also use them to take notes in meetings versus trying to take notes on my computer in real time. Personally, I find it pretty rude to be typing away on a computer while people are presenting or we are discussing ideas. It seems far less rude to jot down notes on paper and then come back to it an flush things out after the meeting.

I do translate my notes as I work through the problems and put them in a tool like OneNote or Evernote etc. But I always start off with sketches and notes in a notebook. My bet is if you looked at the pattern of those who use notebooks vs those who don't, you'd find those of us using notebooks still skew to an older average age. 40ish+ likely.

Personally, I also jot down pseudo code on paper to get my thoughts right before starting to code the problem. This lets me get my thoughts straight before coding it and I find I make fewer mistakes, plus I am faster when I do this. It is also one of the reasons I dislike coding interviews where someone wants you to just start writing code in the IDE. I don't do that well, because to me the process is, understand the problem, design the solution, engineer the solution, then start coding.

[yellowboxtenant]

Have you found any writing or organizational patterns to be useful? When you design a solution, does that look like a flow diagram? When you engineer a solution, do you jot down in natural language what you think you should do?

[davismwfl]

So, I do follow patterns. For notes they are just notes, written down in my own shorthand methods many times, but I leave space around each note so I can come back and jot down extra information or revise myself. So usually I leave a line or two of space depending on what it is.

When I am trying to solve a problem, I write the problem down first, then move into breaking it down in a process. I define the actors involved, the expected input and the expected output and any error conditions that I identify. Then from there I generate a simple hand written flow chart (not fancy) that will serve as a happy path through the problem.

When I get to the engineering of the problem that is where I start identifying parameter limits, error conditions, output limits and then generally write down some pseudo code to give me something to look at, sometimes that means flushing out a more complete flow diagram first. And I generally use just natural language, as none of what I am writing down is real code, although I may use abbreviations or C syntax at times to express something if it is easier. For example, I use the conditional ? : quite often for simple flow control statements just because it is compact to write, even though in code I may not use that operator in that instance.