Hacker News Reader

Comment by j_baker | Hacker News Reader

Type 1 is right for you. A good type 2 knows they can't anticipate the future and prepares for the unknown. If overdone, this is bad, but the same can be said for type 1.

And rewrites do become difficult as a system grows if you don't think them through. It's easy to rewrite one component with no dependencies, but it's not so easy to rewrite something that lots of different pieces of code rely on.

View on HN

A problem with a verbose approach is that when ver 2.0 comes you can't really know/remember which part of the code is actually used and which was just prepared for future development - so you end up maintaining and coding around pieces of code that will never be used.

Like I said, what eventually bites you is that you never ever ever know exactly what version 2.0 will require. So in the end you still have to adapt code, and adapting clean short code is easier.

If you have to explicitly remember which code was prepared for future development, you're doing something wrong. The point of having loosely coupled code is that it should be easily modifiable under a wide variety of circumstances.

I upvoted you for your braveness but I strongly disagree with you. (For me) Type 2 is wrong for everybody because: + Been there, done that, ended sadly; + We're all different but our limitations are pretty much the same, respect your colleagues! + Every successful achieving programmer I've worked with are persons with particularly good sense; + Knowing how programming related skills like abstraction and logic are highly related to cleverness you can be easily tricked into seeing programming as a cleverness demonstration or competition. That should be done in college or in controlled environments(no deadlines, no changes in team).

Reply on news.ycombinator.com