Poll: How do you begin coding?
7 comments
I start by building the smallest possible subset of the answer as fast as possible. I think Paul Buchheit said he liked to do this too.
This was my approach also, until I find that growing a project "organically" ends up being very disorganized and missing "the bigger picture," compared to the open code I read. I sometimes also find a mistaken assumption at the start led me in a wrong direction from the start.
I'm just trying to refine my coding without losing the instant satisfaction of hacking something together at the start and seeing it work.
I'm just trying to refine my coding without losing the instant satisfaction of hacking something together at the start and seeing it work.
The way to avoid disorganization is to refactor your code constantly. As soon as you complete a feature, refactor. Most high-quality "open code" you've read has probably been rewritten 4+ times as the developer became more familiar with the problem domain.
Yes. Till I read your comment I wasn't sure what to say to the guy. I couldn't imagine how this couldn't work for him, because I'd forgotten it was possible to program without constantly rewriting your code.
In fact, the word "refactoring" feels a bit strange, because I was doing it for so long before there was a word for it. It's one of those terms (DSL, agile, etc) invented by mainstream programmers as they gradually reinvented Lisp hacking.
In fact, the word "refactoring" feels a bit strange, because I was doing it for so long before there was a word for it. It's one of those terms (DSL, agile, etc) invented by mainstream programmers as they gradually reinvented Lisp hacking.
I noticed that you used the word "agile" in On Lisp, which can hardly have been a word to be expected in a book about hacking. By the time I read it, though, the agile software movement existed, so it leapt out at me.
"Refactoring" is a particularly strange word. It's as if people were talking about "exhaling" as a distinct and even controversial practice. How can anyone breathe without exhaling? Yet articles and books would be written about it: "Should Breathers Exhale?" "When Is An Appropriate Time To Exhale?" "Exhaling: For And Against". People would ask their managers for approval to exhale and the managers would say no we can't afford it, and eventually they'd either just do it anyway on the sly or else turn blue and keel over.
"Refactoring" is a particularly strange word. It's as if people were talking about "exhaling" as a distinct and even controversial practice. How can anyone breathe without exhaling? Yet articles and books would be written about it: "Should Breathers Exhale?" "When Is An Appropriate Time To Exhale?" "Exhaling: For And Against". People would ask their managers for approval to exhale and the managers would say no we can't afford it, and eventually they'd either just do it anyway on the sly or else turn blue and keel over.
First I get some sort of framework in place where development is quick and enjoyable... whether that be having an IDE set-up for the project, or setting up __autoload() in PHP so that I don't have to put requires everywhere.. I just want to be sure I can code and not be distracted by overhead issues unrelated to the problem at hand.
As per the actual coding, I agree with pg on this. I divide the problem into "sub problems," often sketched out in pencil with flows for certain things (and maybe corresponding UI's, if it demands). I choose to start work on either the most important (central) process, or often the most interesting one (to get me warmed up and enthused about the problem). Once this is done, it's a matter of branching outwards from that process, and optionally filling in UI's corresponding to that process.
Along the way, refactors are inevitable, but most of the time I find I wouldn't have been able to predict them even if I'd initially spent a large amount of time doing conceptual models. I find the things that take the most time are the unexpected things, which I won't find out about until I'm coding it.
The one thing I enjoy most about having the process sketched out is the options it provides. For me, it's not so much the issue of coding that is the challenge, but giving every aspect of the project the attention it deserves, without getting too bogged down on devoting too much time to making one part really awesome. When I see all the work that needs to be done, and what's related to what, I realize the scale of the sub problem I'm working on may not be as profound as I'd like it to be.
As per the actual coding, I agree with pg on this. I divide the problem into "sub problems," often sketched out in pencil with flows for certain things (and maybe corresponding UI's, if it demands). I choose to start work on either the most important (central) process, or often the most interesting one (to get me warmed up and enthused about the problem). Once this is done, it's a matter of branching outwards from that process, and optionally filling in UI's corresponding to that process.
Along the way, refactors are inevitable, but most of the time I find I wouldn't have been able to predict them even if I'd initially spent a large amount of time doing conceptual models. I find the things that take the most time are the unexpected things, which I won't find out about until I'm coding it.
The one thing I enjoy most about having the process sketched out is the options it provides. For me, it's not so much the issue of coding that is the challenge, but giving every aspect of the project the attention it deserves, without getting too bogged down on devoting too much time to making one part really awesome. When I see all the work that needs to be done, and what's related to what, I realize the scale of the sub problem I'm working on may not be as profound as I'd like it to be.
For me most projects tend to consist of a lot of problems I already know how to solve and a few problems I have to come up with solutions for. I usually start by working on the unsolved problems first.
Usually by creating an individual program that does each task. Then the job becomes considerably more tedious: putting everything together and making it work.
I solve new problems for the same project the same way. I create a solution as an individual program and then incorporate it into the larger system.
Usually by creating an individual program that does each task. Then the job becomes considerably more tedious: putting everything together and making it work.
I solve new problems for the same project the same way. I create a solution as an individual program and then incorporate it into the larger system.
The first thing I do, typically, is write out the requirements.
If I already have requirements, I rephrase them in my own writing.
Then I start sketching out some possible solutions in notes, as brief phrases. I may start writing code at this point, but I continue making notes occasionally.
If I already have requirements, I rephrase them in my own writing.
Then I start sketching out some possible solutions in notes, as brief phrases. I may start writing code at this point, but I continue making notes occasionally.
see which API's Im working with... or if from scratch then see which API's I'll be constructing and how those will be used by higher up functions...
if the app has a GUI then mockup the GUI first in some graphics program to see which kinds of things are useful to users, and then see what the minimum number of primitives is needed from the layers bellow to service that
if the app has a GUI then mockup the GUI first in some graphics program to see which kinds of things are useful to users, and then see what the minimum number of primitives is needed from the layers bellow to service that
Well,
I make kind of entire excution flow in my head... and devide it into small steps/points. I write the points down on a paper...
Usually I can start with any step or point... I don't have to start from a specific point, so usually I start with the smallest one - the easier to code.
I keep a paper with me to write down any enhancements I want to add.
Usually I can start with any step or point... I don't have to start from a specific point, so usually I start with the smallest one - the easier to code.
I keep a paper with me to write down any enhancements I want to add.
This is meant to cover projects that tend to be larger in size.