Hacker News Reader

Comment by edw519 | Hacker News Reader

Wow, there is so much wisdom here, I don't know where to start. So I'll just say that I have encountered almost every one of these situations at one point or another, and Jason is almost dead on.

The most important one for me is probably #3 "Get Rid of Abstractions". I learned this one the hard way. Now I just work on the problem at hand and worry about how to extend it later. It's a lot easier to generalize a specific case than to write something generalized in the first place. Could have saved me years.

View on HN

Here here - In our project, its packed with generic features - most of them haven't be used ever and were released ages ago. Often they really complicate the application with lookup tables and weird logic that never sees the light of day, 'just incase'!

I think you mean "Hear, hear".

Hear, hear indeed - It was 11pm after a long day when I wrote that, but I won't make the same mistake again, lol!

Good example but not what I was referring to.

I just finished an app with 51 separate modules, every one hard coded in infinite detail, and much of the code duplicated, 4000 LOC in all. Crazy, right? I used to think so, too. I could have written one very flexible parameter driven module in a few hundred LOC.

But guess what? Even though I bitched and moaned the whole time I wrote the monster, I was able to refactor and "genericize" it in one day. Start to finish time was much shorter than if I had written the flexible module first (that is, if I had ever finished).

This was a non-intuitive lesson for me. Write the specific case and extend later. I always used to try to write the most comprehensive "able to do anything" code until I realized that sometimes, the long way around is actually quicker.

Thanks again Jason, for #3.

This seems like a great idea if you are committed to immediately refactoring. The problem is that most people move onto something else as soon as they have something that works. In this case, the code becomes a maintenance nightmare until someone actually takes the time to refactor it.

When immediate refactoring is unlikely (either due to laziness, lack of focus, or feature deadlines), some kind of balance has to be reached on what should be more general and reusable and what should be hard-coded and specific. And then we're right back where we started.

But reading and thinking about your posts has been very insightful. On my next project, I will try your approach. I agree that in the long run, it is likely to be a more efficient use of time. I imagine, though, that someone coding in this style will either have to have a great memory or take good notes in order to know where similar code is located. Especially consider the case of generalizing the code from one project to another project.

Like I said, it wasn't easy doing it this way. Every bone in my body screamed, "What's wrong with you? Stop replicating code! Write flexible functions!" But I struggled on until everything worked perfectly.

Here's the good news: I couldn't wait to refactor. I was "in the zone" the whole day. And it felt great. I finally got to clean up the mess that I made, and best of all, I didn't have to struggle trying to figure out how to handle that strange outlying case: it was all already there!

I don't know if I'd try this in someone else's shop. You're right; they'd probably pull me off before I got to refactor, leaving a mess for someone else with nothing learned.

Reply on news.ycombinator.com