1. 6
  1.  

  2. 12

    I find it agonizing to discuss development practices online.

    Usually it drags out certain types of commenters from the woodwork, despite participation being entirely voluntary:

    • the disciple: “we tried X one time and it was awesome, therefore everyone should do it”
    • the fatalist: “there’s never enough time to write software well, so why try?”
    • the ‘pragmatic’ guy: “code quality is orthogonal to market fit, so why bother?”
    • the that-one-time-it-sucked guy: “we did X badly one time, so never again!”
    • the pedantic guy: “this wouldn’t work for [edge case] so it sucks”
    • the intellectually lazy guy: “this seems like a lot of work, back to Twitter”

    I think what irks me is the things that make programming interesting are the subjective things that require taste and experience, but everyone seems hellbent on discussing shiny technology because nuance is not received well.

    1. 2

      I think nuance isn’t received well because nuance is difficult in the best of circumstances; I don’t think that this failure is particular to the world of software development practices. I am now in a position where my job performance is directly related to the quality of the work that a group of other developers is doing, so I have grown a lot more focused on thinking about how to think about software development, you know? I’m starting in on reading some Deming (The New Economics). I’d love to find a place to discuss these sorts of things that’s lower temperature; I think bitching about process is a perfectly normal and healthy thing for people to do, but it can overwhelm more meaningful discussions.

      1. 1

        I think the classifications you’ve mentioned here are true of any topic that involves nuance.

        1. 1

          Nuance is hard to do well. I blog about code patterns that work well because it’s much easier to point to code snippet A, code snippet B, and argue that B is better because XYZ. Even that’s contentious enough. I could write similar things about my development practice experiences, but it’s so much harder to make that into something objective enough to have a discussion that goes beyond partisan cheerleading.

        2. 2

          I liked this article but like almost everything i read about anti-patterns it seems to be written from the perspective that anti-pattern is a fixed thing. If I do X that is always bad. There are plenty of “anti-patterns” that are the right thing to do in a given context.

          For example, DRY as a pattern posits that you should never repeat yourself however, if you follow that without regard to context, you will often end up creating premature abstractions. Also, copy and pasted code that is slightly changed for a different context is sometimes the write thing to do because, now I can make changes within that context without worrying about breaking some other context in subtle ways that might not be caught by tests.

          Basically, many “best practices” are often in conflict with one another and depend on context. It’s about tradeoffs and nothing is ever a bad engineering idea, just like nothing is ever a good engineering idea.

          1. 1

            It’s a bit short on advice on how to avoid these pit falls.

            Is there any good books that uses this reverse approach?