[Coco] How do you program?

[James Dessart]

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  
ends there.

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  
isolating.

> 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.

--
James Dessart
http://skwirl.net