Tips like "don't try to write smart code" are often repeated but useless (not to mention that "smart" here means over-engineered or overly complex, not smart).

1. Somebody verifies with the users that speed is actually one of the most burning problems.

2. They profile the code and discover a bottleneck.

3. Somebody says "no, but we shouldnt fix that, that's premature optimization!"

Ive heard all sorts of people like OP moan that "this is why pieces of shit like slack are bloated and slow" (it isnt) when advocating skipping steps 1 and 2 though.

I dont think they misunderstand the rule, either, they just dont agree with it.

Did pike really have to specify explicitly that you have to identify that a problem is a problem before solving it?

Sometimes this is too late.

C++98 introduce `std::set` and `std::map`. The public interface means that they are effectively constrained to being red-black trees, with poor cache locality and suboptimal lookup. It took until C++11 for `std::unordered_map` and `std::unordered_set`, which brought with them the adage that you should probably use them unless you know you want ordering. Now since C++23 we finally have `std::flat_set` and `std::flat_map`, with contiguous memory layouts. 25 years to half-solve an optimisation problem and naive developers will still be using the wrong thing.

As soon as the interface made contact with the public, the opportunity to follow Rob Pike's Rule 5 was lost. If you create something where you're expected to uphold a certain behaviour, you need to consider if the performance of data structures could be a functional constraint.

At this point, the rule becomes cyclical and nonsensical: it's not premature if it's the right time to do it. It's not optimisation if it's functional.

std::set/std::map got into trouble because they chose the algorithm first and then made the data model match. Rule 5 suggests choosing the right data model first, indicating that it is most important.

When building interfaces you are bound to make mistakes which end users will end up depending on (not just regarding optimization).

The correct lesson to learn from this is not "just dont make mistakes" but to try and minimize migration costs to prevent these mistakes from getting tightly locked in and try to detect these mistakes earlier on in the design process with more coordinated experimentation.

C++ seems pretty bad at both. It's not unusual, either - migration and upgrade paths are often the most neglected part of a product.

One setup I had was a vertical (hydroponic) window farm, which looked pretty great, but the roots start to get into the tubing, which I suspect could happen in the rack-mount system too. It also wasn't simple to just take out one plant for maintenance.

A small NFT (nutrient film technique) box has worked very well, requires very little material as substrate and is easy to maintain. Might get problematic if growing the same plants for over a year since the roots can grow a lot and basically partially outgrow the system so the flow of water starts being insufficient and therefore might need at least some trimming and replanting if some of the roots start to suffer.

I'm in the process of trying out deep water culture, which requires even less materials since there's no growing medium, just water, and roots are submerged so doesn't have the same issues as NFT. Probably has it's own problems, though, and air pumps can be loud!

Anyhow, most of my plants are in a passive hydroponics system. "Kratky method" is something a bit similar. I basically replaced soil in pots with clay pellets and manage watering so that I have to water every 2-3 days. Requires clay pellets as the substrate so needs a bit more effort up front, but doesn't require electricity and is more portable when using small/medium sized pots. Pellets can be reused (at least most of them). I also added a short tube for monitoring water level and possible maintenance if I need to wash / flush the pot with the plant in it.

Regarding fertilizing, I rarely do any accurate measurements anymore. I got a few pump bottles and measured how much fertilizer one push gets me and wrote on the bottles how many pushes per litre. I also eye-ball the water color a bit since I know how it should look like.

Oh, and the plants that have done well for me, and can grow for a long time with multiple harvests (so no lettuce): peppers, cherry tomatoes, cucumbers, trying some small strawberries

To be clear, I'm not asking this in some new age way, and I'm sure it's better than the amount of pesti/herbicides used traditionally (and the whole movement behind hydro/aquaponics is fascinating to me), just wondering if this is something you ever tried minimising with such setups?

Code tells you what is happening but it doesn't always do it so that it is easy to understand and it almost never tells you why something is the way it is.

An obvious example I have is CMake. I have seen so many people complaining about CMake being incomprehensible, refactoring it to make it terrible, even wrapping it in Makefiles (and then wrapping that in Dockerfiles). But the problem wasn't the original CMakeLists or a lack of comments in it. The problem was that those developers had absolutely no clue about how CMake works, and felt like they should spend a few hours modifying it instead of spending a few hours understanding it.

However, I do agree that sometimes there is a need for a comment because something is genuinely tricky. But that is rare enough that I call it "a comment" and not "literate programming".

As for convoluted, I don't find it harder than the other build systems I use.

Really the problem I have with CMake is the amount of terribly-written CMakeLists. The norm seems to be to not know the basics of CMake but to still write a mess and then complain about CMake. If people wrote C the way they write CMake, we wouldn't blame the language.

Even if you give them equal roles, self-documenting code versus commented code is like having data on one disk versus having data in a RAID array.

Remember: Redundancy is a feature. Mismatches are information. Consider this:

// Calculate the sum of one and one

sum = 1 + 2;

You don't have to know anything else to see that something is wrong here. It could be that the comment is outdated, which has no direct effects and is easily solved. It could be that this is a bug in the code. In any case it is information and a great starting point for looking into a possible problem (with a simple git blame). Again, without needing any context, knowledge of the project or external documentation.

My take on developers arguing for self-documenting code is that they are undisciplined or do not use their tools well. The arguments against copious inline comments are "but people don't update them" and "I can see less of the code".

Respectfully, if someone wrote code like this, I wouldn't want to work with them. I mean next step is "I copy paste code instead of writing functions, and in the comment above I mention all the other copies, so that it's easy to check that they are all doing the same thing redundantly".

> The arguments against copious inline comments are "but people don't update them" and "I can see less of the code".

Well no, that's not my argument. I have been navigating code for 20 years and in good codebases, comments are rare and describe something "surprising". Good code is hardly surprising.

My problem with "literate programming" (which means "add a lot of comments in the implementation details") is that I find it hard to trust developers who genuinely cannot understand unsurprising code without comments. I am fine with a junior needing more time to learn, but after a few years if a developer cannot do it, it concerns me.

1. Redundancy: "The code is what it does. The comments should contain what it's supposed to do. [...] You don't have to know anything else to see that something is wrong here." and specifically the concrete trivial (but effective) example.

2. "My take on developers arguing for self-documenting code is that they are undisciplined or do not use their tools well. The arguments against copious inline comments are "but people don't update them" and "I can see less of the code"."

> Respectfully, if someone wrote code like this, I wouldn't want to work with them. I mean next step is "I copy paste code [...]

This is an nonsensical slippery slope fallacy. In no way does that behavior follow from placing many comments in code. It also says nothing about the clearly demonstrated value of redundancy.

> I have been navigating code for 20 years and in good codebases, comments are rare and describe something "surprising".

Your definition of good here is circular. No argument on why they are good codebases. Did you measure how easy they were to maintain? How easy it was to onboard new developers? How many bugs it contained? Note also that correlation != causation: it might very well be that the good codebases you encountered were solo-projects by highly capable motivated developers and the comment-rich ones were complicated multi-developer projects with lots of developer churn.

> My problem with "literate programming" [...] is that I find it hard to trust developers who genuinely cannot understand unsurprising code without comments.

This is gatekeeping code by making it less understandable and essentially an admission that code with comments is easier to understand. I see the logic of this, but it is solving a problem in the wrong place. Developer competence should not be ascertained by intentionally making the code worse.

Fact is, you don't have any proof at all, you just have your intuition and experience. And I have mine.

> It also says nothing about the clearly demonstrated value of redundancy.

Clearly demonstrated, as in your example of "Calculate the sum of one and one"? I wouldn't call that a clear demonstration.

> This is gatekeeping code by making it less understandable

I don't feel like I am making it less understandable. My opinion is that a professional worker should have the required level of competence (otherwise they are not a professional in that field). In software engineering, we feed code to a compiler, and we trust that the compiler makes sure that the machine executes the code we write. The role of the software engineer is to understand that code.

Literate programming essentially says "I am incapable of writing code that is understandable, ever, so I always need to explain it in a natural language". Or "I am incapable of reading code, so I need it explained in a natural language". My experience is that good code is readable by competent software engineers without explaining everything. But not only that: code is more readable when it is more concise and not littered with comments.

> and essentially an admission that code with comments is easier to understand.

I disagree again. Code with comment is easier to understand for the people who cannot understand it without the comments. Now the question is, again: are those people competent to handle code professionally? Because if they don't understand the code without comments, many times they will just have to trust the comments. If they used the comments to actually understand the code, pretty quickly they would be competent enough to not require the comments. Which means that at the point where they need it, they are not yet professionals, but rather apprentices.

About voting with your wallet, I agree that it'd be best if companies actually had to pay for those externalities you mentioned. If you have spare money to spend, you can view not choosing the cheapest option as supporting or donating. That's what I sometimes do when e.g. buying locally instead of ordering from somewhere far for cheaper. I can get local faster and it's more convenient, so there's lazyness, but thinking about it as supporting helps me rationalize it further (and it is true). I don't think it really hurts me more than buying something else that I don't strictly need. I see indirect value in trying to uphold things I like.

Cooperation to the detriment of the individual in the animal world is exactly the same phenomenon in a much simpler system. That is widely and repeatedly evolved so we know for a fact that the game theory works out in a vacuum (ie without human cultural factors).

Any high trust cultural behavior is similar.

- Biology gives us the instinct to cooperate and the capacity for empathy.

- Capitalism provides the mechanism to scale that cooperation to millions of strangers.

- Institutions (laws/culture) provide the rules that prevent the "vacuum" from devolving into a state where the strongest exploit the weakest (which is actually what happens in nature when policing fails).

Therefore, in a capitalistic society, cooperation to the detriment of the individual (e.g., paying taxes, following labor safety rules) is not just a biological imperative; it is a social contract enforced by culture to allow the complex system to function. Without the cultural layer, the biological layer alone is insufficient to sustain a modern economy.

I do not think this should be analysed from the perspective of an individual but from the perspective of being part of a collective.

Individually we are pathetic naked monkeys, collectively we are mighty