[Tainnor]

I'm not looking for rigorous proof, but these are just cherry-picked example quotes instead of a coherent argument. You could just as well quote people who have experience dealing with code that is "not clever enough", e.g. 1000 line files without any internal structure. What does that show?

Writing code is about tradeoffs and not about pithy truisms lime "code should be obvious".

[Mawr]

I'm afraid "writing code is about tradeoffs" is just as much of a truism. It's not going to help anybody write beter code. You need to get into the specifics.

[Tainnor]

The difference is that I didn't presume I could give anyone easy advice about how to write good code.

The only thing you can do is gain lots of experience, constantly question if there are better ways to do things, read about ideas others have had (without getting religiously attached), make your own mistakes, hopefully learn from them, overcorrect, then learn from your overcorrections and so on. I'm afraid there's not really an easier way.

On the other hand "write obvious code" makes it sound as if there's an easy way to do it, and everyone who doesn't write "obvious code" is just deluded, showing off, or something like that.

[bborud]

> On the other hand "write obvious code" makes it sound as if there's > an easy way to do it, and everyone who doesn't write "obvious code" > is just deluded, showing off, or something like that.

There is nothing easy about writing code that is obvious to other people. After all, the point of the exercise is how you communicate ideas clearly to people with the goal of amplifying their productivity. That takes time, empathy, and a willingness to study how other people understand things and accepting when you are not getting through to them.

Most programmers are not good at this. Worse yet, most programmers won't try to be good at this and instead go looking for simple truths. At best, most programmers obsess over "best practices" without really asking themselves if these are the best way to communicate a given idea or if there is a clearer way. To dare to do what's better, yet respect when "better" isn't necessarily better for other people.

(Erik Spiekermann, a designer of typefaces, made an observation that is useful with regard to the last statement. Erik has no love for the font Arial. He doesn't think it is a very readable font. However, he also points out that it is a font most people are so familiar with that even though he thinks its design is poor, it is actually a good functional choice because so many people are used to it that their familiarity makes it easy to read text typeset in Arial).

If your attitude is that it isn't worth trying because it isn't easy to do, then I'm sorry for you, but I think your value to an employer will be limited to only the output you can produce yourself. The biggest potential for a programmer is in their ability to amplify other programmers. And that starts with being able to communicate clearly. Both at the micro level, in code, and at the macro level, in terms of clear structure, abstraction and architecture.

The best way to ensure you don't evolve into a programmer who is able to amplify other programmers, and provide value beyond your own immediate output, is to not even try.

[Tainnor]

> If your attitude is that it isn't worth trying because it isn't easy to do

I haven't said that and I don't appreciate you insinuating that I don't care about writing good code.

[bborud]

Before you get too upset I think you should practice what you preach. I can only judge from what you write. I don't know you. And you have made assumptions about what I think or say, which I then politely, and at some length, have tried to clarify and explain to you. When you continue to argue in a manner that, at least to me, signals you are not interested in actually understanding what I'm saying: that's on you. You are obviously offended, and I would probably care, if it wasn't for your whiny, self-righteous attitude.

[bborud]

So if it isn't about trying to make things obvious, what do you think the goal is?

[Tainnor]

Huge code bases are never gonna be "obvious". It's all about optimising for a balance of tradeoffs.

[bborud]

So you claim that beyond some magic size limit a codebase cannot be easy to understand. Well, quantify it. At what number of lines of code does a codebase pass from the domain where it is possible to easily understand it to where it is impossible?

I suspect you didn't pay any attention to what I wrote about how people go about ensuring that large codebases maintain readability. That saddens me a bit because it means you probably aren't interested in learning anything.

[Tainnor]

This is just an incredibly bad faith reply, and an insulting one at that. I don't know why you felt the need to cross into personal territory, but I will make a mental note not to engage with you again.

PS, please check my comment history before claiming that "I'm not interested in learning anything".

[bborud]

Practice what you preach.