Hacker News Reader

Comment by rorrr | Hacker News Reader

Kudos to his manager for actually looking at the code and recognizing the problem. Maintainable code is extremely important. Just keep your code simple. Adding another layer of abstraction instead of writing a simple and readable loop (if the language doesn't have accumulators) is not a good solution.

I've seen this too many times. Smart developers write complex code, just because they can (and often it does make it shorter), but then mid- and junior-level developer struggle with it. So company has to spend more money on smarter developers.

Here's a relevant post by Linus:

http://thread.gmane.org/gmane.comp.version-control.git/57643...

View on HN

Whether your "simple loop" is actually simple depends on the complexity of the underlying problem. At a certain point, it takes less time to understand the abstraction + the code using that abstraction than to understand the fully-expanded code without the abstraction.

If you're just adding up the elements of an array, no big deal use a simple loop. If you're iterating through three lists of potentially unequal length processing some triplets and skipping others and returning some data structure based on that iteration, a raw loop is going to be anything but simple and readable while using an abstraction like CL's LOOP is going to result in something very manageable.

To give an empirical example off the top of my head, look at any compiler code written in C. Iterating over flow graphs is a big PITA because they're nested heterogenous structures (a procedure has basic blocks which has instructions which has uses and defs). You iterate over them a lot and a lot of iterations end up being complex triply-nested affairs. Nearly all compilers written in C use some sort of abstraction to deal with this complexity. Eg: GCC has a bunch of macros of the form FOR_EACH_ that use the pre-processor.

> Smart developers write complex code, just because they can (and often it does make it shorter), but then mid- and junior-level developer struggle with it.

You know, I can't help but be reminded of Harrison Bergeron when I read this. I'm waiting for the day when someone comes up with a handicap for programmers so that we can all write code with the same ability as the least intelligent and least experienced members of our teams.

Did it ever occur to you that there might be a method to smarter developers' madness? I mean, maybe they write code the way they do because, you know, they're smart and know something you don't?

"I'm waiting for the day when someone comes up with a handicap for programmers so that we can all write code with the same ability as the least intelligent and least experienced members of our teams."

Java? ;-)

Touché. I must admit that I've never thought of Java as something from Kurt Vonnegut, but the analogy is apt.

> Kudos to his manager for actually looking at the code and recognizing the problem.

In the majority of the cases however you deal with managers who lost understanding of anything but simple language constructs because all they did since becoming managers is management and no code development at all. At some point they start rejecting everything they don't understand. They justify their position by arguments of code clarity and maintainability. But they are misguided. To recognize readable and maintainable code you actually need to practice programming continually.

I dealt with such managers. They would tell me that a dozen of simple code lines are unreadable because they saw a new keyword they don't understand. But they would accept a hundred of code lines that do the same thing in which they can recognize all keywords. They wouldn't care about what the code actually does, nor they would care about what it takes to parse a hundred lines of spaghetti code.

It always fascinated me that some managers think they understand developing code better than developers they manage. I've had the best experience with managers that trust their developers to make decisions and the worst experience with managers that try to micromanage.

> Kudos to his manager for actually looking at the code and recognizing the problem.

Huh?

> My manager looked at the code and asked "Who's going to maintain this? How will they understand it?" That's not the first time I've encountered these questions. I heard it when I used function pointers in C. I heard it when I used templates in C++.

So essentially the manager bans the use of basic language features because they have hired incompetent programmers who shouldn't be working in the languages before understanding them. How exactly did the manager "recognize the problem"? The problem isn't that people use languages like they are supposed to be used, it's that they have made bad hires, which is not the competent programmers fault.

I agree. I suspect any manager who looks at code and says it is not maintainable would have a very different side of the story, that might sound something like, "We already had an accumulator that did exactly what was needed. It just used a named delegate. I told him to either use that, or refactor the existing code to use his new and get rid of the old one. Maintaining both is wasteful. He seemed to get in a tissy about it."

Sure that's one possibility. Some other things the manager might say:

* Whose idea was it to hire developers that are smarter than I am?

* Of course I told him not to use function pointers. You have to put programmers in their place from time to time. You know, show them who the boss really is.

* Function pointers? Are you serious? He could have put someone's eye out.

Reply on news.ycombinator.com