4 ms·

A tangential thought but related: I would find this absolutely frightening. I understand the motivation behind it but I always like to start from something exis

by chx 9y ago

A tangential thought but related: I would find this absolutely frightening. I understand the motivation behind it but I always like to start from something existing and editing it -- even if by the end nothing remains of the original. To some, an empty editor window is infinite possibility but to me, it's a "coders block", not sure how to phrase it. Infinite analysis paralysis perhaps.

skrebbel 9y ago
But this is different, because you already have: - the method's signature and spec - the changes in behavior you want
- lallysingh 9y ago
  - tests - history for file (and any bugs listed in there that had to get fixed more than once)
  - criddell 9y ago
    The first thing I thought when I read the title is what that would do to the history. Looking at a diff and seeing a small modification to a method tells me more than a method that has entirely changed with for loops changed to while loops, indices replaced with iterators, different whitespace and brace placement, etc...
    - s73ver_ 9y ago
      That's where commit messages come in. Sadly, those can be just as poor as inline comments for telling you why something was done.
crb3 9y ago
Fill out the comment-header first, then; that's what I do. That informal-prose chatty summary of what the code does and why, what it takes in and what its output is, becomes in my mind the spec for the code while I'm writing it, even in casual one-shot Perl filters. It makes it easier for me to choose variable names which inform rather than mystify, because the master reference is staring me in the face as I write. It's also an attitude-anchor for specific tail-end comments to expand on the summary explanation by detailing why a line is as it is and does what it does. YMMV, but, for me, the payoff is an easier time of drawing thoughts together into code, plus, months down the road, an easier time of deciphering why I wrote the code that way.
adaml_623 9y ago
I totally understand that. Expanding and modifying an existing system is 1000 times easier than starting from scratch.
steinuil 9y ago
I always split my editor window vertically, make some space over the method I want to replace and make sure the old version is visible on the other window, and then I rewrite it while referencing the old one. I only copy and paste stuff over if there's something I really don't wanna write again.
weberc2 9y ago
That's remarkable. I typically find it harder to shoehorn some new idea into existing, often badly-written code than to reimplement something appropriately general. This isn't meant to rebut your point; simply another observation.
allengeorge 9y ago
I find that happens when one - or all - of the following are true: 1. Don’t have a good understanding of the existing system architecture 2. Have not thought through the design of whatever has to be added, both in terms of function expectations or overall flow 3. Overly (?) concerned with “getting it right”; that can lead to paralysis: somehow you have to both demand the best of yourself at that moment and yet accept that despite it all you may not make the best choices - and that’s ok

by chx 9y ago

skrebbel 9y ago

But this is different, because you already have: - the method's signature and spec - the changes in behavior you want

lallysingh 9y ago
- tests - history for file (and any bugs listed in there that had to get fixed more than once)
- criddell 9y ago
  The first thing I thought when I read the title is what that would do to the history. Looking at a diff and seeing a small modification to a method tells me more than a method that has entirely changed with for loops changed to while loops, indices replaced with iterators, different whitespace and brace placement, etc...
  - s73ver_ 9y ago
    That's where commit messages come in. Sadly, those can be just as poor as inline comments for telling you why something was done.

crb3 9y ago

Fill out the comment-header first, then; that's what I do. That informal-prose chatty summary of what the code does and why, what it takes in and what its output is, becomes in my mind the spec for the code while I'm writing it, even in casual one-shot Perl filters. It makes it easier for me to choose variable names which inform rather than mystify, because the master reference is staring me in the face as I write. It's also an attitude-anchor for specific tail-end comments to expand on the summary explanation by detailing why a line is as it is and does what it does. YMMV, but, for me, the payoff is an easier time of drawing thoughts together into code, plus, months down the road, an easier time of deciphering why I wrote the code that way.

adaml_623 9y ago

I totally understand that. Expanding and modifying an existing system is 1000 times easier than starting from scratch.

steinuil 9y ago

I always split my editor window vertically, make some space over the method I want to replace and make sure the old version is visible on the other window, and then I rewrite it while referencing the old one. I only copy and paste stuff over if there's something I really don't wanna write again.

weberc2 9y ago

That's remarkable. I typically find it harder to shoehorn some new idea into existing, often badly-written code than to reimplement something appropriately general. This isn't meant to rebut your point; simply another observation.

allengeorge 9y ago

I find that happens when one - or all - of the following are true: 1. Don’t have a good understanding of the existing system architecture 2. Have not thought through the design of whatever has to be added, both in terms of function expectations or overall flow 3. Overly (?) concerned with “getting it right”; that can lead to paralysis: somehow you have to both demand the best of yourself at that moment and yet accept that despite it all you may not make the best choices - and that’s ok