I don't think wood working per se gives you more flexibility than building software. It's wood working as an individual, not part of a team, so you can make your own decisions and not answer to anyone. If you were a one man software consultant you would have the same amount of autonomy.

:deep breaths:

And indeed that’s something I’d apply to software: both hobbyists and small companies are tempted to use professional tools (as in, intended for lots of engineers collaborating) for small projects or a low number of collaborators that don’t warrant such stringent rules.

Isn't this part of the problem? If the purpose of code is to be understandable, the important communications shouldn't also be subtle. Your intention that the extra empty line before a block of code signals "This is the important part" is likely to be entirely lost on a reader of the code (especially in a codebase where the formatting isn't consistent so those spare lines are littered everywhere). Much better to leave a comment saying "there's a subtle but important thing going on here".

This is a take I don't think I've seen before. Is someone actually mad prettier is changing their single quotes to double quotes? Are they mad some line is breaking at some word?

Certainly I've never been. I use linters / formatters even when I'm working solo because the mere concept of having to think where to break lines is meaningless disruption from the actual goals I have.

If you _really_ want to break a line somewhere, just add a comment in between and your linter will comply.

Shouldn't all the lines of code uploaded in a pull request be automatically formatted into the coding style preferred by the reviewer anyway? It should be like an automatic translation done by some bot or something.

Thank you for that: "linters" (but as a person's role, not as a tool).

Pretty sure that contributed to my early retirement from the industry. It didn't used to be that way — perhaps because there were fewer cooks; perhaps because of a more cavalier, cowboy-style approach to coding.

I definitely preferred the days of the open range....

For larger projects however, not having tooling set up that enforces certain consistency is an absolute showstopper for me. I'll either introduce it or I'll quit; I simply do not want to waste my time with developers squabbling over arbitrary formatting-choices or irrelevant coding-style-details that can easily be enforced by some tooling.

Of course, developer-experience is paramount. Meaning, the tooling must be easy-to-use and generally not stand in the way. Otherwise it can indeed create a lot of friction which will annoy everybody. But once this has been set up (properly!), it will make a lot of silly discussions and choices obsolete.

Consistency is dramatically overrated. We all read through comment threads on HN where each is written in it's own style and nobody has a problem understanding it. I read through open source repos all the time, which all have their own styles and which are often not self-consistent; my comprehension is not impaired. I have worked with teams that enforce linting with a religious fervor and teams where anything goes. The anything goes team is probably more productive and with a comparable rate of bugs (but I don't have the metrics to prove it). Personally, I don't feel like my comprehension is better or worse in one setting or the other.

The difference I do notice is that when there are no linters, nobody wastes time trying to figure out how to work around it for a few lines. A great example is Eigen matrix initialization through the stream operator overload [1]. You really want to manually format that so each row is on it's own line. If you use clang-format in such code, it will be littered with

    MatrixXf mat(2, 2);
    // clang-format off
    mat << 1, 2, 
           3, 4;
    // clang-format on

[1] https://eigen.tuxfamily.org/dox/group__TutorialAdvancedIniti...

Also it's helped keep unused garbage out of the codebase also, which people tend to leave in there otherwise.

Also prettier has helped in me no longer reviewing MRs where every single line shows up in a file because their local machine has a different tab indent set or a different way to handle newlines (like with or without carriage returns, IIRC).

Sure it styles some things that aren't my preference, but I don't have to do it myself, it just automatically changes it all, so I can deal with it.

And if something is especially annoying or causes issues, I can usually get an exception added to the configuration, at least on my current team.

Symptom of nothing better to do, I have found ;)

Hard to picture someone who values their time blocking PRs on tiny stylistic nits.

These days they are pretty good at preserving vertical separation if it already exists and adding it if it’s missing.

This is why woodworking is actually a poor analogy for software development. A better analogy is carpentry. And when it comes to carpentry, it is much more important to ensure whatever you're building is extensible or follow certain specs. The cabinets you make, for example, need to fit into a certain space under or over the counter, and need to be homogenous to a large extent.

For hobby or artisanal pursuits, homogeneity isn't the goal. Often the uniqueness is a feature. But for mass production or large coordinated efforts, uniqueness is a bug. You don't want your car to be manufactured by someone who just felt like a 3mm panel gap felt more right than the 4mm gap the specs called for. Standardization makes coordination easier and that's why some products are better when they are homogenous while others are better when they're allowed to be "creative."

They would if their woodworking projects spanned decades and involved thousands of other woodworkers.

If you use a programming language that affords some guarantees like Haskell or even just C#, people seem to be less interested in linters.