7 ms·

The problem is no set of rules can replace taste, judgement, experience and intuition. Every rule can be used to argue anything. You can't win architecture arg

• braebo 1y ago
  I’m accustomed to this principle as a musician, so it’s been interesting to see it withstand my journey into software.
  • dlivingston 1y ago
    Can you expand on this?
    • hakunin 1y ago
      Not the commenter, but also had experience with making music and writing software. I think the same applies to any creative endeavor. It’s super hard to consume what you produce as “someone else” (I.e. read what you write, listen to what you compose with fresh perspective). Usually it takes time to forget and disassociate from your work, because you get too used to it while producing it. Coming back to it another day can work sometimes, but very quickly you’ll get used to it again. I think this is one of the most effective ways to achieve quality tasteful results in anything. If you can train yourself to read your own code with fresh eyes almost as soon as you write it, you’d be unlocking a powerful shortcut, a cheat code to life. It’ll make the biggest impact on your code’s (and any other creative work’s) quality. This is also why sometimes you can spend hours painstakingly trying to design something, and it comes out terrible, nobody likes it. And you can do something in 20 minutes just improvising your way through, and it comes out an elegant masterpiece. That’s because you never gave yourself time to “get used to” your work such that you couldn’t perceive the problems with it anymore. You maintained that fresh impatient perspective the entire time.
      • teiferer 1y ago
        > If you can train yourself to read your own code with fresh eyes almost as soon as you write it, you’d be unlocking a powerful shortcut, a cheat code to life. This is really a key takeaway here: Always keep your audience in mind. When programming, you have two audiences: the machine executing the code, and fellow programmers maintaining the code. Both are important, but the latter is often neglected and is what the article is about. Optimize for your human audience. What will make it easier for the next person to understand this? Do that. Like public speaking or writing an article. A great talk or a article happen when the speaker/author knew exactly how the audience would perceive them.
        • hakunin 1y ago
          Agreed, I wrote more in depth about it a few years ago: https://max.engineer/maintainable-code https://max.engineer/maintainable-code
    • braebo 1y ago
      I loved hakunin’s take in the sibling comment — it touches on a profoundly important insight that has informed all music and software I’ve written since I was a young EDM producer / guitarist. I was thinking of something else in my original comment however; teaching someone to make music is easy, but teaching them to make _great_ music is almost impossible, because the bottleneck to quality art is always one’s “taste” — or “ear” as it’s often referred to by musicians. I think this concept is synonymous with “talent”, a somewhat mysterious phenomenon. These ideas seem to run parallel to those explored in this thread related to programmers with and without “taste” as it pertains to the quality of one’s code.
• lokar 1y ago
  I found the book helpful as a way to organize and express what I already knew
• zakirullin 1y ago
  > I like the article but the people who need it won't understand it That's true. One doesn't change his mindset just after reading. Even after some mentorship the results are far from satisfying. Engineers can completely agree with you on the topic, only to go and do just the opposite. It seems like the hardest thing to do is to build a feedback loop - "what decisions I made in past -> what it led to". Usually that loop takes a few years to complete, and most people forget that their architecture decisions led to a disaster. Or they just disassociate themselves.
  • lll-o-lll 1y ago
    One of the big troubles is that if you join a big org you won’t get to do any architecture until you are at least “senior” or “lead”. Maybe that’s not true everywhere, but I have seen a fair bit of it. You need several iterations of “I built a thing” “oh, the thing evolved in horrible ways”, before the instincts for good architecture are developed. I think Big Orgs need to develop younger promising talent by letting them build small green fields projects. Essentially fostering startups inside the organisation proper. Let them build and learn from mistakes (while providing the necessary knowledge; you can actually learn most of this from books, but experience is the ultimate teacher). Otherwise you end up with 5 year experienced people who cannot design themselves out of a paper bag.
    • fireflash38 1y ago
      It's not helped by the "jump every 2 years for 20-50% pay bump". They don't have to deal with their own architectural decisions.
  • wreath 1y ago
    In an industry where most people stay for around 2 years (at least pre 2022), people arent even there to see the results of their decisions.
• bb88 1y ago
  > Every rule can be used to argue anything. Unless it's a rule prohibiting complexity by removing technologies. Here's a set of rules I have in my head. 1. No multithreading. (See Mozilla's "You must be this high" sign) 2. No visitor pattern. (See grug oriented development) 3. No observer pattern. (See django when signals need to run in a particular order) 4. No custom DSL's. (I need to add a new operator, damnit, and I can't parse your badly written LALR(1) schema). 5. No XML. (Fight me, I have battle scars.)
  • ferguess_k 1y ago
    > 2. No visitor pattern. (See grug oriented development) This one is my particular pet-peeve. But I often think that the reason is because I suck. I'm going to read "grug". I also hate one-liner functions.
    • bb88 1y ago
      The real geniuses of our times can convert complexity into simplicity. The subgeniuses use complexity to flex over the common developer. Sometimes things need to be complex -- well that's okay. The real trick is to not put complexity into places it doesn't belong.
      • chanux 1y ago
        Complexity has to live somewhere. The genius is in putting in places that make things manageable, I guess. https://ferd.ca/complexity-has-to-live-somewhere.html https://ferd.ca/complexity-has-to-live-somewhere.html
  • cyberax 1y ago
    Visitor pattern is extremely useful in some areas, such as compiler development.
    • brabel 1y ago
      That’s only true in languages that do not have Algebraic Data Types and pattern matching, which nowadays is a minority of languages (even Java has it).
• bogdanoff_2 1y ago
  >the people who need it won't understand it That's not true. There's plenty of beginner programmers who will benefit from this.
• ruraljuror 1y ago
  Software developers don’t arrive fully formed. Rob Pike benefitted from reading a book or two.
  • YZF 1y ago
    Fair enough. But most of the forming is by doing. Someone gave an analogy to music. You can't become a great musician by reading books. Some great musicians have never read a book about music. But yes, reading can be (a great!) part of the learning process. My point was more about rules. The article says things like replacing complex conditionals with intermediate variables. The idea that a certain construct always have higher cognitive load and should be replaced with another is too simplistic IMO. In order to get a sense of what code is harder to understand you will do better to read code and have others read your code. A good takeaway is to keep this in mind (amongst many other factors) and to understand code needs to be maintained, extended, adapted etc. The ideas are still useful. The danger is blindly applying rules. As long as the reader knows not to apply any of the suggestions if they don't understand why and have relevant experience ;)
• safety1st 1y ago
  The approach that I am trialing with my team now, so far to good results, is as follows. * Our coding standards require that functions have a fairly low cyclomatic complexity. The goal is to ensure that we never have a a function which is really hard to understand. * We also require a properly descriptive header comment for each function and one of the main emphases in our code reviews is to evaluate the legibility and sensibility of each function signature very carefully. My thinking is the comment sort of describes "developer's intent" whereas the naming of everything in the signature should give you a strong indication of what the function really does. Now is this going to buy you good architecture for free, of course not. But what it does seem to do is keep the cognitive load manageable, pretty much all of the time these rules are followed. Understanding a particular bit of the codebase means reading one simple function, and perhaps 1-2 that are related to it. Granted we are building websites and web applications which are at most medium fancy, not solving NASA problems, but I can say from working with certain parts of the codebase before and after these standards, it's like night and day. One "sin" this set of rules encourages is that when the logic is unavoidably complex, people are forced to write a function which calls several other functions that are not used anywhere else; it's basically do_thing_a(); do_thing_b(); do_thing_c();. I actually find this to be great because it's easy to notice and tells us what parts of the code are sufficiently complex or awkward as to merit more careful review. Plus, I don't really care that people will say "that's not the right purpose for functions," the reality is that with proper signatures it reads like an easy "cliffs notes" in fairly plain English of exactly what's about to happen, making the code even easier to understand.
  • awesome_dude 1y ago
    > Our coding standards require that functions have a fairly low cyclomatic complexity. The goal is to ensure that we never have a a function which is really hard to understand. https://github.com/fzipp/gocyclo https://github.com/fzipp/gocyclo > * We also require a properly descriptive header comment for each function and one of the main emphases in our code reviews is to evaluate the legibility and sensibility of each function signature very carefully. My thinking is the comment sort of describes "developer's intent" whereas the naming of everything in the signature should give you a strong indication of what the function really does. https://github.com/mgechev/revive https://github.com/mgechev/revive > Now is this going to buy you good architecture for free, of course not. It's not architecture to tell people to comment on their functions. Also FTR, people confuse cyclomatic complexity for automagically making code confusing to the weirdest example I have ever had to deal with - a team had unilaterally decided that the 'else' keyword could never be used in code.
• mnsc 1y ago
  > You can't win architecture arguments. I feel this in my soul. But I'm starting to understand this and accept it. Acceptance seem to lessen my frustration on discussing with architects that seemingly always take the opposite stance to me. There is no right or wrong, just always different trade offs depending on what rule or constraint you are prioritizing in your mind.
  • berkes 1y ago
    I've found that listening and asking questions is the key to accepting other people's architectural choices. Why do they insist on A over B? What trade offs were considered? Why are these trade offs less threatening than other trade offs? What previous failures or difficulties led them to put such weight on this problem over others? Sometimes it's just ego or stubbornness or routine¹. That can and should be dismissed IMO. Even if through these misguided reasons they choose the "right" architecture, even if the outcome turns out good, that way of working is toxic and bad for any long term project. More often, there are good, solid reasons behind choices, though. Backed with data or science even. Things I didn't know, or see different, or have data and scientific papers for that "prove" the exact opposite. But it doesn't matter that much, as long as we all understand what we are prioritizing, what the trade offs are and how we mitigate the risks of those trade offs, it's fine. ¹ The worst, IMO, is the "we've always done it like this" trench. An ego can be softened or taken off the team. But unwillingness to learn and change, instilled in team culture is an almost guaranteed recipe for disaster
  • KronisLV 1y ago
    > Acceptance seem to lessen my frustration on discussing with architects that seemingly always take the opposite stance to me. There is no right or wrong, just always different trade offs depending on what rule or constraint you are prioritizing in your mind. That’s a stance of acceptance, however I’d say that there are people who are absolutely wrong by most metrics sometimes and also stubborn to the point that you’ll never convince them. Ergo, the frustration is inevitable when faced with them.
  • vitaflo 1y ago
    The problem with a lot of devs is trying to win arguments instead of coming to a consensus. What’s best for the team matters more than what’s best for the individual and every team is different.
• heresie-dabord 1y ago
  > Every rule can be used to argue anything. This is true. However, very few people can clearly explain all the rules. If they can, they have understood the system and are qualified.