Hacker News Reader

Comment by earthboundkid | Hacker News Reader

> Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

— Linus Torvalds

That remark from L. Torvalds is, I think, about how to approach problem solving. I'm sure he does have some opinions about code style and organization, but I feel that they would be shelved under a different conversation.

Programming is ultimately about reading and transforming data. When presented a problem, the bad programmer (presumably not well versed in DS theory) thinks of it first in terms of "steps to reach a solution". Whereas the more skilled programmer is able to identify which set of DS is a good match to a specific problem. That is, which combination of structures allow for an efficient access and manipulation of the data in the context of the problem at hand. The implementation then stems from that insight.

Obviously this skill is mostly valuable in performance critical code, which the bulk of our trade generally doesn't intersect with. And in an age of fast processors and abundant memory, it's common to see O(N) data structures applied to O(1) problems and barely anyone notices the cost. Thus keeping us in the comforting illusion that we're better programmers than we actually are.

I'm not sure what exactly Linus means by this, but I read this as: for good programmers, coding is about managing data structures and their relationships whereas bad programmers are more concerned with just getting the thing to work.

I think it's more that bad programmers focus on surface details like code style. All too often I've seen a code review of a complex feature get derailed by nitpicking of inconsequential things like variable names, formatting, etc.

I rarely comment on code style for this reason. I want the review to focus on functionality, not style. I don't really believe the notion "imperfect code style is a code smell" anyway.

> I don't really believe the notion "imperfect code style is a code smell" anyway.

Blaming developers for something that can be automated? Yeah, something is off here, though not necessarily the review.

> nitpicking of inconsequential things like variable names

To me it sounds like a good thing when there's nothing else to comment on. Making code more readable is a win for everybody.

I have a contrary view on code style. If there's no semblance of consistency to the code you write, how can you possibly formulate a consistent and sensible architecture?

The style itself is inconsequential, but no consistent style is a red flag to me.

> how can you possibly formulate a consistent and sensible architecture?

Similar arguments could be made about actual architecture: "If you can't have well-designed and consistent houses, how can you possibly have a well-designed city?"

The best architectures I've seen, by far, had the worst code. Code is not a systemic level issue. The way the pieces fit together is.

A sad fact of good architectures is they actually enable bad code to exist without severe consequences, because that badness is localized.

Yes. For example, a distributed system composed of various microservices, where the microservices can use different code styles, different programming languages, be maintained by different teams, etc.

Variable names are the nouns of programming though. It’s not really related but I think having an “editor” try to read your text and give you improvement ideas is not “shallow”. The code is there for programmers to read and reason about so optimizing for “easy to load into your brain” code is important too.

let c = ... versus let customer_address = ... can save a lot of sanity throughout the years

useful variable names are absolutely a win though

I check both when doing reviews. Style and "cleanliness" of the code is important as other people are also expected to work with it. Also I follow the saying that code is more often read than (re)written, so that should not be neglected.

Structure of the code, as in relationship of classes, data flow and high level design is also important and checked during review.

Variable names are the only thing that can reasonably guide you in time of need. Thinking that variable names are not all that important is not a good take.

there are two kinds of programmer: one thinks code is an artifact and that you can produce quality code. the other thinks code is excrement and only exists as a waste product necessitated by the immaturity of our information modeling tools.

My take is that bad programmers represent information as data as an afterthought.

> what exactly Linus means by this

“I’m a good programmer”, I imagine. I wouldn’t disagree :p

Reply on news.ycombinator.com