←back to thread

873 points belter | 4 comments | | HN request time: 0.001s | source
Show context
latexr ◴[] No.42947128[source]
> Most won't care about the craft. Cherish the ones that do, meet the rest where they are

> (…)

> People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things.

What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not necessarily the ground truth.

What you’re essentially saying is “cherish the people who care up to the level I personally and subjectively think is right, and dismiss everyone who cares more as insane weirdos who cannot prioritise”.

replies(64): >>42947180 #>>42947185 #>>42947187 #>>42947236 #>>42947241 #>>42947385 #>>42947445 #>>42947527 #>>42947549 #>>42947550 #>>42947776 #>>42947831 #>>42947871 #>>42948239 #>>42948415 #>>42948549 #>>42948597 #>>42948603 #>>42948816 #>>42948889 #>>42949006 #>>42949205 #>>42949721 #>>42949848 #>>42950103 #>>42950597 #>>42951017 #>>42951417 #>>42951446 #>>42951888 #>>42951983 #>>42952213 #>>42952396 #>>42952951 #>>42952983 #>>42953095 #>>42953185 #>>42953920 #>>42956368 #>>42956749 #>>42956933 #>>42957674 #>>42957827 #>>42958578 #>>42959426 #>>42959516 #>>42959604 #>>42959832 #>>42959898 #>>42960492 #>>42961062 #>>42961380 #>>42962073 #>>42962322 #>>42962379 #>>42962529 #>>42962821 #>>42963089 #>>42963205 #>>42963258 #>>42964858 #>>42964922 #>>42966606 #>>42974258 #
hliyan ◴[] No.42947527[source]
There's another way to look at this: if you consider the school of thought that says that the code is the design, and compilation is the construction process, then stressing over code style is equivalent to stressing over the formatting and conventions of the blueprint (to use a civil engineering metaphor), instead of stressing over load bearing, material costs and utility of the space.

I'm fond of saying that anything that doesn't survive the compilation process is not design but code organization. Design would be: which data structures to use (list, map, array etc.), which data to keep in memory, which data to load/save and when, which algorithms to use, how to handle concurrency etc. Keeping the code organized is useful and is a part of basic hygiene, but it's far from the defining characteristic of the craft.

replies(20): >>42947540 #>>42947576 #>>42947599 #>>42947739 #>>42947770 #>>42947773 #>>42948888 #>>42949256 #>>42949591 #>>42949745 #>>42951412 #>>42951450 #>>42952786 #>>42955720 #>>42956620 #>>42957839 #>>42958226 #>>42959595 #>>42961043 #>>42964637 #
Retric ◴[] No.42947599[source]
> the formatting and conventions of the blueprint

Some of those formatting conventions are written in blood. The clarity of a blueprint is a big deal when people are using it to convey safety critical information.

I don’t think code formatting rises anywhere close to that level, but it’s also trying to reduce cognitive load which is a big deal in software development. Nobody wants to look at multiple lines concatenated together, how far beyond that you take things runs into diminishing returns. However at a minimum formatting changes shouldn’t regularly complicate doing a diff.

replies(8): >>42947699 #>>42948411 #>>42948818 #>>42949115 #>>42950567 #>>42951552 #>>42952254 #>>42961444 #
hliyan ◴[] No.42947699[source]
I 100% agree. The problem is that after a half a century, software engineering discipline has been unable to agree on global conventions and standards. I recently had an experience where a repair crew was worried about the odd looking placement of a concrete beam in my house. I brought over the blueprints, and the technician found the schedule of beams and columns within seconds, pinpointed the beam and said, "Ah, that's why. We just need to <solution I won't go into>". Just then it struck me how we can't do this in software engineering, even when the project is basically a bog-standard business app: CRUD API backed by an RDBMS.
replies(8): >>42947832 #>>42947976 #>>42951607 #>>42952836 #>>42955524 #>>42955652 #>>42963313 #>>42964672 #
1. skydhash ◴[] No.42947832[source]
That’s because the few hard rules you have to comply with have workarounds and matters rarely. In house construction, you have to care about weight, material degradation, the code, etc… there’s no such limitation on software so you can get something to work even if it’s born out of a LSD trip.

But we do have some common concepts. But they’re theoretical, so only the people that read the books knows the jargon.

replies(1): >>42949919 #
2. namaria ◴[] No.42949919[source]
I mean why should we expect software to have hard rules? Flexibility is the point, no?
replies(2): >>42950883 #>>42953330 #
3. HeyLaughingBoy ◴[] No.42950883[source]
No. Flexibility is a side effect. Sometimes it's a useful side effect, other times it bites you in the ass.
4. Ma8ee ◴[] No.42953330[source]
The rules are what make it flexible. The rules let me understand what the heck is going on in the code you wrote so I can change it. Code that is faster to rewrite from scratch isn’t flexible.