[Coco] How do you program?

[William Astle]

Jim Cox wrote:
> OK, here's another philisophical question for the group.
> 
> How do you program?  Assuming you know the programming langauge you are 
> working with, do you just sit down at the computer and bang at the keys 
> like a chimp, or do you think about what it is you want to do and what 
> you what you need to do it?

That depends somewhat on what I'm going to create. If it's a small thing 
(for some value of small) I often just start codeslinging. For more 
complex things, I have to work out what I'm trying to accomplish before 
I get started. I'm not sure there's any difference between the two 
situations, though. Things that tend to fall under "small" for me are 
those tihngs that just "come naturally" and are often problems I've 
solved before or are substantially similar to such problems. Basically, 
in those cases, the "figure out what I'm going to do" stage happens so 
fast that I don't really notice it.

As projects get more complex, I tend to break them into sub-projects 
that each get treated independently in the requirements and definition 
stage with how the sub-projects integrate being just one of the projects.

Personally, I tend to make "write only" notes about what I'm trying to 
do. Once I write it down, I tend to remember it long enough to use it. 
Sometimes I'll draw flow charts to work through the flow of something 
like an interface. Sometimes I'll make tables of requirements. Sometimes 
I'll specify a data structure ahead of time. It all depends on the 
situation. I never go through the "software engineering method" which 
involves making a flow chart, then making pseudo code, then fleshing out 
the pseudo code (lather, rinse, repeat until you get working code); I 
find that far too cumbersome for the projects I work on. It has its 
place, but it's too resource and time intensive to both with for most 
projects.

(For what it's worth, I've seen projects that were "engineered" by the 
book fail because of rigid adherence to the process. Likewise, I've seen 
projects that were not engineered strictly by the book fail because they 
dind't pay enough attention to the process. A happy medium is required, 
I think, and where that medium is is determined by the project itself.)

To sum up, I use my mind and computer for all projects. As the 
complexity increases, I start to use paper, text files, and other 
documentation, as a sort of swap space when my brain overflows. But, for 
the most part, I have the ability to keep most of the details of a 
complex active project in my head simultaneously. And it annoys the 
<insert expletive> out of people I work with. That technique only works 
well for coders who work mostly alone on a particular project (or 
sub-project).

> If your answer is the latter, what steps do you take, meaning what is 
> your thought process.  If it's the former, how often is your efforts 
> successful the first time out?

Successful the first time out? Hmmm. The odds of that happening seem to 
be at least an inverse square relationship with complexity of the 
project. The more complex the project, the less likely it works the 
first time. To a point. The real simple projects that are "blindingly 
obvious" tend to have a near 100% chance of failing the first time due 
to lack of care and attention to details.

> I'm finding that learning how to think like a coder is harder than just 
> learning the syntax and functions.

Certainly, learning the syntax of a language is usually not terribly 
difficult. There usually isn't a large number of rules involved. 
(Similar to English, for example: there are a fairly small number of 
rules that apply (most of the time) to make the structure of the 
language.) The functions used in the standard library or equivalent are 
more an exercise in memory than anything else (like learning vocabularly 
in English).

How you put the two of those together determines whether you're a good 
writer, an excellent orator, a poet, or just a passable communicator. 
Just like in English, how you think about coding determines how well you 
write it, and to a large extent, what type of code you write. There is a 
different way of looking at writing code for a user interface than there 
is for writing a device driver. Someone who is good at the former will 
likely struggle with the latter, and quite often, vice versa. Yet they 
may both be equally proficient with the language in question.

Going back to the "how do you code" question, the answer to that is 
determined somewhat by what is being coded, too. The further outside my 
comfort zone the project is, the lower the transition line between a 
small codeslinging project to a preplanned project. As I get better at a 
particular type of coding or algorithm or what have you, the higher that 
transition line gets. Similarly, the rustier I get at some particular 
thing, the lower the line gets, although it doesn't usually go as low as 
it starts out.

-- 
William Astle
finger lost at l-w.net for further information

Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL++++$ P++ L+++ !E W++ !N w---
!D !M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y?