1. 18
  1. 22

    I’m not a huge fan of this article. Besides having an overly-catastrophizing view of what the consequences of climate change are likely to be, I think the inferential leap between the posited disruption of industrial infrastructure (in some parts of the world) because of climate change on the scale of the next few decades and a lot of the specific programming practices mentioned is too great to take very seriously.

    Like, it’s probably true that rates of seawater flooding in low-lying coastal areas will go up because of sea level rise on those timescales, but the realistic amount of sea level rise that’s going to happen by the end of the 21st century is on the order of inches. Jumping from that to assuming that the cost of bandwidth (as applied to developer-to-developer personal communication) will go up prohibitively, and then jumping from that to posit that “people will do more TDD” or “the big winners in 2050 will be Rust, Clojure and Go” is a prediction way too specific and contingent to take seriously. Is there no other phenomenon in the world that will affect what programming languages are in common use in 2050 besides climate change? Is it really likely that those three specific languages and no others will be “big winners” in 2050?

    Offices in 2050 for programmers will have been a thing of the past for awhile. It isn’t going to make sense to force people to all commute to a single location, not out of a love of the employees but as a way to decentralize the businesses risk from fires, floods and famines.

    This struck me as an interesting prediction because something like this is in the process of happening - as a 2nd-order consequence of a global pandemic, which was completely unrelated to climate change. There was already an increasing trend towards remote work for most types of programming jobs, and the sharp global emergency of the pandemic really does seem to have accelerated that trend (although we’re still in the midst of this change, and it will take years to accurately see how trends in remote work stabilize).

    In any case it does go too far to say that the office has become a thing of the past for programmers because of the pandemic - there are benefits as well as costs to commuting and working in person will colleagues, and plenty of programmers today do still work in offices, the pandemic nonwithstanding. And the course of time will keep unfolding, and there will be a myriad of phenomena in the world besides climate change over the next few decades that will affect how people work.

    Expect to see a lot more work that involves less minute to minute communication with other developers. Open up a PR, discuss the PR, show the test results and then merge in the branch without requiring teams to share a time zone. Full-time employees will serve mostly as reviewers, ensuring the work they are receiving is up to spec and meets standards. Corporate loyalty and perks will be gone, you’ll just swap freelance gigs whenever you need to or someone offers more money.

    Is also something that happens now. In fact, it’s a reasonably accurate description of how I work in my current job, where I’m in a different time zone than a lot of my colleagues, and I’m hardly unique in that respect. So positing this as a future prediction of a downstream consequence of future climate change rings false to me. But also, why should climate-change-related disruptions of industrial society make it harder to send an asynchronous textual message to a colleague, but not to post a PR on something like a shared git repository? Is Slack really somehow uniquely vulnerable to climate change, when GitLab is not?

    1. 30

      Besides having an overly-catastrophizing view of what the consequences of climate change are likely to be,

      Funny, I thought the opposite; it seems to me incredibly optimistic to believe there is still going to be a programming industry at all

      1. 11

        same here; the collapseOS view seems more likely to me than this version where it’s like the present just with a few little tweaks here and there.

      2. 4

        Non-climate change issues like user-experienced latency and bandwidth costs are already pushing a larger number of SaaS companies to push data as close to the “edge” as possible, colocating data into nearby data centers. A CDN is essentially just pushing data as close to the user as feasible with current logistics.

      3. 8

        I find this article interesting mainly because it completely sidestepped the idea of making computing radically more efficient by reducing the amount of computing happening, using primarily lower level and more efficient systems and so on. It’s almost entirely about the act of engineering as opposed to the engineering itself. The closest it seems to get is touching on bandwidth costs but that’s entirely a user experience thing.

        I think there’s a lot of room between this article and scavenge computing for discussing how to make things more efficient.

        1. 7

          This sort of discussion always boils down to “this article says climate change will deal 5 damage to society, but actually it’ll only deal 3 damage!”, followed by “no, this article is overly optimistic - climate change will actually deal 7 damage”.

          And so, the discussion grinds to a halt pending the conclusion of the question “how devastating will climate change actually be, anyway?”, which is unanswerable - it’s a fundamentally based on both 1) your political beliefs of what would work, and 2) your optimism for how effectively we’ll mitigate climate change in the next 30 years. In other words, we first need to all agree on both politics and the state of human nature and our current culture. This is an endless distraction.

          If we want to have this discussion, IMO we need to bypass that distraction entirely , by creating several possible scenarios of different climate change severity (without arguing for which will actually happen), and then write a version of this article for each scenario.

          1. 5

            I’m not entirely sure that’s useful, because “the future is here, it’s just not evenly distributed”. Some people are already living and dying in blasted wastelands, have had their homes wiped off the maps by floods and wildfires, are fighting in resource wars. Some people will be comfortable and unaffected for the rest of their lives. Global heating, sea level rise, and other effects are (perhaps counterintuitively) not even across the globe. In other words, we won’t get just one of the future scenarios you’re mentioning, we’ll get all of them, at the local level.

            Even the collapse of our civilization wouldn’t be evenly distributed. Look at the Mayans, who by some accounts declined from a population of 3 million at their peak to only 100,000 people by the time the Spanish arrived, but historians disagree on whether this counts as a “collapse” because it took a long time and in the north their culture more or less continued uninterrupted. For the cities that were abandoned, it looks like a collapse, but in the north, it might have been seen as a non-event. (I think a scenario where your numbers are 30 times smaller should count as a collapse, but what do I know. Imagine what that would mean for our culture.)

            The most problematic part for predicting the future is that, not only do we not know what scenario we’ll see at the global level, you can’t fully predict which future you’ll get in any given location. Therefore I think you would be doing people a disservice if you split scenarios up into different articles. The scenarios will all happen, to a greater or lesser extent, and unfortunately you need to prepare for all of them.

          2. 4

            While I think this borders on off-topic, I do think these problems directly affect how we will write software in the future so it meets the threshold of lobsters. We can’t bury our heads in the sand and pretend these problems are not likely coming.

            1. 1

              One of the nice features coming out of Java is project Loom. This is already committed in pre-release mode under Java 19. This will have a positive impact on the environment since it can reduce the number of servers per application. Green threads will allow applications to scale with memory rather than additional machines.