Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software development topics I've changed my mind on

chriskiehl.com

Post reply on HN
Print view View original

401–410 of 788 posts

Re: Software development topics I've changed my mind on

#401

Post by zelphirkalt »

hliyan wrote: post #68
latexr wrote: post #22

> 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 neces…

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 anythi…

And some specific people with lots of experience in teaching as well as in developing real life useful systems will tell you, that code is first and foremost written for people to understand, and only incidentally for a computer to run. Human understanding of what is going on is the one most important thing. If we do not have that, everything else will go to shit.

Re: Software development topics I've changed my mind on

#402

Post by afavour »

latexr wrote: post #22

> 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 neces…

Maybe I'm projecting my own views here but I interpreted those two statements as being about different things: the finished product vs the process that gets you there.

I care deeply about the end result that is presented to the user who has no idea what code even looks like. How we put together the UI. How we load data to minimize delays. That's "the craft" to me.

I care much less about code style, linting etc. that no-one other than a small group of developers will ever see. To a certain extent the latter enables the former. But I've often witnessed the latter being valued over the former and that's where things start to go wrong.

Re: Software development topics I've changed my mind on

#403

Post by daxfohl »

Abstractions are a failure in most libraries too. Invariably something will come up that breaks the abstraction. Either new instances come up that don't quite match, or clients want new functionality that doesn't apply to all instances, or whatever.

I've come to the conclusion that in almost all cases, you should avoid providing any abstraction from your own library / service, and let consumers figure out what abstraction makes sense in their domain. By stipulating the abstraction, you're robbing your consumers of the ability to make things work the way they want, and painting your own thing into a corner.

When you build the abstraction, it seems like you're doing your consumers a favor. But that favor is short lived as the abstraction changes and breaks your consumers.

Re: Software development topics I've changed my mind on

#404

Post by 708145_ »

latexr wrote: post #22

> 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 neces…

It is a fine balance, and everyone that doesn't "drive the same speed" as me, frustrates me.

Re: Software development topics I've changed my mind on

#405

Post by ryandrake »

hliyan wrote: post #68
latexr wrote: post #22

> 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 neces…

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 anythi…

Yea, I've always considered craftsmanship to be about paying attention to the details and making everything high quality--even the things that the end user will never see, but you know are there. The Steve Jobs quote sums it up nicely:

> "When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through."

Re: Software development topics I've changed my mind on

#406

Post by asa400 »

kod wrote: post #348
asa400 wrote: post #271

Earlier quoted context omitted.

And that’s totally fine! But there is no correlation whatsoever between writing on a typewriter or using a fountain pen (or the physical experience of writing generally) and the quality of the writing. None. There is nothing to support this in either writing or programming, at all. For every software craftsman out there obsessing over formatting, editor layout, linters, line length, there is an ancient, horrifyingly…

> But there is no correlation whatsoever between writing on a typewriter or using a fountain pen (or the physical experience of writing generally) and the quality of the writing I heard neal stephenson say that he writes using a pen rather than a wordprocessor specifically because it does affect the quality of the writing. Because he handwrites slower than he types, he does more thinking and editing in his head rathe…

And if that works for him then he should do that, and I have no problem with that at all. I just don't think there is anything one can say about writing tools that _generalizes_ to writing quality, and the same applies to the type of conversations programmers often engage in like "functions need to be short!" or "line length MUST be less than 90 or else I will reject this PR!" or "dark mode is objectively better to write code in" etc.

I have no problem whatsoever with people having preferences, I just think people mistake preferences for proof.

Re: Software development topics I've changed my mind on

#407

Post by stackskipton »

vaylian wrote: post #135
Tade0 wrote: post #41

> Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy My feeling is that a lot of negativity towards the frontend stems from assuming that the entire field is like React and its community. It's really not like that.

The much bigger problem is that you not only have to deal with the technical challenges, but also the visual design challenges where non-technical people have all kinds of opinions that you have to deal with. Things get really nasty once you have to implement features that emulate non-web functionality like right-click menus and the UI becomes an inconsistent mess.

Visual Design Challenges is one I hear most frontend developer complain about. I explained a queen duck (https://bwiggs.com/notebook/queens-duck/) to one of them and he started doing that several times in his project. If you look at this git repo, there would be commits called "queen duck" right before he would demo so he could get feedback about the "mistake" he made, revert the commit and move on with his life.

Re: Software development topics I've changed my mind on

#408

Post by dasil003 »

Retric wrote: post #77
hliyan wrote: post #68

Earlier quoted context omitted.

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 anythi…

> 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 concatenat…

Software, being arbitrary logic, just doesn't have the same physical properties and constraints that have allowed civil engineering and construction code to converge on standards. It's often not clear what the load bearing properties of software systems are since the applications and consequences of errors are so varied. How often does a doghouse you built in your backyard turn into a skyscraper serving the needs of millions over a few short years?

Re: Software development topics I've changed my mind on

#409

Post by VonGallifrey »

hliyan wrote: post #84
Retric wrote: post #77

Earlier quoted context omitted.

> 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 concatenat…

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, th…

> I brought over the blueprints, and the technician found the schedule of beams and columns within seconds

Is that really an example of the standardization you want? It shows that the blueprint was done in a way that the technician expected it to be, but I am not sure that these blueprints are standardized in that way globally. Each country has its standards and language.

If an architect from a different country did that blueprint, I would bet that it would be significantly different from the blueprint you have.

Software Engineering doesn't have a problem with country borders, but different languages would require different standards and conventions. Unless you can convince everyone to use the same language (which would be a bad idea; CRUD apps and rocket systems have different trade-offs), I doubt there could be an industry-wide standard.

Re: Software development topics I've changed my mind on

#410

Post by oasisbob »

gmueckl wrote: post #366
DarkPlayer wrote: post #225

Earlier quoted context omitted.

> However at a minimum formatting changes shouldn’t regularly complicate doing a diff. If the code needs to be reformatted, this should be done in a separate commit. Fortunately, there are now structural/semantic diff tools available for some languages that can help if someone hasn't properly split their formatting and logic changes.

Reformatting comitts still leaves the issue that you deprive yourself of any possibility to reliably diff across such commits (what changes from there to there?) Or attribute a line of code to a specific change (why did we introduce this code?). What we should have instead is syntax-aware diffs that can ignore meaningless changes like curly braces moving into another line or lines getting wrapped for reasons.

Not a full solution, but .git-blame-ignore-revs can help, and is automatically supported by GitHub:

https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa9...

Post reply on HN