Transcript
Holly Cummins: I walked here along the Thames this morning, which was beautiful. Anybody else managed to walk here along the Thames? Anybody throw up while they were walking along? No, good news. Had this been QCon 1858, the story might have been different. In the 1800s, the Thames was not the beautiful place it is now. The Thames was a sewer, and that was pretty bad. It got worse because in the summer of 1858, it was hot. Water levels got lower and the sewage got warmer, and you can imagine how those combined. It was really not good. The waste of 2.5 million people was flowing through a very small channel with very small throughput. This became known as the Great Stink. You may wonder where the technology comes in. I'm going to talk about Michael Faraday which I think counts as technology. Michael Faraday, who you may remember from The Faraday Cage, said, "Near the bridges the feculence rolled up in clouds so dense that they were visible at the surface." Disraeli, who went on to become prime minister, said the Thames was reeking with ineffable and intolerable horrors.
I think everybody had known for a while that something needed to be done, but in the summer of 1858, parliament itself got affected. They had built this beautiful new parliament building and they couldn't actually use it because the smell was so bad. If people went near the Thames, they risked throwing up, people were fainting. It was bad all round. The money that they hadn't been able to find for the problem before suddenly got found and they started a 20-year work of sewage. The embankment wasn't there at the time, but what they did was they built the embankment and they ran plumbing through the embankment to take all of the human waste away from central London. Think of that when you walk on the embankment. What they also did was they built pumping stations. This is Crossness Pumping Station. I just have this picture in here because, how beautiful is that? We do not build technology like that anymore. This is called the cistern chapel.
History Rhymes
Some people say history repeats itself, and some people say, no, history doesn't repeat itself but it definitely does rhyme. After I had prepared these slides, I ended up watching Dirty Business on Channel 4. Anybody else watch that as well? It was upsetting. The problem with the plumbing in London before they redid it was fundamentally a scaling problem. We've all had scaling problems. The Thames had insufficient throughput for the number of poo transactions that were being performed in London at the time. This is a throughput problem. To be specific, it is a poo throughput problem. If you want you can shorten that to a pooput problem. The reason there was a throughput problem was a direct consequence of previous architectural decisions. About 20 years before the Great Stink, someone had a really good idea, which is that they should eliminate cesspits in London. On the surface this seems like clearly a good idea.
Nobody wants cesspits. What is a cesspit? I always thought a cesspit was a metaphor, but a cesspit is an actual architectural feature. How it used to work was that you would have your nice house and then you would have a hollowed-out area underneath your house where just everything horrible went, and everything horrible just went down there and then it stayed and it stank and it was horrible. Everybody agreed that this was no good. A law came in that said instead of having cesspits we should have plumbing. Seems like a good idea so far. That plumbing should take the sewage and discharge it into the Thames. Suddenly seems like less of a good idea. The problem happened because we had this fundamental tradeoff between centralized stink and disease, which is what we got when we put the sewage into the Thames, and distributed stink and disease which is what we had when we had cesspits.
You can see that neither of these architectural choices is really very appealing, which is why they had to do something better and direct the sewage outside of London. The first implementation, they only directed the sewage about 6 miles outside of London and then continued to dump it into the Thames, which didn't actually work out so well. They did a second iteration where they properly got rid of it and started treating the sewage, which was an innovation that needed to happen. These sorts of tradeoffs where you have a good idea and then you have another good idea, and then yet somehow it doesn't quite work out the way you hoped. These happen all the time.
Anybody remember grid? The old people are, I remember grid. Grid went away. Nobody thought anything more about grid until grid came back and we called it cloud. We have these ideas and they just keep coming round, and it really starts to feel like nothing is new under the sun. Unfortunately, including destroying our home. Very old idea. We have a long-standing tradition of destroying our home. Every now and then we have another idea, which is, maybe it would be better if we didn't wreck our home. The reason we keep cycling between these two ideas is because there's a tradeoff. There are really good reasons to optimize for the short term, but on the other hand there are very good reasons to be sustainable. This is relevant for us in tech because right now one of the major things affecting our home isn't sewage, luckily. Aren't we glad to live in 2026?
The major thing affecting our home is carbon, and the tech industry is responsible for quite a lot of carbon. It is responsible for more carbon than aviation, which is what we tend to think of as the poster child for climate irresponsibility. If you look just at data centers, data centers use as much electricity as a medium-sized country like the UK. For us as tech professionals, this is relevant to us because we're the ones writing the things that go in those data centers. What we do with our software, what we do with our technology can have a direct impact on this. Part of the solution is clearly to use low carbon energy, but that can't be the only part of the solution, because even green energy, even zero carbon energy is not without environmental impact. This is the Itaipu Dam in Brazil. You can see that this had a significant impact on the landscape, and this isn't even the largest dam.
The Three Gorges Dam in China, when it was built moved so much water around that it was like a figure skater when they lift their arms. It actually affected the speed of the rotation of the earth, and the days are now 0.06 microseconds longer than they were before. If you're working longer, it's because the Three Gorges Dam made days longer. It also tilted the earth slightly. The earth's axis tilted by 2 centimeters just because of this human created structure.
Green energy, good. Green energy, we need to do more. We also need to be reducing what we use. This is, again, a very old idea. I won't go through everything we can do, but I do want to talk about two things we can do that are pretty easy and pretty effective. Again, these are old ideas. One is LightSwitchOps and one is efficient software. What is LightSwitchOps? LightSwitchOps is the idea, the very old idea, that maybe after you're done using something, you should turn it off in the same way you might turn a light switch off. It seems like common sense. Why don't we all do this? The reason we don't all do this is because those of us who have turned computers off in the past and had them never work the same again have been burnt by that experience. We've learned, don't turn the computer off if it's working.
We need to change that. We need to architect our systems so that they can tolerate being turned off. The other thing we need to do is think about software performance. Think about efficient software. This is where I have a very tidy intersection with my day job. I work on Quarkus. Quarkus is an extraordinarily efficient way of running Java applications. We've measured this. We did some experiments and we looked at carbon as a function of load for Quarkus and another framework which we don't name here but is Spring Boot. What we found is that with the line labeled legacy, the longer line is a higher throughput. You can see with Quarkus, it's got this very long line. It's got this high throughput. The lower line means it's got a better carbon footprint. You can see this really actually quite delightful correlation between having better throughput and being greener, using less energy.
It's probably a little bit easier to see. This was for a single instance. We then ramped it up so that we just added as many instances as we needed to support the throughput, to support the load. Then you can see a quite nice clear graph where Quarkus on JVM is, compared to Spring Boot, far more efficient as a way of running a Java application. What's going on? Why did we make these changes? Why did we design the system that way? What Quarkus did was it challenged what had been completely accepted conventional wisdom in the Java world, which is that doing things dynamically, delaying decisions, was a really good idea. Java historically has had absolutely loads of reflection. Once you get into popular libraries, they do huge amounts of work via reflection, which is a really expensive way to do it. It doesn't make sense anymore.
It used to make sense. Again, this is a conversation that as tech people, we just keep having over and over again. Should we be dynamic, or should we pre-decide things? Obviously, there's benefits to both. Should we be lazy in our initialization? Should we be eager in our initialization? In Java, for very good technical reasons, the balance had been very much towards being dynamic. It's statically typed, but almost everything else about Java is very dynamic.
When we got the cloud, all of a sudden, that balance shifted. An extremely dynamic runtime in the cloud doesn't make sense, because you're running in a container. Your runtime environment is almost certainly not going to shift in a significant way in terms of what software you have available on your class path. We don't need that dynamism anymore. That shift away from having one really big application running on-prem to something that's running maybe more with containers, more in the cloud, is a reflection of another shift, which is, should we be decentralized, or should we have something which is more central? The shift that happened about 15 years ago was we really swung very strongly towards more distributed architectures, and we got microservices, which are hyper-distributed architectures. Of course, having the hyper-distributed architecture does have some challenges. You have higher latency. You have more complexity. You have more infrastructure cost, but on the bright side, you get this resilient and you can have that independent lifecycle.
It is not a clear tradeoff. Around that same time, Git was introduced, and the promise of Git was that it was decentralized and distributed. That promise lasted for an extremely short amount of time before GitHub went, people don't actually want that. People really quite like having a centralized place to put their source code. GitHub has been enormously successful. We see similar questions now. In the age of AI, we're seeing this absolutely enormous investment in data centers from all of the big companies. We're talking hundreds of billions of dollars in data centers. The ROI on these data centers is somewhat questionable. Some companies are going in a different direction. What Apple is doing is that it is not building its own data centers, it is not building its own models, it's licensing them for a fraction of what it would cost to actually run a data center.
It's putting AI capabilities into its hardware instead. What this means is that instead of having to spend $100 billion on a data center, Apple is manufacturing hardware and it is selling it to us so that we can buy that hardware and then run those AI computations on our hardware in a decentralized way. We're happy because we have shiny Apple products. Apple is happy because we've just paid them a bunch of money for the privilege of running the machine learning workloads.
Hype Cycles and Investments
I mentioned microservices and I mentioned AI, which means I can now introduce this quote from the great Venkat. He says, "I'm so thankful for AI. Finally, developers are no longer chanting microservices constantly." If you've been to a few QCons or really anywhere, you will recognize this pattern, which is that this year, every talk seems to be about AI. A couple of years ago, every talk was about microservices. Now we're not talking about microservices anymore. These things, they seem to become enormously important, and then they go away again. What's going on? It is a hype cycle. It's the hype cycle. If you've been around for a while, you'll have experienced a whole bunch of these hype cycles. Grid was going to save everything, and then Internet of Things was going to save everything, and then digital twin was going to save everything, and then model-driven development was really going to save everything, and then low-code definitely saving everything.
Cloud Native, yes, absolutely. Microservices, Kubernetes. I don't know if you remember a while ago, the parent company of Cloud Foundry had this enormous nosedive on the stock market. The reason they had a nosedive on the stock market was investors noticed that Cloud Foundry did not contain Kubernetes. This was quite obvious to most of us, but it was a surprise to the investors, and they were horrified when they found out, and they immediately sold all of their stocks, because it didn't have the buzzword of the moment. The nature of these technologies is that we get very excited about them individually and as an industry, and then we have the morning after the technology before, where we realize it didn't actually solve all our problems, and then we go back in the other direction. For example, Amazon Prime Video published a blog a few years ago where they announced really excitedly that they had moved away from microservices to a monolith, and they had saved 90% of their costs. What does this show us? I don't think it tells us very much about whether we should use microservices or a monolith, but it tells us that the lunch was not free. We were promised a free lunch, and we have now been extremely disappointed by the price tag.
Meredith Whittaker, the president of Signal, had a really interesting quote a while ago. She was asked what technology did she think was most overhyped. She didn't say AI, she didn't say microservices. What she said was, "It's not simply that one piece of technology is overhyped, it's that hype is a necessary ingredient of the current business ecosystem of the tech industry." What did she mean? Of course, what we have now is that list. We have AI, and, unlike everything else, AI is definitely going to solve all of our problems. We're getting enormous amounts of hyperbole about AI. Anthropic's CEO says that in 3 to 6 months, AI will be writing 90% of the code. Unfortunately, he said that a year ago. Microsoft's AI chief says, this time we're serious, in 18 months, all white-collar work is going to go away to be automated by AI. Why would people say that when it's so obviously not true?
The reason is venture capital, because, how does it work if you want to make money off a business? Let's say you have a great idea, and you start your little baby company. In order to grow your baby company, what you need to do is you need to attract funding, so you do funding rounds. Each funding round, you attract investment, if you're lucky, and then you carry on building your product, and then you go to your next funding round where you get more money, hopefully. Then you just keep going through this cycle of funding rounds, until eventually you get to what's called the exit. The exit is when enormous quantities of cash flow in. The best thing about the exit is that usually the exit will be something like an IPO, or an acquisition. What that means is that this company is no longer your problem.
This company is someone else's problem while you skip happily to the bank carrying huge sackfuls of cash. Everybody is very keen to get to the exit, and people aren't necessarily super concerned about what happens after the exit because they've skipped off to the bank. How do you get to an exit? How do you get through those funding rounds? What attracts investment? I think in an ideal world, we would say things like stability attracts investment, profitability, being well-managed, having stable sources of revenue. Unfortunately, we do not live in the ideal world. What attracts investment is growth. What attracts investment is excitement. This is because the investors need to feel the excitement, but they also need to have confidence that everyone around them is feeling the same excitement, so that they can have follow-on funding rounds, so that they can get to the exit. The likelihood of selling your stake at a profit, which is what you want if you're doing an investment, is higher if you have that growth and that excitement, and that's what drives the hype.
What we're being promised in the current round of hype is a world without developers. This is actually a very old idea. I mentioned low-code earlier. The promise of low-code was exactly the same. You don't need to have developers. You can just use low-code tools, and the management will be able to write everything. It's an even older idea than that. This is COBOL. You may not think it looks like English, but at the time, it was advertised as English language programming. The idea was that COBOL was so comprehensible that your manager might not be writing your code, that was maybe a stretch too far, but domain experts could certainly be writing code, and your manager could be reading your code because of the magic of this highly expressive programming language. COBOL did not make the development profession go away. In fact, it was the opposite. COBOL unlocked this whole new profession of application developers instead of system developers.
This is a really good example of what's known as Jevons Paradox. Jevons Paradox says that efficiency improvements can lead to increased consumption. I always find the easiest way to think about Jevons Paradox is in terms of highways. We've probably all got a road that's got too much traffic on it that we have to go on, and then at some point, they announce they're going to widen the road, and we think, amazing, at last, the same amount of traffic will be running along this much wider road. It will be heaven. This is not what we get, this is what we get. Because as soon as the road is wider, all of those cars that had been put off going on that road go, amazing, and it takes you exactly as long to do your journey. It's just that more cars are doing the journey. This is exactly the same, I predict, for software.
This makes it quite different for some other professions. Many professions have gone away because of technology and continue to go away because of technology. For example, I think this might be my favorite ever profession. This is a knocker-up, which sounds extremely funny if you're from North America. Their job was a human alarm clock. It was nothing more sinister than that. What a knocker-up did was, in the Industrial Revolution, people needed to get to their factory jobs, but they didn't have alarm clocks because it was the 1800s, and alarm clocks wouldn't be invented for another hundred years. They needed a human alarm clock. The profession of knocking up actually continued for a very long time. It lasted all the way to the 1940s, and it lasted to the 1970s in some parts of England. Of course, inevitably, the knocker-up profession disappeared, because there is fundamentally very finite demand for this.
Only people who have a job outside the home need waking up, and nobody needs waking up more than once a day. You don't say, I enjoyed that experience of being woken up so much, I'd like six of it, please. It doesn't happen. With software, it's really different. The more software we have, the more software we want. We seem to have this infinite appetite for software. Of course, we need the software to do stuff, but then we need the software to do more stuff, and then we need the software to tell people about the software. Then we need the software to bypass the advertisements in the software. Then we need the software to bypass the bypass so that the ads still show because somebody has to make money. Then we need the software to gamify the software. Then we need the software to monitor the software.
Then we have the software to manage the software. Then we have the software to write the software, welcome to 2026. Of course, now, we have the software to debug the vibe-coded software, welcome to 2026. Now we have the software to manage the software that writes the software, because it's all a little bit complex. Then, at that point, we really need software to try and avoid Skynet, and then we may as well work at the meaning of life while we're at it. This could go on for a really long time, but I've run out of screen. If you look at the history of the software engineering profession, each time we've had a new layer of abstraction, the number of developers hasn't gone down, it's gone up. Each time it was predicted that software developers would go away because now we had COBOL, now we had frameworks, it just fundamentally didn't happen.
Some of you may be thinking, that's nice, but I've seen the job numbers, I've seen the news. The USA developer vacancies, it's not good. The numbers have gone very down. In the UK, it's slightly better, but it's looking a bit bleak. If you read the news, there's layoffs announced it seems like every week. Every time the layoff announcement says we're doing so well with AI, we're getting rid of people. We're doing so well, we're getting rid of people. We're doing so well, we're getting rid of people. What these announcements are saying, often they're coming from companies that have an AI product. If you have an AI product, and the promise of your product is that it allows everybody else to get rid of people, you have to get rid of your own people too, to show that your product works, otherwise nobody's going to believe you.
This is saying our AI product is working. For the companies that don't have an AI product, there's still quite a lot of FOMO out there. Everybody else is saying that they're getting these extraordinary productivity gains from AI. We need to show that we are too, or people are going to think our company's not being run well. We need to show our AI strategy is working. This is called AI washing. It's putting AI into a headline to disguise news that maybe isn't so good otherwise. For example, Block had significant layoffs. Their business really wasn't doing that great before the layoffs. Another factor behind these layoffs is overhiring. Overhiring is basically people-stockpiling. This blows my mind slightly, but it is an accepted business practice. There's many reasons for this, but one of it again comes back to this idea of attracting investment. What makes you look really successful?
If you're hiring loads of people, whether you need them or not. This works ok until the economic cycles bite. There's a recurring idea of free money, and you may be thinking, I'm fairly sure. I have never had free money. There's no such thing. Almost all of us have borrowed money. When we borrowed money, we had to pay something for the privilege. Depending when we borrowed it, we might have had to pay quite a lot or a little bit less. This is financial debt, also known as debt. The nature of debt has changed recently because we had been in what's known as a ZIRP. A ZIRP is a zero interest-rate phenomenon or a zero interest-rate period. You might think that zero interest rate means zero interest. Foolish. It doesn't. What it means is less than 1%. There isn't free money, but there's almost free money. Until quite recently, so if you look since 2010, interest rates have been bumping along at around 1% until the last 3 years when all of a sudden they shot up.
This was quite a shock to a lot of organizations, and they had to change how they were being run because all of a sudden money wasn't free. In the bigger picture, actually the exceptional period was that last 15 years. Since, if you look that's that period that most of us are used to. It's actually a little bit of an outlier in a broader history of high interest rates. High interest rates really affect investor behavior. Because if I have this dream of doing a startup and getting the investment, it's not guaranteed to get to the exit, of course. It might be that everything dies after the third round. All of that money that was invested just goes up in flames. Investments in companies have risk. If I'm an investor and I have my pile of money and I need to decide what to do with it, I could put it in a software company or I could buy government bonds.
In a zero interest-rate period, the risk is really high with a software company, but the return is potentially really good as well. With the government bond, the risk is low, but the return is 0%. That is just wasting my money. I'm going to put it in the software company. On the other hand, in a post-ZIRP period, all of a sudden that government bond is giving me maybe 4%. Compared to that really high risk with software, it starts to look attractive. Some investment gets siphoned away from software into safer forms of investment. If there's less investment, there's less hiring, and that means less jobs for us. You can see this if you look back at those employment figures. That big peak wasn't with the introduction of GenAI. That big peak was when interest rates were really low, and that downward slump was when interest rates rose.
ChatGPT didn't really make much of a blip on those job figures. Again, this comes back to the fact that software is not going away, and because software is not going away, developers are not going away. This is in fact confirmed by the latest data. If you look at the latest data, developer vacancies are going up again. Hiring is on the up. You may say, that's just because the economy is on the up in general. It's not. The gray line is the overall hiring. You can see it's still staying pretty low. Developer vacancies going up.
A World Without Work?
Does that mean that everything is perfect? Not quite, because another long-standing dream that people have had is a world without work. Every time productivity increases, we are promised that this productivity increase will eliminate work. In 1930, Keynes said that by the 21st century, we would all have a 15-hour week. Reality is somewhat different. What many of us are experiencing instead is a world without rest. We're really struggling with burnout. We have all of these ideals of like we need to do the hustle, and we need to do the grind, and we need to do the 996, which brings us to, unfortunately, a new form of debt, which is sleep debt. The good news, which is also terrible news, is that this is also not a new idea. In 1826, the average working week was 66 hours. The typical working week was 6 days, and you would work 12 hours for 6 days.
The interesting thing about this was that that was actually a peak. This is an incredible dataset, which shows the average UK working hours from like 1300 to now. That big peak was the peak of the Industrial Revolution. We had enormous productivity gains, and yet we were all working more. Then eventually we realized that maybe working more wasn't actually helping us as much as we hoped. Henry Ford realized that he could change his factories from having a 6-day week to a 5-day week, and productivity basically stayed the same. This is because, for people, there is actually a huge amount of value in doing nothing at all. The default mode network is a part of the brain that becomes more active when we're doing nothing, and it helps us solve problems. Then the question is, now that we have AI, are we doing more nothing? Unfortunately not.
Professions using AI are working 3 hours more per week than other professions, than they were before AI. This is something that's been widely reported, so I've seen this slide several times. AI intensifies work. AI is making us work longer. This article says, it's a paradox. Yes, it is a paradox. This is exactly Jevons Paradox in action, because we have this extra capacity, because the cost of doing things is lower, we are doing more things. For a lot of us individually, what we're experiencing is a combination of euphoria, because we can do so much with the tools, and also fear, because we've seen the news, and we've seen those layoff figures. We're entering this productivity panic, where we're going as fast as we can and producing so much stuff. That article I showed had the phrase disposable busyware, which I really like, because we're producing so much stuff that the build versus buy has shifted completely towards, let's just build it, and then let's throw it away, and then let's build it, and let's throw it away.
The fact is, maybe we should think about whether the world actually needs us to be building all of these things. Should we be producing these things? Because workslop is pollution, fundamentally. We are polluting our digital environment with stuff that we didn't really maybe need, and we should have asked, should we build this? Because code isn't an asset, code is a liability. Even good code is liability. The more code we have, the more technical debt we're bringing on. What we've agreed to is vibe now, pay later. We are definitely starting to see the pay later part as well. Of course, it's been widely reported that after several outages, Amazon has now told its staff, you know those agents? Maybe don't use them. The rumor I heard was that there was a moratorium on agents for a week, and that junior and mid-level developers aren't allowed to ship agent-produced code without a senior sign-off. There's this very strong rollback.
The Return of Engineering Discipline
Another thing that's coming back is engineering discipline. Kevlin Henney said he wanted to write a talk called, I told you so, which I liked. Because these ideas that, "Maybe we should do small steps. Maybe we should commit as we go. Maybe we should do all these things." They're fashionable again, which is really good for those of us who appreciate these. TDD is back, which as a TDD advocate, I love. The spec is back. I'm less sure about this one, I have to say, but maybe the specs will be different this time round. My first role, we had to write a spec, it was 500 pages. Mixed feelings about the return of the spec. The reason that we need this is to try and get a handle on something that's happening in our systems, which is epistemic debt. This is something I heard from Simon Wardley.
Epistemic debt is the collapse of competence. It's what happens when you ship code you don't understand. This is also a really old idea. Remember COBOL that looked like English? Dijkstra said the use of COBOL cripples the mind. He said COBOL was so terrible that teaching COBOL should be considered a crime because people who had learned COBOL could just never become proper software engineers. This is a balance that we've been struggling with for a while. This is a tradeoff really between getting stuff done and understanding the low-level details. There's a lot of snobbery around this, I think. Hello, Dijkstra. Understanding the low-level details sometimes has value, but ultimately none of us, no matter how good we are as engineers, understand all of the low-level details. None of us are hardware engineers. Very few of us are programming in assembler because we want to get stuff done. We have to operate at that higher level of abstraction.
Connecting The Dots: Debt, Tradeoffs, and Circular Ideas
Srini said I was going to connect the dots. I think I've connected all of the dots or at least I've talked about all of the dots. I've talked about three things. I've talked about debt. I've talked about tradeoffs. I've talked about circular ideas. We've had ecological debt. We've had financial debt. We've had technical debt. We've had epistemic debt. We've had sleep debt. What is debt? Debt is a tradeoff with the future. These ideas keep coming back round because they come back round when the tradeoff shifts. When all of a sudden the tradeoff tilts because the outside environment changes, an old idea that we had all dismissed can become fashionable again. At that point, it doesn't look like a tradeoff. It looks like we're having our cake and eating it too. When I was talking to the program committee about this talk, we were talking about, what will you hear that will make you better at your job?
I think this is, how do you get better at seeing the repeating patterns? My first thought for this was to be old. That's not really actionable advice. It's not even true, actually. Probably most of you have heard of Greenspun's 10th rule, "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of common Lisp." This is exactly a prediction that things are coming round again. Anybody want to guess how old Greenspun was when he wrote this? He was 29. He wasn't old and grumpy. He was young and grumpy, and he still came up with this insight. What I would really recommend you to do is always step back to these fundamental questions. What problem are we trying to solve? What's the tradeoff? I would really encourage you to be curious. Be curious about the past. Also be curious about the present.
Why are things the way they are now? Are there assumptions that have changed? Because if the assumptions have changed, that is a big opportunity. We're seeing there's a continual reset of assumptions. We're seeing an introduction now of analog computing, which can be far more energy efficient and performant than digital computing. We're seeing that SQL didn't die. It's coming back. SQLite has done really cool things with SQL. I mentioned Quarkus. Quarkus is really making Java as performant as other languages like Go. We're seeing GitHub had this enormous opportunity of moving back to a centralized model. Look for those opportunities because they can really pay off.
Conclusion
Nothing is new under the sun. There are no new ideas. Unfortunately, there almost always is a tradeoff, but sometimes there isn't a tradeoff, which is cool. Think about the sustainability of your IT. It really matters. It matters for the environment, and it also matters for people to have a sustainable pace of work. Of course, financial sustainability ultimately does come back to bite you if you haven't got it. Look for those ideas that everyone else has forgotten and recycle them, because you may find that as well as being sustainable, because you're recycling, they turn out to be really good ideas in the modern context.
See more presentations with transcripts
