[Coco] How do you program?
james at skwirl.ca
Fri Dec 9 21:10:43 EST 2005
On 9-Dec-05, at 5:04 PM, Jim Cox wrote:
> 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?
I think a lot before tackling completely new code, I think about the
features I want, how I might implement them, how I want the
interactions to work, etc. And, as evidenced by my output, it usually
However, when I'm working, ie. for money, I start drawing some
preliminary object diagrams, since I do my for-profit stuff in object
oriented languages. Then I start with the object interfaces first,
before implementing it (ie. just the header files), and see how I
think that'll work.
Once I start implementing the functions associated with the objects
I'm creating, it gives me a better idea of what I might need to
change in the interfaces. I usually start with my core functionality,
since that's what the rest of the code deals with.
Then I'll test what I can, sometimes writing skeleton code to do so,
cause I like to see stuff working, it gives me the push to finish the
rest. Sometimes this points out limitations in the design I worked
out, but it's better I find those while still coding, than later on.
After that comes maintenance, when I "think" I've finished, but then
someone else uses the software, and we find out that what I thought
was working doesn't work right for others. Usually because the
assumptions I made when developing are different than the ones my
boss had. This usually results because the boss changes his mind, or
I just didn't get the exact idea right, for whatever reason.
Then there's tracking down obscure bugs. You know, those bugs that
show up when somebody else is using it, that you never come across
cause you didn't think anyone would use the software like that, ever,
not in a million years. And then, even when the user has given you a
detailed test case, it doesn't reproduce on your machine.
Sometimes there's optimization to be done, and I like optimization.
Generally, to be a proper software engineer, you do this once
everything works right, but is just slow, or takes up too much
memory. Usually, with desktop software, the issue is speed, rarely
resource constraints. With modern operating systems and processors,
this can be very interesting.
I've worked in teams of just myself all the way up to 13 developers
on a project. My personal preference is a small, close-knit, in-
person team. There are less procedures you need to put in place to
keep things from going crazy. Two works well, while one can be a bit
> PS: Still would like to get opinions about how to proceed with my
> career and moving to an engineering tech job.
Experience is the only thing that'll get you a decent paying job. I
was lucky enough to enter the co-operative education program at my
university, and got some job experience before graduating.
More information about the Coco