←back to thread

873 points belter | 3 comments | | HN request time: 0.784s | 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 #
skydhash ◴[] No.42947770[source]
The value of software is both what it does now (behavior), and what you can get it to do later (structure). What you described as design and the compiled artiface is the behavior.

The craft is what gives you future choices. So when people cares about readability, writing tests, architecture, they’re just making easy for them to adjust the current behavior later when requirements change. A software is not an house, it doesn’t get build and stays a certain way.

replies(1): >>42949208 #
skeeter2020 ◴[] No.42949208[source]
experience gives you some possible ideas for how it will be used in the future, but after a long time I'm coming to the position you're fooling yourself if you think you can predict where with any accuracy. It's still valuable and important to try, just not as critical to be right as I used to think. Example: I've completely flip-flopped from interface simplicity to implementation simplicity.

I agree that a house is a bad analogy, for your reasons and because you can "live" in software that as a building would not be fit for human habitation.

replies(1): >>42949995 #
1. skydhash ◴[] No.42949995[source]
You have to be pragmatic about it, balancing between the speed of only implementing the now and the flexibility of taking care of the future. It's not predicting, mostly it's about recognizing the consequences of each choice (for later modifications) and and either accepting it or ensuring that it will not happen.
replies(1): >>42950841 #
2. dowager_dan99 ◴[] No.42950841[source]
> It's not predicting, mostly it's about recognizing the consequences of each choice (for later modifications)

This is the exact trap I'm describing. It sounds very reasonable, but how is it not prediction when you're asking people to "recognize the <future> consequences of each choice"? You have very little to no understanding of the context, environment or application of today's creations. Smart, experienced people got us into the current microservice, frontend JS, "serverless" cloud messes.

replies(1): >>42951007 #
3. skydhash ◴[] No.42951007[source]
Risk management is a fact of all activities. It's not predicting that some thing is going to happen, but it's evaluating that if we can afford the consequences if it really happens. If we can, let's go ahead with the easy choice. If we cannot, let's make sure that it won't affect us as much.

> Smart, experienced people got us into the current microservice, frontend JS, "serverless" cloud messes.

Those are solutions to real problems. The real issue is the cargo cult, aka "Google is doing it, let's do it too". If you don't have the problem, don't adopt the solution (which always bring its own issues). It's always a balancing act as there is no silver bullet.