6 ms·

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, t

• 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.
    • skydhash 2y ago
      That’s because the few hard rules you have to comply with have workarounds and matters rarely. In house construction, you have to care about weight, material degradation, the code, etc… there’s no such limitation on software so you can get something to work even if it’s born out of a LSD trip. But we do have some common concepts. But they’re theoretical, so only the people that read the books knows the jargon.
      • namaria 2y ago
        I mean why should we expect software to have hard rules? Flexibility is the point, no?
        • HeyLaughingBoy 2y ago
          No. Flexibility is a side effect. Sometimes it's a useful side effect, other times it bites you in the ass.
        • Ma8ee 2y ago
          The rules are what make it flexible. The rules let me understand what the heck is going on in the code you wrote so I can change it. Code that is faster to rewrite from scratch isn’t flexible.
    • watt 2y ago
      don't stress about it so much: look how many variations of plugs and sockets are for this one quite simple thing: https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets
    • VonGallifrey 2y ago
      > I brought over the blueprints, and the technician found the schedule of beams and columns within seconds Is that really an example of the standardization you want? It shows that the blueprint was done in a way that the technician expected it to be, but I am not sure that these blueprints are standardized in that way globally. Each country has its standards and language. If an architect from a different country did that blueprint, I would bet that it would be significantly different from the blueprint you have. Software Engineering doesn't have a problem with country borders, but different languages would require different standards and conventions. Unless you can convince everyone to use the same language (which would be a bad idea; CRUD apps and rocket systems have different trade-offs), I doubt there could be an industry-wide standard.
  • desdenova 2y ago
    Fortunately nowadays formatting issues can be delegated to autoformatting in any popular language. Some people still argue over autoformatter parameters, but then people will always find a bike shed to argue about.
    • noahjk 2y ago
      Maybe a new paradigm for code formatting could be local-only. Your editor automatically formats files the way you like to see them, and then de-formats back to match the codebase when pushing, making your changes match the codebase style.
      • asdajksah2123 2y ago
        This is pretty common now. At least my Vim/git combo does this, where I always open source code with my preferred formatting but by the time it's pushed to the server it's changed to match the repo preferences.
      • tele_ski 2y ago
        It's a decent idea, but it's weird reviewing code you wrote in saying GitHub, it looks totally different. Imo not a show stopper but a side effect you have to get used to.
        • maccard 2y ago
          I’d like to think that GitHub would be able to display with my editor format settings.
      • ruined 2y ago
        this works for pure formatting, but falls apart when you start linting to exclude certain syntax or patterns
      • withinboredom 2y ago
        This is disastrously easy to implement with just a few filters on git (clean & smudge). I highly recommend it though, especially if you worked for a long time at one company and are used to a specific way of writing code. Or if you like tabs instead of spaces...
  • drcongo 2y ago
    First thing I thought of was the tiny Stone Henge in Spinal Tap.
  • DarkPlayer 2y ago
    > However at a minimum formatting changes shouldn’t regularly complicate doing a diff. If the code needs to be reformatted, this should be done in a separate commit. Fortunately, there are now structural/semantic diff tools available for some languages that can help if someone hasn't properly split their formatting and logic changes.
    • gmueckl 2y ago
      Reformatting comitts still leaves the issue that you deprive yourself of any possibility to reliably diff across such commits (what changes from there to there?) Or attribute a line of code to a specific change (why did we introduce this code?). What we should have instead is syntax-aware diffs that can ignore meaningless changes like curly braces moving into another line or lines getting wrapped for reasons.
      • DarkPlayer 2y ago
        > What we should have instead is syntax-aware diffs that can ignore meaningless changes like curly braces moving into another line or lines getting wrapped for reasons. These diffs already exist (at least for some languages) but aren't yet integrated into the standard tools. For example, if you want a command line tool, you can use https://github.com/Wilfred/difftastic https://github.com/Wilfred/difftastic or if you are interested in a VS Code extension / GitHub App instead, you can give https://semanticdiff.com https://semanticdiff.com a try.
      • oasisbob 2y ago
        Not a full solution, but .git-blame-ignore-revs can help, and is automatically supported by GitHub: https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa98b9e279175f2 https://gist.github.com/kateinoigakukun/b0bc920e587851bfffa9...
  • singron 2y ago
    I'm immediately reminded of Apple's "goto fail" bug, which was in part overlooked because of poor formatting and/or style: https://dwheeler.com/essays/apple-goto-fail.html https://dwheeler.com/essays/apple-goto-fail.html
    • throwaway2037 2y ago
      But not poor testing?
    • dsego 2y ago
      I feel like this is a failure of language and syntax that allows formatting to be deceiving.
  • dasil003 2y ago
    Software, being arbitrary logic, just doesn't have the same physical properties and constraints that have allowed civil engineering and construction code to converge on standards. It's often not clear what the load bearing properties of software systems are since the applications and consequences of errors are so varied. How often does a doghouse you built in your backyard turn into a skyscraper serving the needs of millions over a few short years?
  • maccard 2y ago
    This is the best argument I've ever heard for editorconfig, commiting a standardised format to the repos, and viewing it in whatever way you want to view it on your own machine
  • zcfan 2y ago
    I don't care about code styles of my colleagues, as long as it remains consistent and sane. But sadly it usually isn't.
• binary132 2y ago
  There is definitely something to be said for the idea that a shitslop engineering blueprint which still conveys correct design (maybe; who knows really?) is shitslop, whether or not the design is sound. In the case of software engineering, the blueprint is the implementation, too, so it’s not just shitslop blueprinting, it’s also shitslop brickwork (totally sound bones though I promise!), shitslop drywalling, shitslop concrete finishing and rebar work — and maybe it’s all good under the hood! Totally fine if all you’re building is a shithouse! But I think you get where I’m going with this.
• skydhash 2y ago
  The value of software is both what it does now (behavior), and what you can get it to do later (structure). What you described as design and the compiled artiface is the behavior. The craft is what gives you future choices. So when people cares about readability, writing tests, architecture, they’re just making easy for them to adjust the current behavior later when requirements change. A software is not an house, it doesn’t get build and stays a certain way.
  • skeeter2020 2y ago
    experience gives you some possible ideas for how it will be used in the future, but after a long time I'm coming to the position you're fooling yourself if you think you can predict where with any accuracy. It's still valuable and important to try, just not as critical to be right as I used to think. Example: I've completely flip-flopped from interface simplicity to implementation simplicity. I agree that a house is a bad analogy, for your reasons and because you can "live" in software that as a building would not be fit for human habitation.
    • skydhash 2y ago
      You have to be pragmatic about it, balancing between the speed of only implementing the now and the flexibility of taking care of the future. It's not predicting, mostly it's about recognizing the consequences of each choice (for later modifications) and and either accepting it or ensuring that it will not happen.
      • dowager_dan99 2y ago
        > It's not predicting, mostly it's about recognizing the consequences of each choice (for later modifications) This is the exact trap I'm describing. It sounds very reasonable, but how is it not prediction when you're asking people to "recognize the <future> consequences of each choice"? You have very little to no understanding of the context, environment or application of today's creations. Smart, experienced people got us into the current microservice, frontend JS, "serverless" cloud messes.
• anuramat 2y ago
  > not the defining characteristic Did anyone claim otherwise? Besides, I imagine bridges aren't rebuilt every week -- poor blueprints can only cause a finite amount of pain.
• atkevindsouza 2y ago
  Let's talk about in the way you seem to interpret it. Imagine if Blueprint A used imperial units while others used metric units. That's what inconsistent code style does to you.
  • gbro3n 2y ago
    No it doesn't, the units remain the same. Only legibility changes. Style doesn't affect semantics.
• psychoslave 2y ago
  >I'm fond of saying that anything that doesn't survive the compilation process is not design but code organization. Maybe not at the same level, but code organization is also a design. I don’t care that much about the exact linter rules applies (but I do prefer blue, hmm, nooo). But getting rid of merge conflicts that come from lake of common linter rules, this is a great pipeline process improvement, and this is some kind of code contribution pipeline design.
• animuchan 2y ago
  In many languages, types don't survive the compilation process (e.g. TypeScript, Java). Yet types describe which data structures are used.
• asdajksah2123 2y ago
  > 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.
  • tehologist 2y ago
    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.
    • atq2119 2y ago
      > 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.
      • mindcrime 2y ago
        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.
        • tisdadd 2y ago
          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.
• zelphirkalt 2y ago
  And some specific people with lots of experience in teaching as well as in developing real life useful systems will tell you, that code is first and foremost written for people to understand, and only incidentally for a computer to run. Human understanding of what is going on is the one most important thing. If we do not have that, everything else will go to shit.
• ryandrake 2y ago
  Yea, I've always considered craftsmanship to be about paying attention to the details and making everything high quality--even the things that the end user will never see, but you know are there. The Steve Jobs quote sums it up nicely: > "When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through."
  • james_marks 2y ago
    To take it a bit further, the "unseen quality" does surface periodically, like when the proverbial chest of drawers ends its first life, and goes to the dump or gets restored. The same is true in software when a developer inherits a codebase. Those signs of quality turn into longevity, even when they face away from the user.
  • Illotus 2y ago
    If you look at back pieces of old classic furniture made during hand powered tools era, its mostly very roughly finished. Professionals rarely had time to spend dicking around with stuff that isn't visible.
• s1mplicissimus 2y ago
  The construction metaphor isn't a very good fit here in my opinion. No building is expected to have the amount of adaptability that is expected of software. It falls completely apart for interpreted languages. When is a PHP app constructed in this metaphor? On every single request? The metaphor assumes a "design once, build once" approach, which is basically no software I've ever seen used in real life. Hardware, OS, language, collaborator/dependency updates all require changes to the application code more often than not. And that's assuming the feature set stays stable, which, in my experience is also quiet rare. Maintainability is therefore a quality dimension of software, and reduced cognitive load usually results in increased maintainability (curious if someone has a counterexample to that) That is not to say I'm one of those people who need a specific code style to have their weird brain satisfied. But not using a linter/autoformatter at all [when available] in 2025 sounds like the opposite of "work smart, not hard"
• tremon 2y ago
  sowhatyouresayingisthatyoureequallyhappyeditingjavascriptinitsminifiedartifactformastheoriginalcode?imeanifallthatyoucareaboutisthatyourwordsarecorrectlyinterpretedbythemachinetheresnovalueinmakingsurethatyourcodeisreadableandusablebyanotherhumanbeingamiright?
• bellBivDinesh 2y ago
  So writing brittle code that’s impossible to change isn’t a failure of design? It can still compile and run just fine
• chausen 2y ago
  I overall agree. The one thing I will say is that what you call code organization (anything pre-compilation) also includes structuring the code to improve maintainability, extensibility, and testability. I would therefore disagree that code organization is only basic hygiene, not part of design, and not a large part of the “craft” (use of that word is something I’ve changed my opinion on—while it feels good to think of it that way, it leads to exactly the thing we’re discussing; putting too much emphasis on unimportant things). Code style though, I do agree isn’t worth stressing about. I do think you may as well decide on a linter/style, just so it’s decided and you can give it minimal energy moving forward.
• forgetfreeman 2y ago
  By your own analogy, blueprints have a very strict set of guidelines on stuff like line styling, font selection, displaying measurements, etc. This is absolutely critical as nobody wants to live with the kind of outcomes generated when there's any meaningful ambiguity in the basic conventions of critical design documents. At the same time, having to hack through a thicket of clashing code style adds to the cognitive load of dealing with complex codebases without offering any improvement in functionality to balance the tradeoff. I've literally seen open source developers lose their commit access to projects over style issues because the maintainers correctly concluded that the benefits of maintaining an authoritarian grip on the style of code committed to the project outweighed humoring the minority of fussy individualists who couldn't set aside their preferences long enough to satisfy the needs of the community.
• aqueueaqueue 2y ago
  You defined anything that doesn't survive the balloon as keeping the s77 rad-ishes.
• ahel 2y ago
  Thanks for writing this. It makes me question if I'm too much concerned with code hygiene vs my coworkers.
• nijave 2y ago
  Code is read much more frequently than a blueprint. I'd argue that code is more akin to a paper map than blueprint.