Hacker News Reader

Comment by chx | Hacker News Reader

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.

View on HN

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.

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.

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.

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

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

But this is different, because you already have:

- the method's signature and spec

- the changes in behavior you want

- tests

- history for file (and any bugs listed in there that had to get fixed more than once)

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...

That's where commit messages come in. Sadly, those can be just as poor as inline comments for telling you why something was done.

Reply on news.ycombinator.com