1. 22
  1.  

  2. 16

    Apparently I’m not. I really hate these titles.

    But fort he point the author is making, one can see this style of thinking all over the place. I have worked at companies that did reorgs all the time, as if reorging will some how fix a culture of poor quality. I’m not sure if people honestly think that their issue is how the organisation is structured or don’t know how to change culture in an organisation. One nice thing about reorging is that generally the person doing the reorging is not being moved around either, which implies they don’t see themselves as part of the problem. On the other hand, admitting there is a culture problem means you are part of the problem.

    1. 8

      I know, the title sucks. Sorry about that.

      It’s hard to find a balance sometimes between boring, matter-of-fact titles that nobody clicks on and this sort of Buzzfeed-style clickbait thing.

      But I take your criticism to heart, and I’ll try to lean to the conservative side next time.

      1. 8

        I recently left a company that has had reorgs roughly every 6 months for years now. It’s like tradition. Really what happens is that someone new comes in and shits all over the current state, insisting they get their own way. Over and over.

        Sometimes there isn’t even a real problem other than ego.

        1. 6

          This is why I’m inherently distrustful of large orgs: they spawn all sorts of ridiculous behavior that makes zero sense with regard to what they actually do in the real world. And it always traces back to someone trying to protect turf or enlarge their ego.

          How utterly dull and uninspiring.

      2. 6

        Similarly, when developers declare how much better one framework is than another after a complete rewrite. Failing to acknowledge that many of the benefits came from the rewrite, not the framework.

        1. 5

          That’s a great point. I wish I’d mentioned that in the post.

          You go into a rewrite with all this accumulated domain knowledge that you probably didn’t have the first time around, and a much clearer understanding of the problem.

          But then people act like “Man, Angular is so awesome!”

        2. 5

          I was nodding along to the content of the post. I think the problem is more fundamental than “frameworks” though. I’ve often asked devs: “why aren’t you using the framework or library functionality to do it?”. I hardly ever ask this question because I knew it is supported (often I have never used the library or framework at all; specialisation is for insects ok?) but because it made sense based on what they were trying to do. Sometimes I would be wrong, but very often a little hunting through the docs revealed the functionality was already there.

          Sometimes it would be patterns, other times they were trying to implement something that I recognised as a function in a (or perhaps even the standard) library of a different language, e.g. the groupBy function in Scala’s collections library.

          1. 2

            This always reads to me as a compositionality failure. The moment you even have a decision to yank a “framework” out you’ve lost.

            I’ve come to believe that in massively effectful, non-denotation all code you cannot win. Your constructions rely too much on one another’s behavior and essentially any “magic” anywhere implies commingled but hidden stateful interaction.

            The Js “small libraries” movement doesn’t seem to solve this either. It resolves some things, but a conjunction of bad assumptions just leads to polynomial failure rates.

            Solving these problems needs abstraction safety and standard Js style is really hostile to that.

            1. 2

              About the only bit here that I would disagree with, is the part on “learning fundamental Javascript concepts”. Actually, I think the issue there is that at the abstraction level that matters, there aren’t really any. I would go as far as to say that people should be kept well away from Javascript until they’re already a fairly experienced programmer (with a few languages under their belt). There is so little structure, and so little consensus on what good looks like, that it is a world of choices, and you need some experience to make them.

              Frameworks (the ones I have seen, at least) may help you with some of the most trivial (where do I put the call to render this template?) but will leave you completely alone with the more complex (how should I structure control and responsibility for this complex application such that cohesion is high while maintaining loose coupling and predictable operation in the presence of unpredictable asynchronicity?)

              In general, yeah, rapid shifting between tech strategies/org charts/resourcing models, etc. is a sign of a group that hasn’t sussed the problem yet. Otherwise known as the “all of my 8 ex-wives were b****es” problem. Nope.

              1. 1

                Curious, where would you suggest people begin? C?