[Coco] How do you program?
lost at l-w.ca
Fri Dec 9 18:26:54 EST 2005
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
(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
> 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
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.
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?
More information about the Coco