←back to thread

Software development topics I've changed my mind on

(chriskiehl.com)
873 points belter | 7 comments | 05 Feb 25 09:50 UTC | HN request time: 0.002s | source | bottom
Show context
latexr ◴[05 Feb 25 11:39 UTC] 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 ◴[05 Feb 25 12:26 UTC] 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 #
1. asdajksah2123 ◴[05 Feb 25 15:23 UTC] No.42949745[source]▶
> stressing over the formatting and conventions of the blueprint (to use a civil engineering metaphor)

This is incredibly important.

This is the kind of stuff that prevents shit like half the team using metric and the other half thinking they're imperial, or you coming up with the perfect design, but then the manufacturer makes a mirrored version of it because you didn't have the conventions agreed upon.

replies(1): >>42950046 #
2. tehologist ◴[05 Feb 25 15:39 UTC] No.42950046[source]▶
Imperial vs Metric is a hard requirement not a convention or formatting. I have a co-worker who wants everything to be a one liner, doesn't like if/else statements, thinks exception handling is bad and will fail a code review over a variable that he feels isn't cased properly.

This makes code reviews super slow and painful, it also means you aren't focusing on the important stuff. What the code actually does and if it meets the requirements in functionality. You don't have time for that stuff, you are too busy trying to make this one person happy by turning an if else into a ternary and the end of sprint is a day away.

replies(2): >>42950802 #>>42952573 #
3. atq2119 ◴[05 Feb 25 16:23 UTC] No.42950802[source]▶
> will fail a code review over a variable that he feels isn't cased properly

Many projects have fairly strict rules about identifier naming conventions, so this doesn't feel so far fetched to me.

The example about if/else vs ? : is pretty damning though.

replies(1): >>42952653 #
4. plorkyeran ◴[05 Feb 25 18:03 UTC] No.42952573[source]▶
If a reviewer is regularly rejecting PRs because the variable names have incorrect capitalization then that's a problem with the author, not the reviewer. That is the incredibly basic shit you decide on at the start of a codebase and then follow regardless of your personal thoughts on what scheme is preferable.

If/else vs ternaries is something where consistency is a lot less important, but if you know that a team member has a strong preference for one over the other and you think it's unimportant then you should just write it how they prefer to begin with. Fight over things you think are important, not things that you think don't matter.

replies(1): >>42954115 #
5. mindcrime ◴[05 Feb 25 18:08 UTC] No.42952653{3}[source]▶
Sure, but if there are actual rules, agreed to and accepted by the entire team (as opposed to one guy's idiosyncratic preferences) then there should be a commit-hook to run the code through a linter and reject the commit if the rules are violated.
replies(1): >>42964361 #
6. withinboredom ◴[05 Feb 25 19:50 UTC] No.42954115{3}[source]▶
wtf... no.

I worked with a guy where you would try to predict what he would bitch about next. In this example, you would write it as a ternary so you don't have to hear about it ... and he'd suggest it be an if-else statement.

Nobody fucking cares which one it is; is it readable? That's the real question. Your preference of which version of "readable" it is only applies when you are the author. If you're that picky about it, write it yourself. That's what we eventually did to that guy after the team got sick of it. Anytime he'd complain about something like that, we would invite him to write a PR to our PR, otherwise, get over it. Then, we would merge our PR before he could finish.

He eventually got fired for no longer able to keep up with his work due to constantly opening refactor PR's to the dev branch.

7. tisdadd ◴[06 Feb 25 17:11 UTC] No.42964361{4}[source]▶
Yes indeed. I'm a fan of getting the team to pick an already existing lint ruleset and then doing this. You can also set to only lint changed files if you want a gradual change over in existing codebase.