in reply to How do you view programming

Since the beginning, which is way too long ago now, I've always done most of it in my head during more mundane activities like driving the car, mowing the lawn or visting relatives -- oops I didn't say that, did I?

It starts with ideas of "boxes" or "widgets" I want. That usually starts with an "I wish I could do this in one line idea" and goes from there. I always zoom in and out to the detail code level and back up to the overall design, usually many many times in my head before I write anything. Unless it's something very simple, or something that fits into an existing model I have. OO set me free here in a way, even though it was bit of a hump to learn it after 8-9 years of procedural coding. We had well defined, well accessed, well hidden data in our procedural code for the most part, but things in OO that you just couldn't do easily (or at all) procedurally, like inheritence and ploymorphism really made a difference. I find it comical that people sometimes scoff at Perl and OO because two of the things I love most and use a lot in my designs -- ties and closures -- don't exist in traditional OO languages like C++ and Java (or do they in Java and I don't know it?). And I simply can't live without regexps at this point in my life. Before Perl I did many years of shell, awk, and sed so I'm a lost cause when it comes to regexp's.

During that thought time I scribble things down I usually can't make sense of later but which help me through the thoughts at the time. When I'm into it a bit I also usually write some throw-away test code to help solidify the ideas. I've never been a fan of the design first/code second method -- I just have to try things out or it gets too abstract. Having a full-time internet connection has really made a difference here. I can pop in and look up an idea or try a code snippet out whenever I want.

I also like to try and find something at least similar to what I want that's already out there and check it out, both playing with it and looking at the code to see how other people solved similar problems. I've always felt I have more of a strength extending something someone else has started than coming up with extremely novel new ideas. For years I worked with a great idea guy and I just grabbed what he started and took it further. It was a very satisfying working relationship. It's not that I didn't come up with anything on my own -- he just was more of the frontier guy and I'd latch on and go for the ride.

A few other quirks I know I have in this area: I need to see code blocks when I read and write code. I've never been able to see blocks with the old kernel style braces which is why I've almost never used them. To me, identifying code blocks is the first thing my brain tries to do when looking at code. When I code I invariably stub out a bunch of empty blocks and functions/methods first, then fill them in later (often breaking them down further). But contrast that with another quirk I've picked up in my old age: Line level comments primarily serve as a distraction, whereas I used to comment every line when I was right out of college. I think my brain has just learned to scan code over the years. An interesting observation here too: The absolute best coders and designers I've worked with are much better than their peers at "sucking in" existing code and making sense of it. That, IMO, is a much harder skill to master than writing brand new code and it is where much of our time is spent.

Replies are listed 'Best First'.
Re: Re: How do you view programming
by iguanodon (Priest) on Feb 16, 2003 at 14:41 UTC
    Too bad I can only ++ you once, steves.

    I've always done most of it in my head during more mundane activities like driving the car, mowing the lawn or visting relatives
    I get a good deal of work done this way. Once I get an idea of the data I'll be working with, I start thinking about the data structures I'll use within my application. I often find that this kind of design is easier to do when I'm not at my desk.

    When I'm into it a bit I also usually write some throw-away test code to help solidify the ideas. I've never been a fan of the design first/code second method -- I just have to try things out or it gets too abstract.

    I've learned that in my job, the users often don't really know what they want, and they will agree to a paper specification without really reviewing it. I think a lot of people have a tough time visualizing the end product from some words and mocked up screens on paper. So I like to hack up a prototype application as soon as I get the basic requirements, then let the users comment on that. Not to mention that this increases the fun factor by minimizing the amount if spec. writing and maximizing the amount of coding.