5 ms·
> Joe wrote amazingly simple programs and he did so in a peculiar way. First he wrote down the program any old way just to get it out of his head. Then once it
by apo 7y ago
> Joe wrote amazingly simple programs and he did so in a peculiar way. First he wrote down the program any old way just to get it out of his head. Then once it worked he would then immediately create a new directory program2 and write it again. He would repeat this process five or six times (program5, program6, ...) and each time he would understand the problem a little better and sense which parts of the program were essential enough to re-type. He thought this was the most natural thing in the world: of course you throw away the first few implementations, you didn't understand the problem when you wrote those!
I thought I was the only one who did that.
- StefanKarpinski 7y agoI often do the same thing.
- galimaufry 7y agoI have heard that J.P. Serre used the same method when writing his books.
- theprotocol 7y agoDoing that made me feel insecure. Reading this helps with that.
- lukego 7y agoJoe also happened to type with only two fingers. Made me realize how little a hyper optimized touch typing style really impacts work outout!
- sleepychu 7y agoYou only need two fingers to type ctrl+space! I'm sure I use more than two fingers but even to increase APM I focused on getting more for my keystrokes rather than more keystrokes.
- rectangletangle 7y agoI often do the same thing with more critical functionality. Though I'm not quite as thorough, usually calling it at iteration 2 or 3.
- kabdib 7y agoGood code isn't written, it's re-written. It is scary when something "works the first time", because it probably doesn't.
- erikpukinskis 7y agoThere's different ways to re-write though. I tend to assume I couldn't come up with the right design if I tried. So I will leave my naive implementation in place until USE shows me a bug or a new feature and then that IMPLEMENTATION shows me where my architecture is clunky, and how to fix the original thing. Over time, everything important gets a full rewrite or four, but only piece by piece. Generally I assume in an implementation vacuum the long term spec isn't even well defined so I would never just rewrite something immediately. Sometimes if a module proves difficult to amend I will start over from scratch. But usually by then I have tests and use cases I am confident in. I love the idea of people doing these rewrite series though... not trying to be evangelical. Just describing a different kind of rewrite.
- Gibbon1 7y ago> So I will leave my naive implementation in place until USE shows me a bug or a new feature and then that IMPLEMENTATION shows me where my architecture is clunky, and how to fix the original thing. I do that too. And I generally avoid refactoring anything until the pressure it's putting on the rest of the code justifies it. And one of the things I think isn't appreciated is me in the future probably will know better how to rework the code than me now.
- kabdib 7y agoBack when rocks were young, one of my hobbies was writing assemblers because the ones available were generally terrible. My first few attempts were pretty bad. The fifth or sixth assembler that I wrote was commercial quality; it was fast, had macros, supported most of the different microprocessors that our platform had, and became widely used. It's been forked and is still in active development today, 35 years later. I'm still proud of it. But those first efforts were indeed awful, and those were preceded by even more false starts; it took 2-3 years of iteration [not full time!] to get to something that was good. (Simple assemblers are, well, simple. But if you're in an industry where it's common to write a ton of assembly -- like the early gaming industry was -- you start gauging assemblers by the creature comforts they provide, such as a decent macro capability, cross-reference and listing support, performance, and support for chip manufacturer assembly syntax).
- duxup 7y agoAs someone who changed careers and now is coding as a career, it's comforting to see other folks doing this ;) I feel like I get more "right" the first time now, but man I still see a better way once I'm done nearly every time.
- tombert 7y agoI do something pretty close; if I'm working on a new feature, I typically create a branch off master, get an implementation working, then do another branch off master without having merged my original code. I repeat this until the code is acceptably un-awful. It's kind of validating to hear that Joe had a similar workflow to me.
- dimatura 7y agoI do it as a way to deal with perfectionism. I write program0 (hey, this is computer science, we start at 0) and often never get around to program1, since program0 works, despite being a bunch of hacks. But I feel less bad about the hacks while I'm writing them, since it is version 0, after all...
- pryelluw 7y agoNot at all. There are others (me included) who also realized that code evolves with your understanding of a problem.
- gitgud 7y agoI feel like I do this too, but within a git repo.
- yellowapple 7y agoThis is how I've inadvertently been tackling my toy (for now) Erlang-based programming language (OTPCL). Wrote and rewrote and rewrote the parser, then wrote and rewrote the interpreter, then wrote a small standard library that I'm in the process of again rewriting and expanding (and I'm learning in the process that another rewrite or otherwise major change of the interpreter is likely in order; I'll probably also need to rewrite both yet again - and possibly even the core execution/evaluation model - if/when I decide to attempt to compile OTPCL to BEAM instead of it being strictly interpreted). I figured my tendency to start and restart things is just because I'm a terrible programmer. Good to hear I ain't alone :)