Hacker News Reader

Comment by radu_floricica | Hacker News Reader

Sometimes the world just is as simple as it seems. Type 1 is right, type 2 isn't.

After 15 years of writing code I can only vouch for two metrics of code quality: clarity and length. For a long time I too thought that clarity means using "thisIsAStudentBirthDate" variable names - but it turns out there are very very few instances where the shortest code isn't also the most obvious at first glance.

I think the turning point was when I decided rewrites aren't a bad thing. I started seeing the code as alive - unchanged code isn't good, is dead. The myth of perfect code is just an illusion. Writing for the next version sounds very sensible - until you get enough years under your belt to realize that either there won't be a next version or it won't be anything like you expect.

View on HN

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.

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

Definitely agree this juggling rests in experienced hands. A vet knows what balls can be dropped and which ones cannot. My thoughts on this are: 1) As a rule of thumb, the longer the project the more structured it should be--which should be a no brainer. 2) Having a clean dispatch module allows you to sweep the mess under loosely coupled rugs. 3) Programmers are code excavators first, curators second, developers third.

Reply on news.ycombinator.com