Cold Showers • Hacker News Board

Re: Cold Showers

#361

Post by ehnto » Tue, Jun 21, 2022, 2:57 AM UTC

camgunz wrote: post #352

ehnto wrote: post #309

Earlier quoted context omitted.

Maybe I could get it done in the same time, but I'd be really annoyed, and less certain what things are intended for. An IDE can really carry the burden figuring out what things are, but you're going to lack some context. Usually it doesn't matter WHAT things are, I need to know WHY you have a variable, and what it's intended use is. That can be explained in the variable name a lot of the time. I have the same argume…

> Why did the API endpoint change? ... This stuff all feels better suited for a commit message. Conversely if I found all this in code I'd delete it. I'm an almost never comment person (I use them when things are weird or inconsistent, but otherwise view them as noise) but I've been persuaded by John Ousterhout that code cannot adequately describe abstractions, and you need comments to fill in the gap. Similarly with…

I also almost never comment code architecture and logic, but code is usually solving some business problem and documenting that in code is just not always reasonable or even possible. Also bugfixes and compat related naming in live software gets you things like fixForObserverOverrideBugIn364

For me it's more about not wasting people's time. Names are opportunities to divulge minor contextual information that you spent time figuring out, and it would be going backwards to then compress that into shortened names.

i for index is fine, but if you have nested loops or multiple loops it gets annoying.

Re: Cold Showers

#362

Post by 9935c101ab17a66 » Tue, Jun 21, 2022, 9:25 AM UTC

jamal-kumar wrote: post #333

jollybean wrote: post #323

Earlier quoted context omitted.

Maybe you need an MBA to help you understand that in many cases, it's incredibly more cost effective to use the cloud, because the marginal savings that could be achieved with on prem hardware are dwarfed by the cost of labour, and especially lost opportunity cost. For most things 'local prem' is an optimization that usually needs on some degree of scale to justify, or, you have a peculiar setup i.e. a couple of well…

I think the big difference that I'm seeing here is that I don't live in a country where engineers demand +100000/yr salaries

I love that you say “demand” like somehow engineers are forcing companies at gun point to pay their salaries. No, stop. It’s the result of market pressure and actual engineering degrees + peng certifications being hard to acquire and desirable.

What a glib and senseless follow up.

Re: Cold Showers

#363

Post by camgunz » Tue, Jun 21, 2022, 2:43 PM UTC

ehnto wrote: post #361

camgunz wrote: post #352

Earlier quoted context omitted.

> Why did the API endpoint change? ... This stuff all feels better suited for a commit message. Conversely if I found all this in code I'd delete it. I'm an almost never comment person (I use them when things are weird or inconsistent, but otherwise view them as noise) but I've been persuaded by John Ousterhout that code cannot adequately describe abstractions, and you need comments to fill in the gap. Similarly with…

I also almost never comment code architecture and logic, but code is usually solving some business problem and documenting that in code is just not always reasonable or even possible. Also bugfixes and compat related naming in live software gets you things like fixForObserverOverrideBugIn364 For me it's more about not wasting people's time. Names are opportunities to divulge minor contextual information that you spen…

Oh yeah totally get it. I feel like our area of agreement is that whenever you're writing code, you should be writing it to be read and understood, not simply executed. Whether that's through naming, comments, docs, structure, etc.

An example of a comment I'd value is something like a "why bother" at the top of a file doing a lot of in-depth algorithmic work, like a note accompanying a Chesterton's Fence. It makes some sense (though I quibble with this all the time) to design things so as to be as understandable as possible, and then only start optimizing when necessary, and when that happens it's useful to put a "this is pretty complicated, but it cuts CPU time down by 30%. [here](link) are the tests, and [here](link) is the naive equivalent implementation".