It's the biggest I think in my career. I think if we looked back at the history of software development as a whole, the comparable thing would be the shift from assembly language to the very first high-level languages. The biggest part of it is the shift from determinism to non-determinism and suddenly you're working with an environment that's non-deterministic, which completely changes.

It was in the late 70s, early 80s. Like so many things, it was kind of accidental really. At school, I was clearly no good at writing because I got lousy marks for anything to do with writing. But I was quite good at mathematics and that kind of thing and physics. So, I kind of leaned towards engineering stuff and I was interested in electronics and things because the other thing is I'm hopeless with my hands. I can't do anything that requires strength or physical coordination.

So, all sorts of areas of engineering and building things, you know, I've tried looking after my car and I couldn't get the rusted nuts off or anything. It was hopeless. But electronics is okay because that's all very, you know, it's more in the brain. You need to be able to handle a soldering iron, but that was about as much as I needed to do. And then computers made it even easier. I don't even need a soldering iron. So, I kind of drifted into computers in that kind of way. And that was my route into software development.

Before I went to university, I had a year working with the UK Atomic Energy Authority. I did some programming in Fortran 4 and it seemed like a good thing to be able to do. And then when I finished my degree, which was a mix of electronic engineering and computer science, I looked around and I thought, well, I could go into traditional engineering jobs, which weren't terribly well paid and weren't terribly high status, or I could go into computing where it looked like there was a lot more opportunity. And so I just drifted into computing. And this was before the internet took off.

My first job was with a consulting company, Coopers & Lybrand. We were doing advice on information strategy in the particular group I was with, although that wasn't my job. My job was I was one of the few people who knew Unix because I'd done Unix at college and so I looked after a bunch of workstations that they needed to run this weird software that they were running to help them do their strategy work. And then I got interested in what they were doing with their strategy work and kind of drifted into that. I look at it back now and think, god, that was a lot of snake oil involved. But hey, it was my route into the industry and it got me early into the world of object-oriented thinking, and that was extremely useful to get into objects in the mid-80s.

While I was at that consulting company, I met another guy that they had brought in to help them work with this kind of area, an American guy who became really the biggest mentor and influence upon my early career. His name is Jim Odell and he had been an early adopter of information engineering and had worked in that area. He saw the good parts of these ideas that these folks were doing and he was an independent consultant and a teacher.

I left Coopers and Lybrand after about a couple of years to actually join this the crazy company which is called PEK. I was with them for a couple of years. It was a small company. There was a grand total of four of us in the UK office and that was the largest office in the company. Having seen a big company's craziness, I then saw a small company's craziness. I did that for a couple of years and then I was in a position to go independent. I did, helped greatly by Jim Odell who fed me a lot of work basically. I remember leaving PEK and thinking that's it, independence life for me. I'm never going to work for a company again.

Famous last words. Exactly. I carried on. I did well as an independent consultant throughout the '90s and during that time I wrote my first books. I moved to the United States in '93 and I was doing very, very happily. Obviously, with the rise of the internet, lots of stuff was going on in the late 90s. It was a good time and I ran into this company called ThoughtWorks and they were just a client. I would just go there and help them out.

I had met Kent Beck and worked with Kent at Chrysler, the famous C3 project, which is kind of the birth project of extreme programming. So I'd worked on that, seen extreme programming, seen the agile thing. So I'd got the object orientation stuff, I got the agile stuff, and then I came to ThoughtWorks. They were tackling a big project, a big project for them at the time. Still sizable, about 100 people working on the project. So, it's a sizable piece of work and it was clearly going to crash and burn. But I was able to help them both see what was going on and how to avoid crashing and burning, and they figured out how to sort of recover from the problem.

But then they invited me to join them and I thought, hey, you know, join a company again maybe for a couple of years. They're really nice people. They're my favorite client. I always thought of it as other clients would say, "These are really good ideas, but they're really hard to implement." And while Thoughtworks would say, "These are really good ideas. They're really hard to implement, but we'll give it a try." And they usually pulled it off. And so I thought, "Hey, with a client like that, I might as well join them for a little while and see what we can do." That was 25 years ago.

Since I joined, that was my title. Well, it's important to remember I'm chief of nobody and I don't do any science. The title was given because that title was used a fair bit around that time for some kind of public-facing ideas kind of person. If I remember correctly, Grady Buch was chief scientist at Rational at the time.

And there were other people who had that title. So it was a highfalutin, very pretentious title but they felt it was necessary. It was weird because one of the things of Thoughtworks at that time was you could choose your own job title. Anybody could choose whatever job title they like. But I didn't get to choose mine. I had to take the chief scientist one. They didn't like titles like flagpole or battering ram or loudmouth which is the one I most prefer.

One thing that ThoughtWorks does every six months, and the latest one just came out, is the ThoughtWorks Radar. This latest radar, it just came out I think a few days ago. It lists things that they recommend using: pre-commit hooks, ClickHouse for database analytics, vLLM for learning LLMs on cloud or on-prem in a really efficient way, and they're also recommending a lot of different things related for example to AI and LLMs.

It started just over 10 years or so ago. Its origin was one of the things that we've really pushed at ThoughtWorks is to have technical people, practitioners, really involved at various levels of running the business. And one of the leaders of that was our former CTO, Rebecca Parsons. So Rebecca became CTO and she said I want an advisory board who will keep me connected with what's going on in projects. So she created this technology advisory board and it had a bunch of people whose job was to brief her as to what was going on. I was on the advisory board not so much for that reason but because I was very much sort of a public face of a company.

And then one of these meetings, Daryl Smith, who was actually her technical assistant at the time, he said it would be good to get some picture what kinds of technologies we're using and how useful they are and so as to better exchange ideas. So we thought this is a nice idea and he came up with this idea of the radar metaphor and the rings of the radar that we see today. And it's a habit if we do something for internal purposes, we try and just make it public. That's always been a strong part of the ThoughtWorks ethos. We talk about everything that we do and we share everything. We give away our secret sauce all the time.

So we did that and people were very interested and so we continued doing it. Now the process has changed a bit over time. As we've grown, we've created more of a process where people can submit blips, nominate them. A blip is being a point on the radar, an entry. They will brief us a little bit about it. And then they brief the members of the what's now called the Doppler group. And then at the meeting we'll decide which of these blips to put on the radar. It's very much this bottom-up exercise. For me it's a bit weird because I'm so detached from the day-to-day these days that it's just this lineup of technologies and things I have no idea what most of them are, but it's interesting to hear about.

ThoughtWorks has basically got several thousand technologists all over the world doing projects of various kinds to all sorts of different organizations. And the radar is a mechanism that we've discovered is a way of getting some of that information out of their heads and spreading it around both internally and to the industry as a whole. I really like how ThoughtWorks never said this is the thing for the industry. They said this is the thing for us. This is what we see. This is what we recommend our team members or our clients to consider. And we also encourage clients to do is to try and do their own radars.

AI is the biggest I think for my career. The comparable thing would be the shift from assembly language to the very first high-level languages, which is before my time, when we first started coming up with COBOL and Fortran and the like. That was a big change, right? You really needed to know the internals of the hardware and the instructions. With a high-level language like Fortran, at least I can write things like conditional statements and loops. It's better than what you can do in assembly. So there's a definite shift of moving away from the hardware to thinking in terms of something a bit more abstract.

I think it's with LLMs it's a similar degree of mind shift. Although, as I've written about it, the interesting thing is the shift is not so much of an increase of a level of abstraction, although there is a bit of that. The biggest part of it is the shift from determinism to non-determinism. And suddenly you're working with an environment that's non-deterministic, which completely changes how you have to think about it.

One of the key things about high-level languages is the ability to create your own abstractions in that language. That is particularly important as you get to things like object orientation or more expressive functional languages like Lisp. An old Lisp adage is really what you want to do is to create your own language in Lisp and then solve your problem using the language that you've created. And I think that way of thinking is a good way of thinking in any programming language.

AI helps us a little bit in that because we can build abstractions a bit more easily, a bit more fluidly, but we have this problem of non-deterministic implementations of those abstractions. My colleague Unmesh Jooshi has been really pushing this: using the LLM to co-build an abstraction and then using the abstraction to talk more effectively to the LLM. And that I'm finding a really, really interesting way of thinking about how he's working with that.

This has great parallels with the ideas of domain-driven design in ubiquitous languages and also some of the stuff that I was working on a decade or so ago around domain-specific languages and language workbenches. So there's some fascinating stuff around there that will be interesting to see how that plays out.

It's got some interesting parallels to other forms of engineering. Other forms of engineering you think in terms of tolerances. My wife's a structural engineer, right? She always thinks in terms of what are the tolerances? How much extra stuff do I have to do beyond what the math tells me? We need probably some of that kind of thinking ourselves. What are the tolerances of the non-determinism that we have to deal with? And realizing that we can't skate too close to the edge because otherwise we're going to have some bridges collapsing. I suspect we're going to do that particularly on the security side.

One area that has got lots of attention already is being able to knock up a prototype in a matter of days. That's just way more than you could have done previously. So, this is the vibe coding thing. It's an ability to try explorations. People can go, hey, I'm not really quite sure what to do with this, but I can spend a couple of days exploring the idea much, much more rapidly than I could have before. And so for throwaway explorations, for disposable little tools, that's a very valuable area.

On a completely opposite end of scale, one area that's really interesting is helping to understand existing legacy systems. My colleagues have put a good bit of work in this. The idea is you take the code itself, do the semantic analysis on it, populate a graph database with that kind of information, and then use that graph database in a RAG-like style. You can begin to interrogate and say, well, what happens to this piece of data? Which bits of code touch this data as it flows through the program? Incredibly effective. In fact, we put understanding of legacy systems into the adopt ring because we said if you're doing any work with legacy systems, you should be using LLMs in some way to help you understand.

And then there's the areas that we're still figuring out. I'm certainly seeing more interesting stuff as people try to figure out how to work with an LLM on a one-to-one basis to build decent quality software. We're seeing some definite signs of how you've got to work with very thin, rapid slices, small slices. You've got to treat every slice as a PR from a rather dodgy collaborator who's very productive in the lines of code sense of productivity. But you know, you can't trust a thing that they're doing. So, you've got to review everything very carefully.

Most of the experience we're gaining is building in a green field environment. So that leaves big questions in terms of the brownfield environment. Well, we know that LLMs can help us understand legacy code. Can they help us modify legacy code in a safe way? It's still a question. Another area that's really up in the air, both green field and brownfield, is what happens when you've got a team of people. Because most software has been built by teams and will continue to be built with teams. The question is, of course, how do we best operate with AI in the team environment? And we're still trying to figure that one out as well.

When I use the term vibe coding, I try to go back to the original term which is basically you don't look at the output code at all. Maybe, you know, take a glance at it out of curiosity, but you really don't care. And maybe you don't know what you're doing because you've got no knowledge of programming. My take on it is, I think it's good for explorations. It's good for throwaways, disposable stuff. But you don't want to be using it for anything that's going to have any long-term capability.

When you vibe code stuff, it's going to produce god knows what, and often it really is. And you cannot then tweak it a little bit. You have to basically throw it away and hope that you can generate whatever it is you're trying to tweak.

The other thing of course that's the difference, and this is the heart of the article that Unmesh wrote, is when you're using vibe coding in this kind of way, you're actually removing a very important part of something, which is the learning loop. If you're not looking at the output, you're not learning. And the thing is that so much of what we do is we come up with ideas, we try them out on the computer with this constant back and forth between what the computer does with what we're thinking. We're constantly going through that learning loop. You cannot shortcut that process. And what LLMs do, they just kind of skim over all of that and you're not learning. And when you're not learning, that means that when you produce something, you don't know how to tweak it and modify it and evolve it and grow it. All you can do is nuke it from orbit and start again.

I first came across refactoring at Chrysler when I was working with Kent Beck. I remember in my hotel room, him showing me how he would refactor some Smalltalk code. What he was doing was taking these tiny little steps. And I was just astonished at how small each step was, but how because they were small, they didn't go wrong and they would compose beautifully and you could do a huge amount with this sequence of little steps. And that really blew my mind away.

But Kent was at the time his energy was to write the first extreme programming book. He didn't have the energy to write a refactoring book. So I thought, well, I'm going to do it then. I started by, you know, whenever I was refactoring something, I would write careful notes. And partly because I needed it for myself. How do I extract a method so as I don't screw it up? And so I would write careful notes on each one. And then each of those turned into the mechanics in the refactoring book. And I did it in Java, not in Smalltalk because Smalltalk was dying sadly. And Java was the language of the future in the late 90s.

20 years later, I decided to do a second edition. When you've got a book that's written in late 1990s Java, it shows its age a bit. I decided to switch to JavaScript. I felt it would reach a broader audience that way and also allow a less object-oriented centered way of describing things. So instead of extract method, it's extract function.

Looking ahead with AI tools, they generate a lot more code a lot faster. I can certainly expect refactoring to be increasingly important. Because again, if you're going to produce a lot of code of questionable quality, but it works, then refactoring is a way to get it into a better state while keeping it working. These tools at the moment definitely cannot refactor on their own. But definitely the refactoring mindset and thinking how do I make changes by basically boiling them down to really small steps that compose easily. That's really the trick of it.

What you're doing with patterns is you're trying to create a vocabulary to talk more effectively about these kind of situations. I mean it's just like in the medical world they come up with this jargon in Greek and Latin to more precisely talk about things that are quite involved and complex. I certainly feel that they do help communication flow more effectively once people are familiar with that terminology.

One interesting thing that happened around the 2010s is the cloud started to get bigger. AWS, Google Cloud, and a lot of companies started to build similar things. These hyperscalers, the cloud providers, they built all these services that are really well architected. You don't need to worry too much about your data storage; you just use, let's say, DynamoDB or a managed PostgreSQL service. So suddenly architecture is not all that important because these blocks take care of it for you. You have these building blocks. His observation was maybe architecture was solved with a well-architectured building block that you could use and you didn't have to reinvent the wheel.

The origin of the Agile Manifesto, I always feel, was actually a meeting we had that Kent ran about a year before. It was a gathering of extreme programming folks. Part of the discussion we had was should extreme programming be the relatively narrow thing that Kent was describing, or should it be something more broad? Kent decided he wanted something more concrete and narrow. And then the question is, well what do we do with this broader thing and how it overlaps with things like what the Scrum people were doing? That's what led to the idea of getting together people from these different groups and we had the meeting in Utah.

Of the meeting itself, I actually don't remember very much of it. I do remember Bob Martin being the one who was really insistent on, "I want to make a manifesto." And me thinking, oh well, yeah we can do that. The manifesto itself will be completely useless and ignored, of course, but the exercise of writing it will be interesting. And then of course the fact that it made a bit of an impact was kind of a shock. And then of course it gets misused most of the time.

The great thing about agile is that we can actually go into organizations and operate much closer to the way that we'd like to be able to do. Our clients will let us work the way we want to to a much greater extent than we were able to do back in 2000. And so that is the success.

I still feel that building things in terms of small slices with humans reviewing it is still the way to bet. What AI hopefully will allow us to do is to be able to do those slices faster and maybe do a bit more in each slice, but I'd rather get smaller, more frequent slices than more stuff in each slice. Improving the frequency is usually what I think we need to do and just cycle out those steps more rapidly. That's where I felt we've had our biggest gains.

Well, the main way I learn these days is by working with people who are writing articles that are going onto my site. My primary effort these days is getting good articles onto my site and my view is that I'm not the best person to write this stuff because I'm not doing the day-to-day production work. So it's better for me to work with people who actually are doing this kind of work and help them get their ideas and their lessons expressed. I'm learning through the process of working with people to write their ideas down.

And of course, reading from where I feel are some of the better sources. Simon Willison's stuff is superb. I keep an eye on what he's doing all the time. I'm always interested in what folks like Kent are up to. Part of what I'm always looking for is a lack of certainty. I think that's a good thing. When people tell me, "Oh, I know the answer to this," I'm usually a good bit more suspicious. And I'm much more conscious of when people say, "This is what I understand at the moment, but it's fairly unclear."

For junior software engineers, the answer is what it's always been: find some good senior engineers who will mentor you, because that's the best way that you're going to learn this stuff. A good experienced mentor is worth their weight in gold. The AI can be handy, but always remember it's gullible and it's likely to lie to you. So be probing on asking it, "Okay, why are you giving me this advice? What are your sources? What's leading you to say this?" By probing that, you can get a better understanding of where they're coming from.

In a broad sense, I'm positive because I still feel there's so many huge things that can be done with technology and software. But really what's happening, the most important thing that's hit us is not AI. It's the end of zero interest rates. That's the big thing that really hit us. And that's what the job losses started before AI because of that kicking in. And so we have this weird mix of no investment, pretty much depression in the software industry with an AI bubble going on. And they're both happening at the same time.

I don't think AI is going to wipe out software development. I think it'll change it in a really manifest way like the change from assembly to high level languages did, but the core skills are still there. And the core skills of being a good software developer in my view are still, it's not so much about writing code. A lot of the skill is understanding what to write, which is communication, and particularly communication with the users of software and crossing that divide which has always been the most critical communication path.

At the moment my favorite programming language is Ruby because I'm so familiar with it. But the one that is my love is Smalltalk without a doubt. There was nothing as much fun as programming in Smalltalk when I was able to do it in the '90s. That was such a fantastic environment.

A book I do particularly like to recommend is Thinking, Fast and Slow by Daniel Kahneman. I like it because he does a really good job of trying to give you an intuition about numbers and spotting some of the many mistakes and fallacies we make when we're thinking in terms of probability and statistics. Another book that I'd mention is a book called The Power Broker. This is a book about a guy called Robert Moses. It's about how he rose to power, how power works in a democratic society, often not in plain sight. It's also a fascinating book because it is so well written.

If I'm going to pick something that's I think not too complicated for someone to get into that I think is still got quite a lot of richness at the moment, I think the game I'd pick out would be something called Concordia. It's fairly abstract in its nature, but it's easy to get into and it's got quite a good bit of decision making in the process.