Thread: Doing programs and algorithms

It's a matter of acquiring a discipline.

When I'm starting a new program (which I'm doing now) I tend to wander around doing my daily routine, but spending my spare time visualizing it and thinking about what it has to do. Once I have a decent mental image of the *result* I can start backtracking into the larger blocks needed to make it work... major sections like "display", "network ops" or "math processing"... now these I write down, each on the top line of it's own page and I'll carry these pages around with me for a few days, adding notes and ideas as I go. (My friends are known to say: "See that clipboard...he's programming again!")

Then as the process continues, I write down the smaller elements needed to make each major section work... for example the "network ops" might include "check password", "send error", "make new packet" etc.

Now when all this is done and I think I understand the *problem* well enough, I will sit down a the keyboard and start roughing out a *solution* which basically consists of writing a set of comments --"//Get new user", "// examine password" etc. that will eventually delineate the code I write. (think of it as a book author's outline)

From there it's coding time and I usually start by getting the output functions working (a GUI in most cases). Then it's internal business, such as functions to open files, read the keyboard etc. leaving the background work... networking, internet, etc. for last.

Now... be aware... when I do this, the final product usually bears little or no actual resemblence to all my notes and comment lists. It is changing constantly as I solve a hundered little problems along the way... But in the end I usually do end up with a successful program.

The notion that programmers hear a list of requirements then immediately start hammering the keyboard is totall bogus... Nobody with a lick of sense *starts* by writing code...

For me, and most of the others I know, the best way is to just keep thinking about it until you figure it out... The keyboard will still be there when I'm ready.

You can see one result of this process on my website... RemoteMedia

Originally Posted by kcpilot

I'd find a new career, because if your mind wanders when trying to program at this level, you won't make when the heavier programming comes along.

Well, that might be true... but I think it's a tad premature.

Many people approach programming like it's a "sit down and write code" thing... not realizing that's only a small part of the process. The real work is done in the planning stages.

Perhaps our friend just needs to approach it with the right mindset.

Originally Posted by kcpilot

I'd find a new career, because if your mind wanders when trying to program at this level, you won't make when the heavier programming comes along.

I've been thinking about that but I really do want to do programming.

Originally Posted by CommonTater

It's a matter of acquiring a dicipline.

When I'm starting a new program (which I'm doing now) I tend to wander around doing my daily routine, but spending my spare time visualizing it and thinking about what it has to do. Once I have a decent mental image of the *result* I can start backtracking into the larger blocks needed to make it work... major sections like "display", "network ops" or "math processing"... now these I write down, each on the top line of it's own page and I'll carry these pages around with me for a few days, adding notes and ideas as I go. (My friends are known to say: "See that clipboard...he's programming again!")

Then as the process continues, I write down the smaller elements needed to make each major section work... for example the "network ops" might include "check password", "send error", "make new packet" etc.

Now when all this is done and I think I understand the *problem* well enough, I will sit down a the keyboard and start roughing out a *solution* which basically consists of writing a set of comments --"//Get new user", "// examine password" etc. that will eventually delineate the code I write. (think of it as a book author's outline)

From there it's coding time and I usually start by getting the output functions working (a GUI in most cases). Then it's internal business, such as functions to open files, read the keyboard etc. leaving the background work... networking, internet, etc. for last.

Now... be aware... when I do this, the final product usually bears little or no actual resemblence to all my notes and comment lists. It is changing constantly as I solve a hundered little problems along the way... But in the end I usually do end up with a successful program.

The notion that programmers hear a list of requirements then immediately start hammering the keyboard is totall bogus... Nobody with a lick of sense *starts* by writing code...

For me, and most of the others I know, the best way is to just keep thinking about it until you figure it out... The keyboard will still be there when I'm ready.

You can see one result of this process on my website... RemoteMedia



Well, that might be true... but I think it's a tad premature.

Many people approach programming like it's a "sit down and write code" thing... not realizing that's only a small part of the process. The real work is done in the planning stages.

Perhaps our friend just needs to approach it with the right mindset.

Thank you for your post. It's nice. Yes, I'm one of the people who think programming as it's "sit down and write code", it's not because I always thought programming is like that, but the coders that I know by name are really good code writers and I think they're very thankful for that, but now that I'm having difficulties trying to code and together with your post I'm thinking that it's really about thinking first before writing the code, I've always thought that way regading programming partly because of the kind of code I want to write and then I think I need to be very fast thinker and code writer.

Originally Posted by stahta01

@guilhermeptrr: CommonTater method sounds good.

I would add that I try to write prototypes of the functions I think I will be using in the project before I write code for any functions; after I list all the prototypes I start coding. I even sometimes use the prototypes without changing/adding to them.

Tim S.

I prefer to write down things to a paper first when I'm studying, even though when it's just a draft or random things related to the subject I'm trying to read.