1. 36

  2. 13

    I agree with almost everything the OP has said.

    Where there is confusion is around the case that this is a “quiet crisis”. I used to think that software managers didn’t know that open-plan offices and ageism produced a low quality of result. The older I get, the more I’m aware that they do know. They just don’t care.

    Business has this anti-intellectual culture and the flip side of that is that not knowing how this technical “voodoo” works is a point of pride, because only the low-status peons actually know that “mechanical” stuff. This also makes it really easy to blame “tech” when things go wrong. Executives are expected to be on top of things like the latest corporate logo redesign or the press coverage they’re getting, but technical excellence isn’t valued and technical failure can always be blamed on the programmers– even if it’s a software company– with no consequences for the individual executive. Thus, conditions for programmers will deteriorate. Sticking the programmers in an open-plan cattle pen saves money on paper (that’s a bonus for some cost-cutting shithead who doesn’t actually do anything). When the programmers all become less productive, the blame can be thrown on them as individuals.

    The OP is the rare software manager who actually cares more about doing his job than promoting himself and climbing the ranks. Very few do.

    Is this a “quiet crisis”? I don’t know. I mean, technical excellence isn’t rewarded in the corporate world, and companies are still profitable. I might personally think it sucks that there’s so much tolerance of imprecision-of-thought and half-assed work, but we’re not actually seeing these executives bear the consequences of their decisions, so I’m increasingly convinced that everything we fight for, as principled technologists, actually doesn’t matter to the global economy.

    1. 6

      “Doesn’t matter to corporations” is very different from “doesn’t matter to the global economy”. Robin Hanson, who is a professor of economics at GMU, has uncovered numerous ways in which people behave, to put it bluntly, irrationally and hypocritically, and some of these relate to the corporate world in particular. For example, Hanson claims (I believe correctly) that if corporations really wanted to hear an unbiased view of how likely a project was to come in on time and on budget, they’d get feedback from the people who actually have insight into this, i.e. the front-line employees - in our case, software engineers. Hanson believes that internal prediction markets are a good way of obtaining accurate feedback - I’m afraid (I know you disagree with me here) I prefer Scrum - but regardless of what you think about that, the general principle is sound. But getting accurate feedback from front-line employees is a relatively uncommon activity in the corporate world. Why is this? Well, we can conclude one of two things: either corporations by and large do not want to hear accurate estimates, they instead want to hear political estimates manufactured by managers and executives (and in some cases individual engineers) to make them sound good. Or, alternatively, there are a large number of middle managers and executives who genuinely believe that a military-style command-and-control hierarchy is the best way to obtain accurate estimates. I’m not sure which possibility is worse.

      But neither of these possibilities imply that this local “political” optimum is necessarily economically optimal, either for the corporation itself or for the economy as a whole. Traditional corporate organisation is something humans fell into - it was copied from the military, and we shouldn’t expect that it will continue to be seen as the most effective organisational form forever.

      1. 3

        You’re correct. Also “corporations” don’t have discernible wills. People within corporations do. Executives don’t actually care if projects succeed or fail– only how it will affect them. They’d rather have a major failure that they can blame on a rival than a success that puts them at risk later on.

      2. 3

        What are the options for the peon ?

        1. Go join another corporate
        2. Work at a younger corporate
        3. Become an executive
        4. Join other peons and start a peon collective and wait till the peon leader sells out in the end to become another executive.
        5. Join peon anonymous
        6. Quit / Die

        Some want to work within the system.
        Some outside of it.
        The input of the System is your soul. The output is profit.

        Monsters exist because we lack the discipline to defeat them. That’s the first assumption made by the monster.

        1. 2

          I think we can start by not thinking of ourselves as peons, and to demand that our employers treat us as trusted professionals. Organizing around our interests can help us at denying talent to employers who refuse to do so, and we can make this a global effort.

          So #4 seems like the strongest suggestion. And sure, a “peon leader” is a SPOF. That’s why there needs to be at least the threat of competition. If one programmer collective turns corrupt, then another should replace it.

          The best strategy that I can see is to create an exam system like what the actuarial sciences have, and build up a professional society from that.

          1. 1

            Fair enough. The best-case scenario I can see is for ACM / IEEE like organisations to do it.

            The challenge I see is for selling that idea to the industry and a vast number of hippy-dippy-dropout programmers to actually write it.

            Culturally I suppose the best we can do is to

            1. Increase Awareness
            2. Encourage corporates that do better things.

            I have an idea, let’s build a website that reviews ….. oh wait that’s glassdoor.

            1. 1

              I think sites like glassdoor are the best hope/tool we have. I left my old job based on being bored of the grind and realising that after being there for 8 years without a significant pay rise i was now being under paid, when i asked around my own work I found out that even the new graduates straight out of uni were paid more. I had slipped through the cracks and was stuck in a rut, half my fault, half my boss’s. It took glassdoor or similar to prompt me initially.

      3. 5

        I love the way there’s still this baked in superior/inferior cultural dynamic:

        As a manager it’s likely you don’t have a whole lot of say here but if you do, allow your employees
        to dress casually. You certainly don’t want them going to work with torn up jeans or in their pajamas,
        but a nice pair of jeans and any decent shirt with a collar should do just fine.


        1. 7

          What do you mean with that?

          1. 3

            “Any decent shirt with a collar” presumably means no t-shirts, no jumpers, and no turtlenecks. (Sorry Jobs.) Here’s the content of our intranet’s “What to wear” page (edited to replace names with titles):

            What To Wear (because explicit is better than implicit)

            For the avoidance of doubt, our “dress code” is: wear clothes.

            If you want to wear a suit to the office, wear a suit. Nobody else generally does.

            CTO tends to wear a shirt and jeans. Hoodies are commonplace (we have branded hoodies!) as are t-shirts of various levels of branding and humour.

            1. 2

              I think nickzoic means, “Why does the manager have a say/expectation at all?”. My personal view is if they aren’t front facing, don’t have clients they physically interact with, then don’t worry what they wear. Something like “No offensive t-shirts, genitals and nipples covered” should be good enough.

            2. 1

              I picked up on that passage too, but it felt so out of place with the rest of the article it’s almost as if he left it in there to allow people to say “how can I improve on this and make it mine”—not unlike the confectionist who got much more business from punters popping in to tell them their sign contained a spelling mistake…

            3. [Comment removed by author]

              1. 2

                Have any of you seen situation where the high performers were actually bad? I’d be interested to hear about it.

                Yes! At a former job (for a big bank) I worked with a couple people who were liked by traders for “delivering quickly”. The rest of us knew that they spent most of their day putting out fires and wrestling with technical debt, so dreaded it every time they went on holiday and we had to cover. One of them was my boss, hence there was little I could do as a new starter.

                1. 2

                  I think it should be read as “perceived high performers”. When looking at some people through the narrow window of “functionality added”, without delving into the quality of the code they wrote (as a manager might), it’s entirely possible to get false positives for high performance. It’s also an issue of short term vs. long term, both in terms of length of observation and management priorities (which are often extremely focused on the short term).

                  I have seen two examples in the workplace:

                  • One is a person who churns out a lot of code. In the worse case, it’s buggy but (insidiously) the bugs may show up in other components, making other people waste time on fixing them. In a somewhat better case, the code works but ignores established conventions and/or the developer doesn’t care to propagate the changes to the rest of the code base (e.g. suppose they introduce a superior logging mechanism in their bit of code but they don’t give a toss about replacing it in the rest of the code). Again, these changes fall on the shoulders of other people, bringing their observable performance down. This may look like high performance to the manager for some time, especially because the performance of other people has gone down. The complaints and the realisation that bugs are introduced at a higher rate compared to other people will take time to percolate up to the manager.

                  • Another case is a person who writes a lot of good code, but the code they write is beyond the understanding of the rest of the team. The rest of the team then struggles to use it, and they have to keep going back to the original developer for help. This definitely looks like high performance to the manager (hey, this developer is solving complex problems AND helping teammates!), and maybe even to the developer team. But ultimately, this isn’t a great situation either. Without bringing everybody else to the same skill level, this is a dysfunctional setup.

                  And then, of course, there is the situation suggested in the article where the developer churns out code without regard for maintainability, which may align perfectly with the (short term) priorities of the manager but brings everybody’s performance down when viewed over the long term.