10 ms·

> 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 m

by latexr 2y ago

> 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”.

hkwerf 2y ago
There is more than one type of people who stress over code style. There's the group who wants to discuss about how to style your code and then there's the group who wants to just use a common code formatter and be done with that. For example, I have objections to rustfmt's default style. I would never start discussions on rust projects about changing that to another formatter or changing its configuration. I definitely would carefully ask that people should really use rustfmt, though, if they don't do so yet.
- xnorswap 2y ago
  Edit: This comment was based on misreading the parent comment. I've left it up, but I should have been more careful. You've set yourself up to always be the outlier. To always need to have that discussion or tweak the rules on every project you work with. You've increased the overhead of onboarding anyone used to the default style. You've increased the overhead of you working on anyone else's projects that is more likely to have the default style. All of that is friction introduced because you haven't learned to live with the default style. Do I love that the default C# rules put a new line before the else block? No, but I've learned to live with it so that I can work on all manner of projects without fussing over that style option every time. By adhering to default rules, you never have to have the endless arguments such as tabs vs spaces again. ( Spaces won, and the tabbers got over it fairly quickly once it was the default in almost all formatters. )
  - hkwerf 2y ago
    I believe you may have misunderstood my comment, as I agree.
    - xnorswap 2y ago
      I apologise, I misread your statement as: "I would never start discussions on rust projects *without* changing that to another formatter" which changed the meaning entirely. I should have taken a moment to re-read what you wrote.
  - latexr 2y ago
    What I understood from your parent comment was the exact opposite, i.e. that they’re saying “I disagree with some of the default choices of the formatter (and so would prefer they were different) but I never voice those because it’s not worth it. However, I do think everyone should use something, whatever it is (even if the default style), as opposed to nothing”.
- maleldil 2y ago
  > I definitely would carefully ask that people should really use rustfmt, though, if they don't do so yet. If you don't already, you should run `cargo fmt --check` in CI and block PR merges until it passes. You can also run it in a pre-commit hook, but you can't be sure everyone will set that up. Automating such types of decision is great but moot if others have to opt into it.
- spjt 2y ago
  Code formatters are the best of both worlds. I despise Allman-style indentation for reasons I can't explain or justify, but if I have to work on a codebase that uses it, I can simply put hooks to reformat it to whatever the repo style is before commit.
OJFord 2y ago
It's not even more or less, it's just about different aspects. Consider a woodworker obsessing over sharp chisels - they don't all care beyond 'sharpish', or about the tools used to do so - but to some that's hugely important and how they are then able to do their best work.
- chasd00 2y ago
  To take it further some woodworkers are really tool hobbyists. They obsess over the tools and never really touch the wood they’re supposedly working. Same goes for software devs, I think about this when reading threads obsessing over AWS services, pipelines, build stacks, instead of writing software.
xnorswap 2y ago
The solution is to have computers enforce the code style. Pick a linter, pick a set of rules, and then forget about them. Things I beleive: - If you're picking up on code-style in PRs then your toolchain is backward. - If you're changing linting rules every month then you're focussed on the wrong things - It's better to have a consistent style than a perfect style
- secondcoming 2y ago
  This is what we did with clang-format on our code base. The result is occasionally ugly code and nobody is 100% happy but at least it's consistent.
  - maleldil 2y ago
    Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.[1] [1] https://go-proverbs.github.io/ https://go-proverbs.github.io/
    - maxwell 2y ago
      While everyone has a favorite ES Lint ruleset but few agree on which to use.
  - gpderetta 2y ago
    *cough*clang-format off*cough*
    - secondcoming 2y ago
      Ha, yes. I started doing that but then lost the will to continue.
- bayindirh 2y ago
  Yes. I love how gofmt has no settings, basically. Is this how you envisioned? Great. Now I don't have to think about optimizing it. Coincidentally, the choices they made are the choices I'd made, but it doesn't matter in the end.
jajko 2y ago
Not really. Obsessing over breaking lines after famous 80 chars in Eclipse was, is and will be idiotic to be polite. Surprisingly large amount of people were obsessed by this long after we got much bigger screens, if that was ever an argument (it wasn't for me). 2 spaces vs 4 spaces or tab. Cases like these were not that rare, even though now it seems better. That's not productive focus of one's (or team's) energy and a proper waste of money for employer/customer, it brings 0 added value to products apart form polishing ego of specific individual. Folks who care about the craft obsess (well within realm of being realistic) more about architecture, good use of design patterns, using good modern toolset (but not bleeding edge), not building monolithic spaghetti monster that can't evolve much further, avoiding quick hacks that end up being hard to remove and work with over time and so on. If you don't see a difference between those groups, I don't think you understood author's points.
- sfn42 2y ago
  I'd say avoiding long lines is one of the most important rules. I regularly have 2-3 files open side by side, I don't want to have to scroll sideways to read the code. 80 characters is a bit on the low end imo but I'd rather have the code be too vertical than too horizontal. Maybe 120-150 is a more reasonable limit. It's not difficult to stay within those bounds as long as you don't do deep nesting which I don't really want to see anyway because it's hardly ever necessary and it makes code more difficult to read.
  - cess11 2y ago
    Reading vertically is much faster than reading horizontally, so I think 80 is a good soft limit. In some contexts it's hard to not go over it sometimes, e.g. in Java where it's not uncommon with very long type and method names.
  - CrimsonRain 2y ago
    Functional code is more chained and need more space often. Descriptive names are better; tends to be longer. Buy ultrawide. 80 is for aholes who like to use small laptop and then force it on everyone else. 120/150 is reasonable. 200 is great.
WJW 2y ago
There's a correlation-is-not-causation issue here. Yes, most very good developers pay a lot of attention to details, as well as to the bigger picture. But there are a lot of mediocre to downright bad developers who think that paying a lot of attention to code style, linting rules and other minutia will make them better developers.
- bityard 2y ago
  My experience has been the opposite. Most mediocre to bad developers are so happy that their code works AT ALL that they pay little to no attention to things like sensible variable names and whitespace conventions. We sometimes call these things, "code smell."
  - fullstackchris 2y ago
    I've always thought on the contrary that "code smell" refers much more to the patterns used and not so much how it was formatted. Anyway, choosing a language that has automatic formatting (Go for example) renders about 80% of comments in this thread about "linting" and "formatting" and blah blah blah completely irrelevant.
bryanrasmussen 2y ago
as others note, most of this minutia can be automatically enforced. Anything that can be automated is not craft.
- marsovo 2y ago
  Heartily disagree. I have had to fight with others over automated formatting because it obscured intent or clarity. For example (C#) mandating `var`, mandating one and only one line of whitespace between lines of code, mandating the => syntax for single-line functions (instead of Function(vars) { ... } ) I would say, when to use one or the other of each of those options is very much a craft.
- __mharrison__ 2y ago
  Sadly formatting well written pandas and Polars code cannot be automated but current tooling.
aswerty 2y ago
In my opinion, I think the author is criticizing bike shedding [1] rather than meaningful decisions. Of course some people will differ on whether a decision is one or the other. But as a whole, not sweating the details is a good quality to have whatever road in life you are on. [1] https://en.wikipedia.org/wiki/Law_of_triviality https://en.wikipedia.org/wiki/Law_of_triviality
- The_Colonel 2y ago
  Everyone dislikes bikeshedding. But people disagree on which questions are bikeshedding and which aren't.
- bluGill 2y ago
  Details are important though. Some bikeshed type ideas spiral into very expensive changes. This is a large part of why US transit construction is so much more expensive - people asking for lots of little details which add up (large monument stations, bike paths done with the project... those things all add up) - the important safety details are left to experts, but only after they are told to build something far more expensive than needed. (this isn't a plea for brutalism architecture there are nice things you can do that are only minimally more expensive)
hliyan 2y ago
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.
- chrisjj 2y ago
  > the school of thought that says that the code is the design There's such a school?? Seriously??
- TickleSteve 2y ago
  architecture over implementation (for details).
- Retric 2y ago
  > 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.
  - hliyan 2y ago
    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.
bdcravens 2y ago
I think the line between minutiae and craft is drawn by the effect it has on the product you're creating. Method length makes your code more manageable, for example. Placement of line breaks, not so much. At the end of the day, we aren't paid to produce code, but working software that works today and is easy to change tomorrow.
- latexr 2y ago
  That is a purely commercial take of the matter. I don’t think it’s controversial to argue the artisans who stand out do so because they care for the craft itself. Spending an extra hour or two perfecting the shape of the armrest in the chair may not allow you to earn more money from that one commission, but it might improve your knowledge and skill and be slightly more comfortable to the sitter. If they comment on it and appreciate it, so grows your motivation and pride. Sometimes the code itself, and not its result, is the product. For example, when making tutorials the clarity and beauty of the code matters more than what it does. I’m not arguing for obsessing over code formatting, but pointing out the line between “master of the craft with extensive attention to detail” and “insane weirdo with prioritisation deficits focusing on minutiae” is subjective to what each person considers important. Most of us seem to agree that being consistent in a code base is more important than any specific rule, but that being consistent does matter. At the end of the day, we aren’t paid to eat healthily and taking care of our bodies either. But doing so pays dividends. Same for caring about the quality of your code. Getting in the habit of doing it right primes you to do it like that from the start in every new project. Like most skills, writing quality code becomes easier the more you do it.
  - bdcravens 2y ago
    > be slightly more comfortable to the sitter That's kind of my point: the end cannot see, or feel, minutiae. If they can, it's not minutiae. > Sometimes the code itself, and not its result, is the product. For example, when making tutorials the clarity and beauty of the code matters more than what it does. The code still isn't the product in that instance. It's the educational process. In many cases, clarity != beauty. This is why the best written tests often duplicate code, rather than being curated exercises in DRY. > we aren’t paid to eat healthily and taking care of our bodies either Yet programmers insist to be paid. Obviously taking time to grow on your own, on your own dime, is self-enriching for all the reasons you describe.
korijn 2y ago
Is it ironic that this comment has evoked a discussion on minutiae?
- deleted 2y ago
  [deleted]
hemant1041 2y ago
Interesting read!
raverbashing 2y ago
And that's why I don't care anymore Yup. Doesn't matter. Code style should be consistent and look nice, probably use the default without too much nitpicking. You have bigger fish to fry There are better things in life to worry about "Craft", most code goes to irrelevancy in 5 yrs. And if it doesn't it's fixable (amen for AIs) Try to sweat up every detail right off the bat and you go nowhere
oytis 2y ago
To me "craft" is about keeping code efficient, scalable, extensible, well-tested and documented. Code style is more about what naming convention to use, tabs vs spaces etc. - it's nice to have it consistent, but no need to spend more than 5 minutes arguing about it.
- ctxc 2y ago
  Tabs/spaces is a non-issue, agreed - IDEs handle it. But surely naming convention contributes to keeping code documented, extensible and efficient? A deviation from the norm leads to people thinking x does not exist in a large code base, leading to them implementing duplicate methods/functionality, leading to one instance evolving differently enough to cause subtle bugs but not enough to be distinct, or leading to one instance getting fixes the other does not etc? Sample size of 1, but I've seen it happen unfortunately.
lr4444lr 2y ago
Following non functional stylistic rules to the letter as if they were on the level of SQL injections or memory leaks isn't "craft". It's cargo culture weirdness. Sure, have a style and a linter. Be DRY. Don't lose your head over it though.
lijok 2y ago
Video game logic: Everyone worse than me is a noob. Everyone better than me has no life.
- alternatex 2y ago
  Today Steam gives us the option of verifying whether a certain player has no life. Only half joking.
  - danielbln 2y ago
    My favorite steam reviews are: "This game sucks, would not recommend." - playtime 800h
    - edm0nd 2y ago
      and on the flipside of this "This game sucks, would not recommend." - playtime 1.2h
- mtdrk 2y ago
  This is more like noob logic. Good players are eager to learn from those better than them.
ozim 2y ago
If you want to compare to artisans - they were stressing about details that customers see, details that customers don’t see were to cut corners on. Making fuss about indentation in code file is not artisanal. It is insane weirdo if we are charitable and if not clueless and childish.
- sumtechguy 2y ago
  Everyone wants a particular style. Except when they have to use someone elses style. Pick a style stick with it. Review it every 6 months to year to see if anything needs to be tweaked. If you hear 'we are professionals' you are about to see code that has 20 different styles and design patterns. I worked with one guy who could not make up his mind and changed the whole style guide about every 2-3 weeks. It royal made him mad the original style guide fit on a couple of postit notes. Me and two other engineers bashed it out in a 1-2 hour meeting at the start of the project (odd number of people to vote on anything). It came down to the fact he came in after the fact and had no say in it. Then proceeded to change everything. One week it was tabs everywhere then spaces then tabs again. One day camel case, week later all lower, another partial hungarian, upper on random things, etc. Waste of time.
  - bluGill 2y ago
    Ideally pick a style from a different large organization that you have no input in. Because the organization is large they will have put a lot of effort into it, but since you have no input you can just follow it without thinking. Sometimes an organization will make some really weird choices and you will be forced to change styles (google as rejected a lot of the latest C++ standard and thus their C++ style guide is not to be used elsewhere, but there are plenty of other good options). Second best is to start a large cross company standards organization and only allow one representative per organization. Make sure there is a lot of process standing in the way of changes so that changes are only made when really justified (because most are not justified)
- 9rx 2y ago
  To be fair, for most developers code is what their customer is going to see.
hackflip 2y ago
Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac?
- mixmastamyk 2y ago
  The old Carlin bit, was going to mention. :-D. I think he used, “asshole.”
  - RangerScience 2y ago
    "If you met an asshole in the morning, you met an asshole. If you meet assholes all day, you're the asshole." (or, something close to that)
- cmckn 2y ago
  Oh thank god, I thought that was just me.
Cthulhu_ 2y ago
Thing is, you can care for the craft, but let the code style and linting tools do what they do best and don't stress over them. Code reviews are better now that there's tooling that automatically checks for, fixes, or marks common issues like code style so the reviewer doesn't have to do anything with them. That is, I'd argue the "stressing" is not about what these tools check, but about the tools and their configuration itself. Just go with all the defaults and focus on bigger issues.
cardanome 2y ago
Sure some people that care about minutiae are code artisans but what I have seen more often is co-workers weaponizing these discussions to hide their own incompetence. I have seen so many people going on and on about best practices and coding styles and whatnot and using big words just in hopes to keep discussions going so no one figures out out that they don't know how to code.
raincole 2y ago
When people stress over the details I care, it's craftmanship. When they stress over the ones I don't care, it's nitpicking.
ghc 2y ago
To reduce your argument to its essence, you're saying typesetting is part of the craft of writing. I've yet to meet an author who believes this (other than enjoying editing their own work as output from a typewriter), and I think the same broadly applies to code. It's not that everyone thinks these things are unimportant, it's that caring deeply about doing them a particular way is orthogonal to the craft. It's something that has long been lampooned (tabs vs. spaces, braces, etc.) as weird behavior.
- catlifeonmars 2y ago
  I think there are accessibility aspects to formatting. Specifically to different formatting. Not sure the typesetting analogy is the best, but typesetting absolutely matters for readability. Authors don’t need to care about it because typesetting is easy to change (before printing) and because publishers spend time caring about it —- all before it ends up in the hands of readers.
- stonemetal12 2y ago
  More than one writer refuses to use a computer, preferring typewriters. Harlan Ellison learned how to repair typewriters after he could no longer find anyone to fix his. Stephen King wrote Dreamcatcher with a fountain pen. Authors totally obsess over details that seem irrelevant to people outside that craft.
  - asa400 2y ago
    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 laid out C codebase that expertly runs and captures the essence of its domain, serves real traffic and makes real money. Make your editor work how you like, but if my team lead started to get annoyed after my 4th formatting-only PR I should probably start to think about what I want them to bring up to my manager in my performance review.
arp242 2y ago
Most of these things really don't matter, and it all just boils down to "that's not how I would have written it". Well, okay, but that doesn't mean that's somehow objectively better.
fsloth 2y ago
No, focusing on code style is weird. It’s tablestakes it should be uniform in style and legible. Automate styling to vanilla defaults. Leave it. It’s like obsessing over the font on the packaging of the marker you use to write to the whiteboard in a math seminar. Now, weird is beautiful but it’s not usefull and mostly irritating in a professinal context. Cherish your weirdness and celebrate when you can find people of same persuasion. But don’t bother your colleagues with it. I’m saying this as a person with very deep weird personal interests as several here do - and I’ve learned this slowly and painfully.
swiftcoder 2y ago
If what you care about deeply can be automated by a linter, it's trivial, and you ought to just setup the linter rules, and go use all that time you just gained to work on something more meaningful.
jredwards 2y ago
Related: Anyone who's driving slower than I am is an idiot and anyone who's driving faster than I am is a maniac.
taurknaut 2y ago
> Revered artisans are precisely the ones who care for the details. Well yea, but which detail you care about still matters and reveals a lot about your "craft". Code style is of such little consequence compared to semantics it's always a little eyebrow-raising to see people who are extremely opinionated about it. I've also noticed that this sort of thing can sort of fade into the background after a couple decades of coding. I know people who go on and on about how "beautiful" code is—to me it's just syntax serving a purpose. Sometimes you can make really elegant code that works well with the language, sometimes you can't. But how the code is presented impacts my reading comprehension very little unless you're doing something very strange (looking at you, early 90s c code with one-letter variable names and heavy macro usage). Actually, I recant one element of this—Javascript and Typescript are just straight ugly and hard to read.
drbawb 2y ago
Somewhat agree and disagree. I bucket people's style into two camps, stressing over the former is largely unproductive, but stressing over the latter is crucial to writing high-quality, maintainable software. Someone's style can be "different" without being "bad", and you have two basic options to deal with it. One is to authoritatively remove the soul via process (auto-formatters, code review, and to a lesser degree linters, etc. are all designed to create uniformity at the cost of individuality.) The other is to suck it up and deal with it, as this is just an inevitability of creating a team size larger than one: people have different tastes and those have to be reconciled. I somewhat prefer allowing for individuality, and individuals should endeavor to match the style of whatever module they're working in, out of courtesy to its owners/stakeholders if nothing else. However I have only worked independently or on small teams. Most large teams (/ open source projects) have gone the former route of automating all the fun/craftsmanship out of their systems, and even I think that makes sense at a certain scale. Someone's style can just be objectively "bad", however, and I usually find it's evidence they just don't care about the source artifact that much, and they're focused on the results. (It can also be a sign of an under-performer that spends so much mental capacity just getting the code to work that they have no spare cycles to spend thinking about matters of taste.) If it compiles / works / passes the test-suite that's "good enough" and "their job is done" and they move on to the next task. These people tend to be hyper-literal thinkers that are very micro-task oriented: they see implementing a new feature as a checklist to be conquered, rather than being systems-level thinkers on a journey of discovery & understanding. If the author is talking about the latter, I have to agree with you that the latter are quite difficult for me to work with; particularly since I know that the source has to be maintained & supported over a much larger time-scale. The source-code is like your house, you live in it, being comfortable to work with/in/on it is the key to success. The deployed artifact may live for only a few weeks, days, or even hours before it gets replaced. The source has evolved over decades. You (the organization) are practically married to it. To further the analogy: I don't mind if somebody wants to hang posters in their room for a band I don't like. (Hell I can even handle if a group of those posters are tastefully hung out-of-level to make some kind of statement.) I do mind if their furniture is blocking a vent, the outlet covers are hanging off, there's a hole in one of the walls, a light has been burnt out for months, and the window-blinds over there are clearly broken but they insist it's fine because daylight still gets through.
afavour 2y ago
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.
- intull 2y ago
  In some ways, it's the point OC makes — that it's subjective. It's a culture problem. In our profession, our conventional approach to resolve these kinds of differences is to reduce them to a specific set of conditionally applied rules that everyone _has_ to agree on. Differences in opinions are treated as based on top of a more fundamental set of values that _have_ to be universal, modular, and distinct. Why do we do this? Because that's how we culturally approach problem-solving. Most industries at large train and groom people to absorb structured value systems whose primary function is to promote productivity (as in, delivery of results). That value system, however, ultimately benefits capital most, not necessarily knowledge or completeness. Roles and positions ultimately encompass and package a set of values and expectations. So, we are left with a small group of people who practiced valuing few other aspects but feel isolated and burdened with having to voluntarily take on additional work (because they really care about it), and others unnecessarily pressured to mass-adopt values and also burdened taking on what feels like additional work that only a small group of people like to care about. In the cultural discourse, we are trying to fix minimum thresholds of some values and value systems and, correspondingly, their expectations. That is never going to be possible. In and of itself, that can be a valid ask. However, time and resources are limited, and values are a continuum. Fixing one requires compromising on another. This is where we are as a professional culture and community in the larger society today. The Tech industry refuses to break down the role of a "software engineer/developer" further than what it is today and, consequently, refuses to further break down more complex/ambiguous values and value systems into simpler ones, thus reducing the compromises encompassed in and perceived by different sub-groups and increasing overall satisfaction of developers in the industry. Instead, we've expanded on what software developers should be responsible for, which has caused more and more people to burn out trying to meet a broader set of expectations and a diminished set of value systems with more compromises to accommodate that. Ideally, we need an industry and a professional culture that allows for and respects niche values and acknowledges the necessity of more niche roles to focus on different parts of the larger craft of software development. PS. As a side note, the phrasing of it in the article is unfair, which OC is pointing out too — there is a false equivalency drawn between "caring for the craft" and "stressing over minutia." This causes, in this context of having a discourse around the article, those who value and want to talk about the value of caring for the craft to be viewed and perceived as the insane weirdos who stress over the minutia that the author was referring to.
708145_ 2y ago
It is a fine balance, and everyone that doesn't "drive the same speed" as me, frustrates me.
WesolyKubeczek 2y ago
People, though, tend to spiral down into the bikeshedding abyss. It’s one thing to stand your ground about a linting rule that has proven effective in combatting certain classes of errors that you encountered in the field. It’s another thing to make every discussion be about linting rules. I cannot put it into words right, but you can see there’s usually a vibe. It will be different coming from an experienced developer knowing what they are talking about from lived experience, and from a clueless one who has seen shit but is hell bent on process and rules.
vichle 2y ago
I love that the top comment is a 10 level deep bikeshed about bikeshedding.
yread 2y ago
tabs or spaces are ok. Mix of tabs and spaces is not.
tharne 2y ago
> 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”. Theses are bullet points expressing general rules of thumb, not legal treatises. You're reading far too much into these.
giancarlostoro 2y ago
I dont care about style as long as you can give me a document that specifies all the rules. It can be a simple text file, but don't expect me to remember them all from one convo. At least with Python I just push everyone to follow PEP-8 makes it easier.
unclebucknasty 2y ago
>Revered artisans This may point to the dividing line. Software is required to be functional, not simply "artistic". You can certainly make the argument that there are non-functional considerations in its construction: readability, maintainability, extensibility, etc. And, these absolutely intersect with style, so it's tempting to apply words like "artistry". But, is there a point where details veer into personal preference and insistence on style for the sake of style? I think so, and many of us have seen this. For those who haven't yet, stick around!
Pxtl 2y ago
"Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac?" -- George Carlin
98codes 2y ago
Reminds me of the equivalent you see so often about driving where people slower than you are morons, while those faster than you are crazy.
OptionOfT 2y ago
Formatting is also important for cohesion. A code base that is formatted is easier to browse. And I couldn't care less about where you put the {}. I love autoformatters. Linting is a little more. It's both style and genuine issues, like don't == instead of === in JavaScript.
Netcob 2y ago
I think most people who care about code have a bit of OCD over these things, but there is a difference between how the code looks vs. how it is structured. I think that's what the author means.
jacksnipe 2y ago
I care about the craft of constructing programs. I do not care about the craft of typesetting them.
throw310822 2y ago
> What you’re essentially saying is “cherish the people who care up to the level I personally and subjectively think is right No. The two aspects (let's call them the craft and the minutiae) are orthogonal, they're not different level of caring about the same thing. I've seen people obsessed over minutiae and writing buggy, careless and unmaintainable code. As with other formal aspects (e.g., testing) the quality of the code and the level of adherence to convention or forms are independent of each other; but they do both consume the same limited resource, which is the time and attention of developers.
diddid 2y ago
The idea that style and linting define the “craft” is bizarre. What it sounds like you are saying is that you prefer style over substance. Not a single developer I’ve ever revered cared about styling. It’s a means to an end for large teams because to make it easy to read you need commonality. It’s kind of like what Bruce Lee said about punches. Before you know how to code, styling is just styling. When you become proficient in coding, styling is more than just styling. But when you’ve mastered coding, styling is just styling again. Be like water my friend.
wiremine 2y ago
I took this as "don't stress about things you can automate." Yes, you need to care about this. But for the most part you should just follow the conventions of the language/framework, and not reinvent the wheel. Instead, you should put cycles into crafting architectures and algorithms.
jayd16 2y ago
The trick to life is finding the exact right amount of fucks to give.
- bdangubic 2y ago
  zero… the answer is zero :)
lngnmn2 2y ago
[dead]
Aeolun 2y ago
Code style and linting rules are not something you obsess over. They are things you set once and then follow more or less automatically.
bradleyjg 2y ago
Code is human readable text. Authors should craft it with care. The linter people are hypercorrectionalists of the type that would change “to boldly go where no man has gone before!” because it’s a split infinitive.
rhubarbtree 2y ago
Equivalently: code is written for other humans to read.
brunooliv 2y ago
There’s a big difference when someone stresses over minutiae and fails to see the bigger picture or why the overall design might be flawed. Wanting to have code up to a given standard is a laudable goal but as with everything, it can be taken to such an extreme that people lose sight of the real value being delivered. Code is not the end goal, except for some people it is.
locallost 2y ago
I could agree with your general sentiment, but don't in this case. There's nothing in code style that is important for the craft, at least not in the way it's usually discussed. It could be important if one style is somehow dangerous, but for most people it's a matter of aesthetics, which after a (too) long time doing this I think is weird. Because there are so many real problems to deal with, and where to place a character certainly ain't one.
akoboldfrying 2y ago
There are aspects of code that matter and aspects that don't. I lump everything that doesn't matter under "code style", and cherish those who cherish the remaining aspects.
sevensor 2y ago
Having a consistent code style and adhering to a set of linting rules is important, but that they exist is far more important than their particulars. I get bored very fast when people argue about the visual presentation of their code. Use a formatter and be done with it. Same with linting rules; pick a set that your team can work with. If you dial everything up to 11, you’re going to have perfectly compliant code that doesn’t do anything. Recognize that compliance sometimes makes your code worse and pick your roles accordingly.
pgwhalen 2y ago
No, they are saying that code style, minting rules, and other minutia are not the essence of the craft. Which I agree with. You have to read between the lines to pick that up though, so your criticism seems valid.
red_admiral 2y ago
I have a lot of sympathy for the golang auto-linter here. I can also understand the fuss better in indentation-is-structure languages like python.
scotty79 2y ago
> Revered artisans are precisely the ones who care for the details. Abhored obstructionists and covert saboteurs are also the ones that care for the details. You need to care about right kind of details. Any specific linting is not that kind. Linting at all is. Artisan without a proper sense could spend weeks exquisitely decorating a spoon with gaping hole in the middle. State of nearly all software is more or less horrible. Choosing the right linting rules is most often than not putting lipstick on a pig.
eloisant 2y ago
Now we have tooling to make sure (1) code style is consistent and (2) you don't have to stress about it. Every language has automatic formatters. Use them, configure them if you don't like the default (in accordance with your team), and configure your editor so that is applied automatically when you save. And use CI to detect PRs with bad formatting so devs who don't have configured their editor yet can't break it. Same with linters, you still have to agree with your co-workers about which rules make sense to be enforced, but with good editor integration you can see it right away and fix it as you code.
- nijave 2y ago
  That's my stance--formatting and style is important but it's also a job for machines. I think you can still quibble over formatting but the result should be automation, not nit-picky code review comments or chat war threads.
bena 2y ago
Whether one uses tabs or spaces, Allman or K&R, etc. is largely immaterial. On your own projects, choose a style, go with it. On someone else's project, go with the style chosen. On a shared project, come up with a style, go with it. Code _organization_ matters way more than code _style_. Where style refers only to the aesthetic choices that don't impact the structure or flow.
lo_zamoyski 2y ago
This is baldfaced relativism. It only takes a moment of reflection to understand the absurd consequences of this position. For example, how it becomes meaningless to speak of caring about the craft if there is no objective definition of what exactly one should care about, or what is important. It ceases to have intersubjective relevance. > What you call “stressing over minutiae” others might call “caring for the craft”. So what? The presence of disagreement is not an argument in favor of relativism and subjectivism. People can be wrong, and they can be wrong about what is valuable. Value is not subjective. The fact-value dichotomy is false. That's the general principle. As far as this particular example is concerned, the author didn't say things like code style and linting rules have absolutely no value. They have some value. The question is how much, especially in the grand scheme of things, and whether one's concerns, attention, and efforts are proportioned to the objective value of such things. That's how this question should be framed. The author's position, charitably read, is that it is objectively irrational to obsess over such things. If you wish to rebut, then go ahead and provide an argument, but don't retreat into the bollocks of subjectivism.
willcipriano 2y ago
The craft is the result, not the process.
Rexxar 2y ago
I think you can apply what Stephen Fry say in the following video to programming : https://www.youtube.com/watch?v=J7E-aoXLZGY https://www.youtube.com/watch?v=J7E-aoXLZGY
andy_ppp 2y ago
Sigh... it really doesn't matter compared to say how and what you test, and that you are consistent. He's saying your opinion about where a brace goes or even spaces or tabs is just not that important compared to crafting simple systems with clear code.
beryilma 2y ago
> People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Until you open a file that has 10 different coding styles from 5 different developers. Just the variations of variable naming schemes alone in individual code files that I see/edit, would drive anyone crazy.
patrick451 2y ago
It's a strange assertion to claim that people who care about formatting care about the craft more. IMO, it's the opposite: people who care about formatting prefer to talk and think about the periphery of programming not the actual act of programming itself. For the record, I reject the usually offered claim that the most important attribute is consistency. I have an easier to reading code written in a different style than understanding somebody with a different accent, but nobody is claiming we should only hire teams from the same regions of the same country.
cafard 2y ago
Didn't George Carlin say that everyone who drove faster than one was a maniac and everyone slower was a moron?

by latexr 2y ago

hkwerf 2y ago

There is more than one type of people who stress over code style. There's the group who wants to discuss about how to style your code and then there's the group who wants to just use a common code formatter and be done with that. For example, I have objections to rustfmt's default style. I would never start discussions on rust projects about changing that to another formatter or changing its configuration. I definitely would carefully ask that people should really use rustfmt, though, if they don't do so yet.

xnorswap 2y ago
Edit: This comment was based on misreading the parent comment. I've left it up, but I should have been more careful. You've set yourself up to always be the outlier. To always need to have that discussion or tweak the rules on every project you work with. You've increased the overhead of onboarding anyone used to the default style. You've increased the overhead of you working on anyone else's projects that is more likely to have the default style. All of that is friction introduced because you haven't learned to live with the default style. Do I love that the default C# rules put a new line before the else block? No, but I've learned to live with it so that I can work on all manner of projects without fussing over that style option every time. By adhering to default rules, you never have to have the endless arguments such as tabs vs spaces again. ( Spaces won, and the tabbers got over it fairly quickly once it was the default in almost all formatters. )
- hkwerf 2y ago
  I believe you may have misunderstood my comment, as I agree.
  - xnorswap 2y ago
    I apologise, I misread your statement as: "I would never start discussions on rust projects *without* changing that to another formatter" which changed the meaning entirely. I should have taken a moment to re-read what you wrote.
- latexr 2y ago
  What I understood from your parent comment was the exact opposite, i.e. that they’re saying “I disagree with some of the default choices of the formatter (and so would prefer they were different) but I never voice those because it’s not worth it. However, I do think everyone should use something, whatever it is (even if the default style), as opposed to nothing”.
maleldil 2y ago
> I definitely would carefully ask that people should really use rustfmt, though, if they don't do so yet. If you don't already, you should run `cargo fmt --check` in CI and block PR merges until it passes. You can also run it in a pre-commit hook, but you can't be sure everyone will set that up. Automating such types of decision is great but moot if others have to opt into it.
spjt 2y ago
Code formatters are the best of both worlds. I despise Allman-style indentation for reasons I can't explain or justify, but if I have to work on a codebase that uses it, I can simply put hooks to reformat it to whatever the repo style is before commit.

OJFord 2y ago

It's not even more or less, it's just about different aspects. Consider a woodworker obsessing over sharp chisels - they don't all care beyond 'sharpish', or about the tools used to do so - but to some that's hugely important and how they are then able to do their best work.

chasd00 2y ago
To take it further some woodworkers are really tool hobbyists. They obsess over the tools and never really touch the wood they’re supposedly working. Same goes for software devs, I think about this when reading threads obsessing over AWS services, pipelines, build stacks, instead of writing software.

xnorswap 2y ago

The solution is to have computers enforce the code style. Pick a linter, pick a set of rules, and then forget about them. Things I beleive: - If you're picking up on code-style in PRs then your toolchain is backward. - If you're changing linting rules every month then you're focussed on the wrong things - It's better to have a consistent style than a perfect style

secondcoming 2y ago
This is what we did with clang-format on our code base. The result is occasionally ugly code and nobody is 100% happy but at least it's consistent.
- maleldil 2y ago
  Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.[1] [1] https://go-proverbs.github.io/ https://go-proverbs.github.io/
  - maxwell 2y ago
    While everyone has a favorite ES Lint ruleset but few agree on which to use.
- gpderetta 2y ago
  *cough*clang-format off*cough*
  - secondcoming 2y ago
    Ha, yes. I started doing that but then lost the will to continue.
bayindirh 2y ago
Yes. I love how gofmt has no settings, basically. Is this how you envisioned? Great. Now I don't have to think about optimizing it. Coincidentally, the choices they made are the choices I'd made, but it doesn't matter in the end.

jajko 2y ago

Not really. Obsessing over breaking lines after famous 80 chars in Eclipse was, is and will be idiotic to be polite. Surprisingly large amount of people were obsessed by this long after we got much bigger screens, if that was ever an argument (it wasn't for me). 2 spaces vs 4 spaces or tab. Cases like these were not that rare, even though now it seems better. That's not productive focus of one's (or team's) energy and a proper waste of money for employer/customer, it brings 0 added value to products apart form polishing ego of specific individual. Folks who care about the craft obsess (well within realm of being realistic) more about architecture, good use of design patterns, using good modern toolset (but not bleeding edge), not building monolithic spaghetti monster that can't evolve much further, avoiding quick hacks that end up being hard to remove and work with over time and so on. If you don't see a difference between those groups, I don't think you understood author's points.

sfn42 2y ago
I'd say avoiding long lines is one of the most important rules. I regularly have 2-3 files open side by side, I don't want to have to scroll sideways to read the code. 80 characters is a bit on the low end imo but I'd rather have the code be too vertical than too horizontal. Maybe 120-150 is a more reasonable limit. It's not difficult to stay within those bounds as long as you don't do deep nesting which I don't really want to see anyway because it's hardly ever necessary and it makes code more difficult to read.
- cess11 2y ago
  Reading vertically is much faster than reading horizontally, so I think 80 is a good soft limit. In some contexts it's hard to not go over it sometimes, e.g. in Java where it's not uncommon with very long type and method names.
- CrimsonRain 2y ago
  Functional code is more chained and need more space often. Descriptive names are better; tends to be longer. Buy ultrawide. 80 is for aholes who like to use small laptop and then force it on everyone else. 120/150 is reasonable. 200 is great.

WJW 2y ago

There's a correlation-is-not-causation issue here. Yes, most very good developers pay a lot of attention to details, as well as to the bigger picture. But there are a lot of mediocre to downright bad developers who think that paying a lot of attention to code style, linting rules and other minutia will make them better developers.

bityard 2y ago
My experience has been the opposite. Most mediocre to bad developers are so happy that their code works AT ALL that they pay little to no attention to things like sensible variable names and whitespace conventions. We sometimes call these things, "code smell."
- fullstackchris 2y ago
  I've always thought on the contrary that "code smell" refers much more to the patterns used and not so much how it was formatted. Anyway, choosing a language that has automatic formatting (Go for example) renders about 80% of comments in this thread about "linting" and "formatting" and blah blah blah completely irrelevant.

bryanrasmussen 2y ago

as others note, most of this minutia can be automatically enforced. Anything that can be automated is not craft.

marsovo 2y ago
Heartily disagree. I have had to fight with others over automated formatting because it obscured intent or clarity. For example (C#) mandating `var`, mandating one and only one line of whitespace between lines of code, mandating the => syntax for single-line functions (instead of Function(vars) { ... } ) I would say, when to use one or the other of each of those options is very much a craft.
__mharrison__ 2y ago
Sadly formatting well written pandas and Polars code cannot be automated but current tooling.

aswerty 2y ago

In my opinion, I think the author is criticizing bike shedding [1] rather than meaningful decisions. Of course some people will differ on whether a decision is one or the other. But as a whole, not sweating the details is a good quality to have whatever road in life you are on. [1] https://en.wikipedia.org/wiki/Law_of_triviality https://en.wikipedia.org/wiki/Law_of_triviality

The_Colonel 2y ago
Everyone dislikes bikeshedding. But people disagree on which questions are bikeshedding and which aren't.
bluGill 2y ago
Details are important though. Some bikeshed type ideas spiral into very expensive changes. This is a large part of why US transit construction is so much more expensive - people asking for lots of little details which add up (large monument stations, bike paths done with the project... those things all add up) - the important safety details are left to experts, but only after they are told to build something far more expensive than needed. (this isn't a plea for brutalism architecture there are nice things you can do that are only minimally more expensive)

hliyan 2y ago

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.

chrisjj 2y ago
> the school of thought that says that the code is the design There's such a school?? Seriously??
TickleSteve 2y ago
architecture over implementation (for details).
Retric 2y ago
> 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.
- hliyan 2y ago
  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.

bdcravens 2y ago

I think the line between minutiae and craft is drawn by the effect it has on the product you're creating. Method length makes your code more manageable, for example. Placement of line breaks, not so much. At the end of the day, we aren't paid to produce code, but working software that works today and is easy to change tomorrow.

latexr 2y ago
That is a purely commercial take of the matter. I don’t think it’s controversial to argue the artisans who stand out do so because they care for the craft itself. Spending an extra hour or two perfecting the shape of the armrest in the chair may not allow you to earn more money from that one commission, but it might improve your knowledge and skill and be slightly more comfortable to the sitter. If they comment on it and appreciate it, so grows your motivation and pride. Sometimes the code itself, and not its result, is the product. For example, when making tutorials the clarity and beauty of the code matters more than what it does. I’m not arguing for obsessing over code formatting, but pointing out the line between “master of the craft with extensive attention to detail” and “insane weirdo with prioritisation deficits focusing on minutiae” is subjective to what each person considers important. Most of us seem to agree that being consistent in a code base is more important than any specific rule, but that being consistent does matter. At the end of the day, we aren’t paid to eat healthily and taking care of our bodies either. But doing so pays dividends. Same for caring about the quality of your code. Getting in the habit of doing it right primes you to do it like that from the start in every new project. Like most skills, writing quality code becomes easier the more you do it.
- bdcravens 2y ago
  > be slightly more comfortable to the sitter That's kind of my point: the end cannot see, or feel, minutiae. If they can, it's not minutiae. > Sometimes the code itself, and not its result, is the product. For example, when making tutorials the clarity and beauty of the code matters more than what it does. The code still isn't the product in that instance. It's the educational process. In many cases, clarity != beauty. This is why the best written tests often duplicate code, rather than being curated exercises in DRY. > we aren’t paid to eat healthily and taking care of our bodies either Yet programmers insist to be paid. Obviously taking time to grow on your own, on your own dime, is self-enriching for all the reasons you describe.

korijn 2y ago

Is it ironic that this comment has evoked a discussion on minutiae?

deleted 2y ago
[deleted]

hemant1041 2y ago

Interesting read!

raverbashing 2y ago

And that's why I don't care anymore Yup. Doesn't matter. Code style should be consistent and look nice, probably use the default without too much nitpicking. You have bigger fish to fry There are better things in life to worry about "Craft", most code goes to irrelevancy in 5 yrs. And if it doesn't it's fixable (amen for AIs) Try to sweat up every detail right off the bat and you go nowhere

oytis 2y ago

To me "craft" is about keeping code efficient, scalable, extensible, well-tested and documented. Code style is more about what naming convention to use, tabs vs spaces etc. - it's nice to have it consistent, but no need to spend more than 5 minutes arguing about it.

ctxc 2y ago
Tabs/spaces is a non-issue, agreed - IDEs handle it. But surely naming convention contributes to keeping code documented, extensible and efficient? A deviation from the norm leads to people thinking x does not exist in a large code base, leading to them implementing duplicate methods/functionality, leading to one instance evolving differently enough to cause subtle bugs but not enough to be distinct, or leading to one instance getting fixes the other does not etc? Sample size of 1, but I've seen it happen unfortunately.

lr4444lr 2y ago

Following non functional stylistic rules to the letter as if they were on the level of SQL injections or memory leaks isn't "craft". It's cargo culture weirdness. Sure, have a style and a linter. Be DRY. Don't lose your head over it though.

lijok 2y ago

Video game logic: Everyone worse than me is a noob. Everyone better than me has no life.

alternatex 2y ago
Today Steam gives us the option of verifying whether a certain player has no life. Only half joking.
- danielbln 2y ago
  My favorite steam reviews are: "This game sucks, would not recommend." - playtime 800h
  - edm0nd 2y ago
    and on the flipside of this "This game sucks, would not recommend." - playtime 1.2h
mtdrk 2y ago
This is more like noob logic. Good players are eager to learn from those better than them.

ozim 2y ago

If you want to compare to artisans - they were stressing about details that customers see, details that customers don’t see were to cut corners on. Making fuss about indentation in code file is not artisanal. It is insane weirdo if we are charitable and if not clueless and childish.

sumtechguy 2y ago
Everyone wants a particular style. Except when they have to use someone elses style. Pick a style stick with it. Review it every 6 months to year to see if anything needs to be tweaked. If you hear 'we are professionals' you are about to see code that has 20 different styles and design patterns. I worked with one guy who could not make up his mind and changed the whole style guide about every 2-3 weeks. It royal made him mad the original style guide fit on a couple of postit notes. Me and two other engineers bashed it out in a 1-2 hour meeting at the start of the project (odd number of people to vote on anything). It came down to the fact he came in after the fact and had no say in it. Then proceeded to change everything. One week it was tabs everywhere then spaces then tabs again. One day camel case, week later all lower, another partial hungarian, upper on random things, etc. Waste of time.
- bluGill 2y ago
  Ideally pick a style from a different large organization that you have no input in. Because the organization is large they will have put a lot of effort into it, but since you have no input you can just follow it without thinking. Sometimes an organization will make some really weird choices and you will be forced to change styles (google as rejected a lot of the latest C++ standard and thus their C++ style guide is not to be used elsewhere, but there are plenty of other good options). Second best is to start a large cross company standards organization and only allow one representative per organization. Make sure there is a lot of process standing in the way of changes so that changes are only made when really justified (because most are not justified)
9rx 2y ago
To be fair, for most developers code is what their customer is going to see.

hackflip 2y ago

Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac?

mixmastamyk 2y ago
The old Carlin bit, was going to mention. :-D. I think he used, “asshole.”
- RangerScience 2y ago
  "If you met an asshole in the morning, you met an asshole. If you meet assholes all day, you're the asshole." (or, something close to that)
cmckn 2y ago
Oh thank god, I thought that was just me.

Cthulhu_ 2y ago

Thing is, you can care for the craft, but let the code style and linting tools do what they do best and don't stress over them. Code reviews are better now that there's tooling that automatically checks for, fixes, or marks common issues like code style so the reviewer doesn't have to do anything with them. That is, I'd argue the "stressing" is not about what these tools check, but about the tools and their configuration itself. Just go with all the defaults and focus on bigger issues.

cardanome 2y ago

Sure some people that care about minutiae are code artisans but what I have seen more often is co-workers weaponizing these discussions to hide their own incompetence. I have seen so many people going on and on about best practices and coding styles and whatnot and using big words just in hopes to keep discussions going so no one figures out out that they don't know how to code.

raincole 2y ago

When people stress over the details I care, it's craftmanship. When they stress over the ones I don't care, it's nitpicking.

ghc 2y ago

To reduce your argument to its essence, you're saying typesetting is part of the craft of writing. I've yet to meet an author who believes this (other than enjoying editing their own work as output from a typewriter), and I think the same broadly applies to code. It's not that everyone thinks these things are unimportant, it's that caring deeply about doing them a particular way is orthogonal to the craft. It's something that has long been lampooned (tabs vs. spaces, braces, etc.) as weird behavior.

catlifeonmars 2y ago
I think there are accessibility aspects to formatting. Specifically to different formatting. Not sure the typesetting analogy is the best, but typesetting absolutely matters for readability. Authors don’t need to care about it because typesetting is easy to change (before printing) and because publishers spend time caring about it —- all before it ends up in the hands of readers.
stonemetal12 2y ago
More than one writer refuses to use a computer, preferring typewriters. Harlan Ellison learned how to repair typewriters after he could no longer find anyone to fix his. Stephen King wrote Dreamcatcher with a fountain pen. Authors totally obsess over details that seem irrelevant to people outside that craft.
- asa400 2y ago
  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 laid out C codebase that expertly runs and captures the essence of its domain, serves real traffic and makes real money. Make your editor work how you like, but if my team lead started to get annoyed after my 4th formatting-only PR I should probably start to think about what I want them to bring up to my manager in my performance review.

arp242 2y ago

Most of these things really don't matter, and it all just boils down to "that's not how I would have written it". Well, okay, but that doesn't mean that's somehow objectively better.

fsloth 2y ago

No, focusing on code style is weird. It’s tablestakes it should be uniform in style and legible. Automate styling to vanilla defaults. Leave it. It’s like obsessing over the font on the packaging of the marker you use to write to the whiteboard in a math seminar. Now, weird is beautiful but it’s not usefull and mostly irritating in a professinal context. Cherish your weirdness and celebrate when you can find people of same persuasion. But don’t bother your colleagues with it. I’m saying this as a person with very deep weird personal interests as several here do - and I’ve learned this slowly and painfully.

swiftcoder 2y ago

If what you care about deeply can be automated by a linter, it's trivial, and you ought to just setup the linter rules, and go use all that time you just gained to work on something more meaningful.

jredwards 2y ago

Related: Anyone who's driving slower than I am is an idiot and anyone who's driving faster than I am is a maniac.

taurknaut 2y ago

> Revered artisans are precisely the ones who care for the details. Well yea, but which detail you care about still matters and reveals a lot about your "craft". Code style is of such little consequence compared to semantics it's always a little eyebrow-raising to see people who are extremely opinionated about it. I've also noticed that this sort of thing can sort of fade into the background after a couple decades of coding. I know people who go on and on about how "beautiful" code is—to me it's just syntax serving a purpose. Sometimes you can make really elegant code that works well with the language, sometimes you can't. But how the code is presented impacts my reading comprehension very little unless you're doing something very strange (looking at you, early 90s c code with one-letter variable names and heavy macro usage). Actually, I recant one element of this—Javascript and Typescript are just straight ugly and hard to read.

drbawb 2y ago

Somewhat agree and disagree. I bucket people's style into two camps, stressing over the former is largely unproductive, but stressing over the latter is crucial to writing high-quality, maintainable software. Someone's style can be "different" without being "bad", and you have two basic options to deal with it. One is to authoritatively remove the soul via process (auto-formatters, code review, and to a lesser degree linters, etc. are all designed to create uniformity at the cost of individuality.) The other is to suck it up and deal with it, as this is just an inevitability of creating a team size larger than one: people have different tastes and those have to be reconciled. I somewhat prefer allowing for individuality, and individuals should endeavor to match the style of whatever module they're working in, out of courtesy to its owners/stakeholders if nothing else. However I have only worked independently or on small teams. Most large teams (/ open source projects) have gone the former route of automating all the fun/craftsmanship out of their systems, and even I think that makes sense at a certain scale. Someone's style can just be objectively "bad", however, and I usually find it's evidence they just don't care about the source artifact that much, and they're focused on the results. (It can also be a sign of an under-performer that spends so much mental capacity just getting the code to work that they have no spare cycles to spend thinking about matters of taste.) If it compiles / works / passes the test-suite that's "good enough" and "their job is done" and they move on to the next task. These people tend to be hyper-literal thinkers that are very micro-task oriented: they see implementing a new feature as a checklist to be conquered, rather than being systems-level thinkers on a journey of discovery & understanding. If the author is talking about the latter, I have to agree with you that the latter are quite difficult for me to work with; particularly since I know that the source has to be maintained & supported over a much larger time-scale. The source-code is like your house, you live in it, being comfortable to work with/in/on it is the key to success. The deployed artifact may live for only a few weeks, days, or even hours before it gets replaced. The source has evolved over decades. You (the organization) are practically married to it. To further the analogy: I don't mind if somebody wants to hang posters in their room for a band I don't like. (Hell I can even handle if a group of those posters are tastefully hung out-of-level to make some kind of statement.) I do mind if their furniture is blocking a vent, the outlet covers are hanging off, there's a hole in one of the walls, a light has been burnt out for months, and the window-blinds over there are clearly broken but they insist it's fine because daylight still gets through.

afavour 2y ago

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.

intull 2y ago
In some ways, it's the point OC makes — that it's subjective. It's a culture problem. In our profession, our conventional approach to resolve these kinds of differences is to reduce them to a specific set of conditionally applied rules that everyone _has_ to agree on. Differences in opinions are treated as based on top of a more fundamental set of values that _have_ to be universal, modular, and distinct. Why do we do this? Because that's how we culturally approach problem-solving. Most industries at large train and groom people to absorb structured value systems whose primary function is to promote productivity (as in, delivery of results). That value system, however, ultimately benefits capital most, not necessarily knowledge or completeness. Roles and positions ultimately encompass and package a set of values and expectations. So, we are left with a small group of people who practiced valuing few other aspects but feel isolated and burdened with having to voluntarily take on additional work (because they really care about it), and others unnecessarily pressured to mass-adopt values and also burdened taking on what feels like additional work that only a small group of people like to care about. In the cultural discourse, we are trying to fix minimum thresholds of some values and value systems and, correspondingly, their expectations. That is never going to be possible. In and of itself, that can be a valid ask. However, time and resources are limited, and values are a continuum. Fixing one requires compromising on another. This is where we are as a professional culture and community in the larger society today. The Tech industry refuses to break down the role of a "software engineer/developer" further than what it is today and, consequently, refuses to further break down more complex/ambiguous values and value systems into simpler ones, thus reducing the compromises encompassed in and perceived by different sub-groups and increasing overall satisfaction of developers in the industry. Instead, we've expanded on what software developers should be responsible for, which has caused more and more people to burn out trying to meet a broader set of expectations and a diminished set of value systems with more compromises to accommodate that. Ideally, we need an industry and a professional culture that allows for and respects niche values and acknowledges the necessity of more niche roles to focus on different parts of the larger craft of software development. PS. As a side note, the phrasing of it in the article is unfair, which OC is pointing out too — there is a false equivalency drawn between "caring for the craft" and "stressing over minutia." This causes, in this context of having a discourse around the article, those who value and want to talk about the value of caring for the craft to be viewed and perceived as the insane weirdos who stress over the minutia that the author was referring to.

708145_ 2y ago

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

WesolyKubeczek 2y ago

People, though, tend to spiral down into the bikeshedding abyss. It’s one thing to stand your ground about a linting rule that has proven effective in combatting certain classes of errors that you encountered in the field. It’s another thing to make every discussion be about linting rules. I cannot put it into words right, but you can see there’s usually a vibe. It will be different coming from an experienced developer knowing what they are talking about from lived experience, and from a clueless one who has seen shit but is hell bent on process and rules.

vichle 2y ago

I love that the top comment is a 10 level deep bikeshed about bikeshedding.

yread 2y ago

tabs or spaces are ok. Mix of tabs and spaces is not.

tharne 2y ago

> 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”. Theses are bullet points expressing general rules of thumb, not legal treatises. You're reading far too much into these.

giancarlostoro 2y ago

I dont care about style as long as you can give me a document that specifies all the rules. It can be a simple text file, but don't expect me to remember them all from one convo. At least with Python I just push everyone to follow PEP-8 makes it easier.

unclebucknasty 2y ago

>Revered artisans This may point to the dividing line. Software is required to be functional, not simply "artistic". You can certainly make the argument that there are non-functional considerations in its construction: readability, maintainability, extensibility, etc. And, these absolutely intersect with style, so it's tempting to apply words like "artistry". But, is there a point where details veer into personal preference and insistence on style for the sake of style? I think so, and many of us have seen this. For those who haven't yet, stick around!

Pxtl 2y ago

"Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac?" -- George Carlin

98codes 2y ago

Reminds me of the equivalent you see so often about driving where people slower than you are morons, while those faster than you are crazy.

OptionOfT 2y ago

Formatting is also important for cohesion. A code base that is formatted is easier to browse. And I couldn't care less about where you put the {}. I love autoformatters. Linting is a little more. It's both style and genuine issues, like don't == instead of === in JavaScript.

Netcob 2y ago

I think most people who care about code have a bit of OCD over these things, but there is a difference between how the code looks vs. how it is structured. I think that's what the author means.

jacksnipe 2y ago

I care about the craft of constructing programs. I do not care about the craft of typesetting them.

throw310822 2y ago

> What you’re essentially saying is “cherish the people who care up to the level I personally and subjectively think is right No. The two aspects (let's call them the craft and the minutiae) are orthogonal, they're not different level of caring about the same thing. I've seen people obsessed over minutiae and writing buggy, careless and unmaintainable code. As with other formal aspects (e.g., testing) the quality of the code and the level of adherence to convention or forms are independent of each other; but they do both consume the same limited resource, which is the time and attention of developers.

diddid 2y ago

The idea that style and linting define the “craft” is bizarre. What it sounds like you are saying is that you prefer style over substance. Not a single developer I’ve ever revered cared about styling. It’s a means to an end for large teams because to make it easy to read you need commonality. It’s kind of like what Bruce Lee said about punches. Before you know how to code, styling is just styling. When you become proficient in coding, styling is more than just styling. But when you’ve mastered coding, styling is just styling again. Be like water my friend.

wiremine 2y ago

I took this as "don't stress about things you can automate." Yes, you need to care about this. But for the most part you should just follow the conventions of the language/framework, and not reinvent the wheel. Instead, you should put cycles into crafting architectures and algorithms.

jayd16 2y ago

The trick to life is finding the exact right amount of fucks to give.

bdangubic 2y ago
zero… the answer is zero :)

lngnmn2 2y ago

[dead]

Aeolun 2y ago

Code style and linting rules are not something you obsess over. They are things you set once and then follow more or less automatically.

bradleyjg 2y ago

Code is human readable text. Authors should craft it with care. The linter people are hypercorrectionalists of the type that would change “to boldly go where no man has gone before!” because it’s a split infinitive.

rhubarbtree 2y ago

Equivalently: code is written for other humans to read.

brunooliv 2y ago

There’s a big difference when someone stresses over minutiae and fails to see the bigger picture or why the overall design might be flawed. Wanting to have code up to a given standard is a laudable goal but as with everything, it can be taken to such an extreme that people lose sight of the real value being delivered. Code is not the end goal, except for some people it is.

locallost 2y ago

I could agree with your general sentiment, but don't in this case. There's nothing in code style that is important for the craft, at least not in the way it's usually discussed. It could be important if one style is somehow dangerous, but for most people it's a matter of aesthetics, which after a (too) long time doing this I think is weird. Because there are so many real problems to deal with, and where to place a character certainly ain't one.

akoboldfrying 2y ago

There are aspects of code that matter and aspects that don't. I lump everything that doesn't matter under "code style", and cherish those who cherish the remaining aspects.

sevensor 2y ago

Having a consistent code style and adhering to a set of linting rules is important, but that they exist is far more important than their particulars. I get bored very fast when people argue about the visual presentation of their code. Use a formatter and be done with it. Same with linting rules; pick a set that your team can work with. If you dial everything up to 11, you’re going to have perfectly compliant code that doesn’t do anything. Recognize that compliance sometimes makes your code worse and pick your roles accordingly.

pgwhalen 2y ago

No, they are saying that code style, minting rules, and other minutia are not the essence of the craft. Which I agree with. You have to read between the lines to pick that up though, so your criticism seems valid.

red_admiral 2y ago

I have a lot of sympathy for the golang auto-linter here. I can also understand the fuss better in indentation-is-structure languages like python.

scotty79 2y ago

> Revered artisans are precisely the ones who care for the details. Abhored obstructionists and covert saboteurs are also the ones that care for the details. You need to care about right kind of details. Any specific linting is not that kind. Linting at all is. Artisan without a proper sense could spend weeks exquisitely decorating a spoon with gaping hole in the middle. State of nearly all software is more or less horrible. Choosing the right linting rules is most often than not putting lipstick on a pig.

eloisant 2y ago

Now we have tooling to make sure (1) code style is consistent and (2) you don't have to stress about it. Every language has automatic formatters. Use them, configure them if you don't like the default (in accordance with your team), and configure your editor so that is applied automatically when you save. And use CI to detect PRs with bad formatting so devs who don't have configured their editor yet can't break it. Same with linters, you still have to agree with your co-workers about which rules make sense to be enforced, but with good editor integration you can see it right away and fix it as you code.

nijave 2y ago
That's my stance--formatting and style is important but it's also a job for machines. I think you can still quibble over formatting but the result should be automation, not nit-picky code review comments or chat war threads.

bena 2y ago

Whether one uses tabs or spaces, Allman or K&R, etc. is largely immaterial. On your own projects, choose a style, go with it. On someone else's project, go with the style chosen. On a shared project, come up with a style, go with it. Code _organization_ matters way more than code _style_. Where style refers only to the aesthetic choices that don't impact the structure or flow.

lo_zamoyski 2y ago

This is baldfaced relativism. It only takes a moment of reflection to understand the absurd consequences of this position. For example, how it becomes meaningless to speak of caring about the craft if there is no objective definition of what exactly one should care about, or what is important. It ceases to have intersubjective relevance. > What you call “stressing over minutiae” others might call “caring for the craft”. So what? The presence of disagreement is not an argument in favor of relativism and subjectivism. People can be wrong, and they can be wrong about what is valuable. Value is not subjective. The fact-value dichotomy is false. That's the general principle. As far as this particular example is concerned, the author didn't say things like code style and linting rules have absolutely no value. They have some value. The question is how much, especially in the grand scheme of things, and whether one's concerns, attention, and efforts are proportioned to the objective value of such things. That's how this question should be framed. The author's position, charitably read, is that it is objectively irrational to obsess over such things. If you wish to rebut, then go ahead and provide an argument, but don't retreat into the bollocks of subjectivism.

willcipriano 2y ago

The craft is the result, not the process.

Rexxar 2y ago

I think you can apply what Stephen Fry say in the following video to programming : https://www.youtube.com/watch?v=J7E-aoXLZGY https://www.youtube.com/watch?v=J7E-aoXLZGY

andy_ppp 2y ago

Sigh... it really doesn't matter compared to say how and what you test, and that you are consistent. He's saying your opinion about where a brace goes or even spaces or tabs is just not that important compared to crafting simple systems with clear code.

beryilma 2y ago

> People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Until you open a file that has 10 different coding styles from 5 different developers. Just the variations of variable naming schemes alone in individual code files that I see/edit, would drive anyone crazy.

patrick451 2y ago

It's a strange assertion to claim that people who care about formatting care about the craft more. IMO, it's the opposite: people who care about formatting prefer to talk and think about the periphery of programming not the actual act of programming itself. For the record, I reject the usually offered claim that the most important attribute is consistency. I have an easier to reading code written in a different style than understanding somebody with a different accent, but nobody is claiming we should only hire teams from the same regions of the same country.

cafard 2y ago

Didn't George Carlin say that everyone who drove faster than one was a maniac and everyone slower was a moron?