4 ms·

Good code isn't written, it's re-written. It is scary when something "works the first time", because it probably doesn't.

by kabdib 8y ago

erikpukinskis 8y ago
There'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 8y 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 8y ago
  Back 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).
  - erikpukinskis 8y ago
    I've been trying to build a web-based IDE for more than 10 years. The first one was a PHP script that had write access to change the files in its own directory. I've started over completely, at least 6 times, trying entire new languages, entire new feature sets, entire new hosting paradigms. Each time I try again, I get closer to something professional. Each time the hacks get a little too messy and realize I'm out of my depth. But lately less and less changes with each rewrite. I am able to pull entire chunks of code in from a previous iteration and have them work well, with little modification. The process of writing software that's beyond one's ability is fascinating.
ahmedalsudani 8y ago
You get used to things working the first time when you use a strongly typed language like Haskell or ML. Still need to test for off-by-one errors and that sort of subtle bug, but it really is true that your program will mostly be error-free. Highly recommend investing some time in such a language if you are able to.
- opportune 8y ago
  There's much more to errors than just types. The source of most of my errors are failures to account for corner cases in input data that I have no control over
  - joevandyk 8y ago
    Most common error in my and teammates code (Ruby, JS) while actively working on it is code being edited is not consistent with the other code in the system. Thinking I’m dealing with an Object A when I have object B. Not realizing that nil is a valid thing to be returned from code that at first glance shouldn’t return nil. Plus, accidentally writing super slow n+1 queries. And accidentally loading too much data.
  - ahmedalsudani 8y ago
    The comment was about code working when you first run it--not exactly where input outside your control comes in. Also, you'd be surprised how much types can catch, but feel free to completely ignore my opinion if that suits you ¯\_(ツ)_/¯
    - revvx 8y ago
      In my experience, a sufficiently rich type system is extremely similar to TDD in this regard. Both give you super fast feedback and a lot of issues can be solved before you finally launch your software for the first time. But neither will save you from bad design or misunderstanding your requirements.
      - 8y ago

Good code isn't written, it's re-written. It is scary when something "works the first time", because it probably doesn't.

by kabdib 8y ago

Good code isn't written, it's re-written. It is scary when something "works the first time", because it probably doesn't.

erikpukinskis 8y ago

There'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 8y 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 8y ago
Back 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).
- erikpukinskis 8y ago
  I've been trying to build a web-based IDE for more than 10 years. The first one was a PHP script that had write access to change the files in its own directory. I've started over completely, at least 6 times, trying entire new languages, entire new feature sets, entire new hosting paradigms. Each time I try again, I get closer to something professional. Each time the hacks get a little too messy and realize I'm out of my depth. But lately less and less changes with each rewrite. I am able to pull entire chunks of code in from a previous iteration and have them work well, with little modification. The process of writing software that's beyond one's ability is fascinating.

ahmedalsudani 8y ago

You get used to things working the first time when you use a strongly typed language like Haskell or ML. Still need to test for off-by-one errors and that sort of subtle bug, but it really is true that your program will mostly be error-free. Highly recommend investing some time in such a language if you are able to.

opportune 8y ago
There's much more to errors than just types. The source of most of my errors are failures to account for corner cases in input data that I have no control over
- joevandyk 8y ago
  Most common error in my and teammates code (Ruby, JS) while actively working on it is code being edited is not consistent with the other code in the system. Thinking I’m dealing with an Object A when I have object B. Not realizing that nil is a valid thing to be returned from code that at first glance shouldn’t return nil. Plus, accidentally writing super slow n+1 queries. And accidentally loading too much data.
- ahmedalsudani 8y ago
  The comment was about code working when you first run it--not exactly where input outside your control comes in. Also, you'd be surprised how much types can catch, but feel free to completely ignore my opinion if that suits you ¯\_(ツ)_/¯
  - revvx 8y ago
    In my experience, a sufficiently rich type system is extremely similar to TDD in this regard. Both give you super fast feedback and a lot of issues can be solved before you finally launch your software for the first time. But neither will save you from bad design or misunderstanding your requirements.
    - 8y ago