After programming for a while now and looking back at how productive i am, i realise that i really can't get much done unless i have planned out prototypes for all the function on a piece of paper. Do other people use pen or paper, or are they just good enough to code right off? Does this mean i'm a bad programmer, or a good one as i have semi good, methodical habits? Just wondering what people think the best and most productive work flow is. I read that codes code on average 8 lines of code and hour. This is true if i haven't thought the code out at all, but if i have this number is x10 or more. What habits do you guys have? Just curious if there are ways to be more productive. PureBlackSin

I personally always write my ideas out on paper, whether it's code, or just a basic theoretical idea, I always start off on paper, just so that the idea is written down somewhere. That way I can always have a guide to what I was thinking originally (as it seemed to really click in my mind as this might work, and I just want that thing to be written before I forget it).

Unless it's something that I have to see in order to make the code (ie; animations or limb movements which require trial and error), I always have a written guide for the prototype. I don't think that it makes you a bad coder (like come on, it's not like your supposed to be the Neo (The Matrix) or a Jedi of programming to be able to code by just looking at the problem!). Most ideas start on paper, and then grow from there. Imagine, if Einstein and all didn't start on paper for the Manhattan Project (the first nuclear weapon building project) and they went directly to making a bomb and then dropping it, think what the results might've been............

I'd imagine that some people can code without prototyping on paper, but hey, we all got our styles.........so whatever fits you best is what'll work best.

Well, digital paper. I work best if I quickly jot down what tasks I need to do and sometimes simple pseudo-code, but physical writing is too slow and I hate juggling paper so I just open up notepad(++). I try to avoid anything that breaks my flow and taking hands off the mouse&keyboard and eyes off the screen to write something just messes me up.

Level design, though, is definitely suited to physical sketches. Designing a level without a pencil nearby is insanity. Interface design too. Anything that benefits from thumbnailing is paper stuff. Code, though? Seems like a placebo to me. Hard to think of any logical reasons why it would help. Different perspective, maybe? See things you wouldn't normally see? Eyes straining on your screen (try turning down the brightness)? Less distracting (try turning off your instant messengers/closing browser windows)?

Also worth noting the biggest advantage to digital writing: You can reorganize your thoughts as much as you want almost instantly. I find that alone to completely and utterly crush any advantages physical paper might have.

I use paper jotting down code that has a visual component or a structure I can visualize. I'm a very visual learner so it helps me to see my code.

For a lot of my projects though I jump in and look up documentation since I lack the knowledge to design certain things.

I love graph paper though over lined paper. If you don't have some pick up a pad. They're awesome.

My dream is to have a giant glass whiteboard that's lit with a faint green light. That would be awesome. Better if it had like an OLED grid.

I'm pretty terrible in that I really don't plan things out beforehand, I just jump straight into coding. I generally have a plan for how it's going to work in my head and nut out any function prototypes I'll need from there before getting into writing the functions.

It quite often ends up in some pretty messy code (Lots of commented out sections, unused prototypes, etc), but it's normally pretty easy to do a quick pass at the end of it and remove any unnecessary junk (Although when I working under tight deadlines I'm not really as strict at that as I should be, whoops).

I've tried doing it the other way, working it out in pseudocode on paper beforehand, but I'm so fluent in C++ now that it ends up being just as quick if not quicker to just write the code as I'm working it out. Not to mention using computers so much means that I can type WAY quicker than I can write, and the added bonus of tab-completion and auto-indentation helps a lot, too.

With mathematics, though, I'll generally write it out on paper first just so I can make little doodles of what I want the numbers to be doing.

from experience I can say that the only way of being productive is sitting your ass on the table and solving the problems.

I've expent days of my life drawing the perfect design for whatever and it never got to the point of becoming real.

I believe that the premise for be productive is getting real. I might be wrong though.

At University, it was:

• Meticulous planning


• Enough documentation to sink a cruise ship. Perfectly designed UML, sequence diagrams, flowcharts, use case diagrams


• Perfect Gantt chart (yes, those damned things), planned down to the last microsecond


• A whole new redefition of "prototype". In University/academic circles, a "prototype" is a fully finished, bug-free product polished to the point you can see your face in it


• Perfect code. Beautifully written, perfect formatting, variable names in the style the marker wants it even though it's likely wrong by an industrial standard

I should note that, on my course, the Agile methodology was banned for the final year project simply because it didn't produce enough documentation to satisfy the crusty old academics.

In the real world, it was:

• Enough planning to get started


• Enough documentation to cover all your bases, but not enough to get bogged down. No UML, no sequence diagrams, the occasional flowchart and a textual description in a template of roughly what you'd implemented for each requirement. This could only take about two hours depending on what you'd done and what needed done


• Gantt Chart? Yes, but it was at a very high level e.g. it would say "Implement bug fixes - 10 days" instead of "Do this - 5minutes, wipe arse - 30s, Do that - 4days)


• Prototype == rough idea. Bugs, but main functionality is present and point is made about look and feel. Almost no polish but enough to get the point across


• I've seen some catastrophically horrific production code, some that would easily fail you a degree at University but these guys are paid reasonably well for it

In short, I don't think that massive, extensive planning achieves anything. In many cases it seems like it was being done for the sake of it and, if you do it wrong at any stage, that's a whole shitload of time wasted.

I generally rough things out in my head, maybe scribble a few things down, then start to write code. There's no point in producing pretty diagrams and pictures if you don't have a working product at the end of it all and I wish more of the crusty academics would come round to this.

I think a very big problem is that most of the people have no idea about paper and pen even exist.

I wanted to start a thread about this, but I didn't want my rating to drop too much, because I probably would have hurt a lot of people with it.
But Anyway:

The biggest reason (I think) of that most of us can't solve anything (anything!) is the fact that paper and pen are not known at all as developing tools.
And it's a fact that there are tons of threads about problems, that are not so tough, but the poster doesn't have the slightest idea how to solve it.
If (s)he would have taken a piece of paper and a pen and start thinking for his own, he probably wouldn't have started a thread. (Not to mention those guys who ask for code).

And not just graphical problems, any problems (even the simplest array indexing stuff, GUI (not the layout, but the 'engine' itself)), that could be solved if paper and pen were used.

I guess most of the people are just staring at the IDE and hope for some magic spark or I don't know what, and if it doesn't come (why the hell it would?) they go and ask somebody to solve the problem for them.

There was an occasion (I don't want to hurt him), when I had to correct his rendering code about 4 times, because he couldn't give the vertices in CCW order.
After the fourth occasion, he said that it was embarrassing, but he had to draw it to understand.
That's my point, paper and pen was his very last desperate attempt to solve the problem (instead being the very first).

So that's my conclusion after the university, and after spending some time here on gamedev.

And sorry again.

[Edited by - szecs on February 18, 2010 6:15:08 AM]

I'm not speaking of decent documentations of course, but sketches like these (I was dumb enough to scan and upload these just to show):

01
02
03
04

just some papers used so far while making a hex grid minesweeper with windowed GUI.

[Edited by - szecs on February 18, 2010 6:38:22 AM]

I personally use pen&paper a lot for solving mathematical problems (does someone remember all my posts where I shuffle matrices around? often a piece of paper has suffered before) and diagrams of all kinds. But I don't prototype interfaces on paper (besides perhaps, as said, in some crude diagram form). So I think that pen&paper is some proper tool.