Just been thinking and just thought i'd let you guys know a bit about the last diagram i made as an example:

Was a serve and client model, so i had arrows to boxes of things i need to do i.e. the layout of the system.

So a box for the server receive module to a process box and to a database box with a basic outline of tables.

It was more like a system plan, instead of the function prototypes, i'm fairly sure this is moving in the right direction, but should the pen and paper be abandoned, even for this kind of thing?

Just pen and paper and produce a good outline and diagram to work from to focus the mind, a bit like a diagrammatic todo list. What do you think?

PureBlackSin

Save trees, invest in whiteboards :(

Quote: Original post by way2lazy2care
Save trees, invest in whiteboards :(

And kill brain cells with solvent fumes to make problem solving a manly challenge!


Personally I use a mix of paper and white board. I write my programs out in a shorthand, and run base tests on algorithms by hand before I touch a computer. I keep my designs flexible, and program first and foremost to insure readability and keep strong documentation. When coding I actually start with a description of the problem to be solved, and then write the solution in as near plain English as possible. THEN I code. If I make a change, then I fully document the change ahead of time, and why I think this change is a good idea.

Does it take more time to get a code base running? Hell yes.
Does it save time when something breaks and I have to go back to fix a bug? Oh god yes!

I'm just happy some clever fellow doing IDE designs came up with the idea of hiding comment blocks. I'm the kind of programmer that feature was really designed for.

[Edited by - Talroth on February 18, 2010 1:32:56 PM]

Quote: Original post by Talroth
I'm just happy some clever fellow doing IED designs came up with the idea of hiding comment blocks. I'm the kind of programmer that feature was really designed for.

I programmer for TERRISTS!!!?

Concerning smaller projects, I just build up a framework of objects whilst deciding how they are going to interact with each other. Filling in the white space with comments on what that part of the program is suppose to be doing. I then take the top down approach, breaking problems down into smaller pieces as they naturally present themselves and refactoring when necessary. However, I can mentally differentiate between design mode and coding, regardless of the fact that I'm sitting in front of an IDE.

I only use paper to help me understand and solve a particular problem if I find the glow of the monitor too distracting.

I find I don't do as much writing things out as I used to do in my personal development. At home I used to use a large whiteboard to draw out the various components I was going to need, and how they would interact.

It's been a while since I have done anything decently large at home, so for the last while I just try to think things through mentally before I start working. I really should dig out my small whiteboard again though.

At work I definitely write a lot more down than at home, whether on a notepad or scrap paper. I'll keep a few text documents handy as well, showing general code flow, or a list of steps that need to be done.

I'd definitely recommend the whiteboard or scrap paper method. It's nice to have a visual reminder of what needs to be done, and how things are supposed to connect. Having one centralized place to keep your notes helps as well, so that something doesn't slip through the cracks.

Quote: Original post by szecs
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.

That's what my 'notes' look like, but they would also include phone numbers, grocery lists, drawings of random cartoon characters and the occasional coffee stain. I guess I'm more a hacker than a proper engineer: I really love having pen and paper laying around, and I hate working with extensive UML diagrams or some web based todo lists.

Quote: Original post by PureBlackSin
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.

I have to have a general overview of how components will work together, but I personally would never write down what these individual elements (classes, functions) are supposed to look like, that's something that will become clear once I start implementing. Although there are situations where others (colleagues, third party companies) directly depend on it, in which case I'll have to.

Quote: Original post by Wan
That's what my 'notes' look like, but they would also include phone numbers, grocery lists, drawings of random cartoon characters and the occasional coffee stain. I guess I'm more a hacker than a proper engineer: I really love having pen and paper laying around, and I hate working with extensive UML diagrams or some web based todo lists.

I didn't want to scan those (they include too much of by budget calculation, and some drawings of genitals)

I do try to write notes about what I'm about to code. The idea is that when later on I wonder what the hell I was thinking when I wrote something, I can find out. It's usually similar for both work and home. My notes tend to look like the development notes here.

I use pen and paper all the time to play with algorithms. I especially find myself doing that for parsing/string processing stuff, to make sure I don't make fencepost errors. Also, especially in game programming, I use pen and paper to figure out mathematical formulas for geometric stuff.

For a more high-level view, I pretty frequently draw flow charts with LucidChart (see shameless-plug sig) mapping out functionality, information flow, etc. It helps keep my ideas straight, and consistently communicate those ideas to other people on the team.