1. 40
  1.  

  2. 21

    Highly-skilled people that I respect just got really angry and irrational and basically refused to even try to learn Haskell, which resulted in a culture divide in the company.

    This is kind of a depressing story, by every account this team did everything right. They rationally evaluated their options, ended up building solid reliable software that added value to the company, and did internal training for the new tools to ensure it could be maintained. I really question the judgement of the management that divided the company over what was seemingly a solid solution, and I don’t blame the OP for leaving.

    Why bother calling our profession “software engineering” if weird superstitions and “feelings” about languages trump empiricism and measurement.

    1. 15

      Highly-skilled people that I respect just got really angry and irrational and basically refused to even try to learn Haskell, which resulted in a culture divide in the company.

      I’ve generally found most tech choices are driven by pure emotion.

      1. 10

        I’ve found a vanishingly small number of technical decisions derived from some rational set of principles in the ~25 years that I’ve been doing this work for money.

      2. 9

        One thing that I’ve found, unfortunately, with high-productivity languages is that there’s a sort of political Amdahl’s Law. Instead of it being the serial component of a program that holds up parallelism, the political component of your workflow can dominate your time once you make the coding aspect efficient. The negative side effect of making the work quicker, in other words, is that a higher proportion of your time is spent on political bullshit, such as justifying work. If the people you work for aren’t capable of valuing the technical excellence that such languages facilitate, it can just make your life a lot worse.

        The truth is that improving efficiency isn’t always a good thing. You have to be able to trust your employer. A good employer will give you more autonomy and let you take on more ambitious technical projects. An evil employer will say, “This is great, now I need three fewer of you.”

        Now that I’m more of a manager/architect who also codes, I’m less zealous about languages. If the other programmers want to use Haskell (which I also prefer) then it’s my job to make that possible. If they want to use Python, that’s more than fine with me. I’ll write Python, then. Even Java is OK if they have a damn good reason.

        1. 2

          This is a good point. The only languages I won’t write are C++ and PHP.

        2. 9

          People build their professional identities upon their tools and platforms, which is in all honesty an absolutely stupid way to approach things (but understandable, given the investment involved). So when you propose switching out your stack or your programming language, it’s perceived as a personal attack on the engineer’s competence or professional self-worth. (I am aware of such an actual situation at a certain large corporation involving certain developers and certain front-end stacks.)

          1. 6

            People build their professional identities upon their tools and platforms, which is in all honesty an absolutely stupid way to approach things (but understandable, given the investment involved).

            This is absolutely true, and you’re utterly right to call it stupid.

            I think that the short-termist and ageist culture of corporate programming is largely to blame. People no longer identify as computer scientists or problem solvers, but as X programmers. It has become this high-stakes game of choosing tools (a) where one can contribute to a corporate codebase right away, make a quick impression, and get pulled on to a leadership track in the first 3 months as opposed to never, and (b) that seem, at the time, to have a long-term future in the corporate world.

            When companies invested in people, and when you didn’t need to make a strong, “10x”, impression in your first 3 months to have a career at a place, there was less of a need to brand oneself based on tooling choices or based on silly silos like “data science” (which is mostly watered-down machine learning).

            I’m within a few days of turning 33, which is ancient by corporate programming standards, and I’ve worked with enough different tool sets to get a sense of the recurring themes. I find it a lot more useful and rewarding to think of myself as a computer scientist and problem-solver who can pick up any tool than as an XYZ developer. That, however, seems to be a luxury that comes with professional standing, insofar as I’d no longer take (and, because of my “advanced” age, probably not even be able to get, even if I needed a throwaway job to fill an income gap) the kind of job where I have to justify work in 2-week increments. If I was forced to play that horrid game, I’d do the same thing as everyone else and invest more energy into the tool-selection process than the work itself.

            1. 2

              I’m curious about the halcyon days of corporate culture you are referring to. When was that? For example, “The Soul of a New Machine” - a book about a team developing a minicomputer more than 35 years ago - shows a picture of the industry that’s remarkably similar to what we see today. My impression is that corporate culture hasn’t really changed in at least the last 40 years.

              1. 1

                The worst employers probably were the same now as then. The distributions are different, with a lot more bad examples and very few good ones.

                People always complained about short-term outlooks and meddling management, but it used to be that they complained about 5-year focus as opposed to the next-quarter mentality, and that management could meddle but it was limited compared to now. You didn’t have to stick with a bad employer, in tech, back then. You still don’t, now, but the odds are that if you roll the dice, it’s not going to be better… and you’re going to have one more job hop to explain in the future.

          2. 6

            I worked at IMVU a little before this. It was a good team and definitely some strong personalities. Large swaths of the PHP code at that point were… well “the horror” is a good way to describe it. I too am curious what would have happened with Java.