Comment by edw519 | Hacker News Reader

Comment by edw519 | Hacker News Reader

the number one most important skill is how to keep a tangle of features from collapsing under the weight of its own complexity

Agreed.

very rarely is there some tricky data structure or algorithm that casts a looming shadow over everything else

Agreed, BUT...

In order to organize, sooner or later, you will have to get clever (with tricky data structures or algorithms).

How I have always built something big and/or complex:

  1. Add lines of code. 
  2. Add lines of code.
  3. Add lines of code.
  4. Holy shit! What have I done?
  5. Refactor.
  6. Combine similar sections.
  7. Genericize with parameter-driven modules.
  8. Still too many lines of code! Optimize Step #7 with something clever.
  9. Go to Step 1.

2 years later: What the hell was this clever parameter-driven multi-nested process for? Why didn't I just code it straight up?

For me, organizing complex code has always been a delicate balance between readibility and cleverness.

Don't remove enough lines of code and it's too much to navigate. Remove too many and it's too much to comprehend.

Organization + Cleverness + Balance = Long Term Maintainability

From [1]:

> Nobody is really smart enough to program computers. Fully understanding an average program requires an almost limitless capacity to absorb details and an equal capacity to comprehend them all at the same time. The way you focus your intelligence is more important than how much intelligence you have.

> At the 1972 Turing Award lecture, Edsger Dijkstra delivered a paper titled "The Humble Programmer." He argued that most of programming is an attempt to compensate for the strictly limited size of our skulls. The people who are best at programming are the people who realize how small their brains are. They are humble. The people who are the worst at programming are the people who refuse to accept the fact that their brains aren't equal to the task. Their egos keep them from being great programmers. The more you learn to compensate for your small brain, the better a programmer you'll be. The more humble you are, the faster you'll improve.

[1] http://blog.codinghorror.com/why-im-the-best-programmer-in-t...

I've always described myself as too dumb to write clever code.

I try to imagine that 6 months from now I'll have a critical bug in whatever I'm writing and so I write it for that.

Apropos of nothing, I'd love an editor that could completely hide (not collapse) comments, as when something I write them I don't need them so hiding them would be great but showing them but been able to toggle them on later would be awesome.

I find that the older I grow as a programmer the less I enjoy cleverness. There's never a good enough reason to use clever algorithms over boring ones. In fact, most of the refactors I did over the past year was to 'undo' cleverness (thankfully those programmers are no longer working here!)

In terms of performance you sometimes need to do less conventional things, but that's precisely where documenting WHY you're doing it that way is so important.

The small bits of performance you're going to get isn't worth the maintenance hell it's going to cause.

> The small bits of performance you're going to get isn't worth the maintenance hell it's going to cause.

I've always said, that's the difference between programming and developing.

Clever and magic are very often bad.

In ideal code, functionality and all paths of execution flow should be as visible as possible and easy to reason about.

Unnecessary abstraction should be avoided.

Naming should be consistent and sufficiently descriptive.

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan

Still too many lines of code!

Being organised has nothing to do with fewer lines of code. A 10 line script can be disorganised and a million LoC app can be well organised. What makes code organised is things not being tangled up together - having well encapsulated logical modules that do one thing (or a set of related things), with a well designed API to get each bit to work with the other bits.

I've found that the more I write testable code the better organised my code gets. Automated testing forces you to design maintainable, organised code - because your test suite really won't cope with disorganised code.

> I've found that the more I write testable code the better organised my code gets. Automated testing forces you to design maintainable, organised code - because your test suite really won't cope with disorganised code.

It can, but it will get out of hand really quickly. Worst case scenario the test suite becomes so tightly bound to the implementation that is becomes a part of it. This forces the test suite to be rewritten in the implementation changes, this is the worst case scenario and must be avoided at all costs.

An insight I've had here is to write the code the same way I would have as if I'd done red green refactor tdd, but then add only the essential unit tests at the end. Works very well and is much much faster, but obviously you'd have to have done a lot of red green refactor tdd previously in your career or on side projects to really know what testable code looked like. Reading Working With Legacy Code by Michael Feathers may be a shortcut to that knowledge as well.

There are two kinds of cleverness, and both require balance in their application.

The first is the more obvious kind: exploiting various conditions that occur in your code, in order to come up with a nonstandard solution. E.g. using if (x mod 15 == 0) in fizzbuzz. The problem with this kind of cleverness is that it's hard to understand the code, and it breaks whenever the conditions it relies on stop holding.

The second kind of more subtle. It is where you organize code to properly express the nature of the problem, but this organization is itself conceptually complex. A typical example is using C++ templates where they make logical sense, but they make the code that much harder to read.

The second kind is where balance is needed most. If you use too little cleverness (or maybe too much humility), you end up with spaghetti code, or code where all the organization is done via convention instead of enforced by the compiler. If you use too much cleverness, you end up with code that is hard to read, and brittle, since so many assumptions are embedded in the code.

I always liked Linuses quote about bad programmers worrying about the code and good programers worrying about the data structures. I often find reorganizing my data models can cut down on a lot of code.

Reply on news.ycombinator.com