Human beings are at their most creative when they're bouncing ideas off each other and trying things out and collaborating really closely. I think it probably used to be more true than it is now. But I don't really buy the myth of the lone genius in their basement writing software. I don't think it works. Professional software. to the 99.99 percentile just doesn't work like that.
From Tuple, this is Distributed, where we show how world-class engineers and their teams tackle the challenges of remote work. I'm Jack Hanna, your host. Let's get to the real work. Hey, everyone. Today, we're talking to Dave Farley.
Dave Farley is a globally recognized software engineer, author, and thought leader in modern software development. And building from Dave's 40 years of experience writing and studying the craft of software, he co-authored the influential book Continuous Delivery, created...
YouTube channel under the same name. And he uses this as a means to educate developers on agile and modern software development practices. And so in today's conversation with Dave, we're going to cover his personal backstory, how he developed such a strong point of view, how... Dave thinks about remote and hybrid work, as well as his thoughts on the current state of software development and where the industry is headed. So Dave, we're really excited to have you on today.
Thank you. Thank you for asking me. I'm looking forward to the conversation. I think there's some interesting things to talk about today. Yeah, no doubt. And so I'm wondering if you could start off and just tell a little bit about your software development journey going from maybe when you first caught the bug of software to where you are today. I think that I was fortunate in that I kind of grew up with computers. So pretty much as soon as home computers became a thing, I was a...
fairly early adopter of that. My girlfriend at the time, who's now been my wife for over 40 years, came home one day with a very small computer, a father who was a lecturer at university. borrowed for the summer holidays. So we took that and plugged it into our television set. It had one failed RAM, a ZIT processor.
Started learning to program on this thing and just had enormous amounts of fun. So I started writing games and got interested in computer graphics and I'm fast forwarding quite quickly. But my last... full-time job of writing software for a living really was built working in low latency finance systems so building trading systems of various kinds. I led a team that built one of the highest performance financial exchanges in the world.
and then later wrote some trading algorithms that traded against exchanges like the one that I'd built. So that was fun and interesting because that was also about exploring some of the unknown things. And I guess that's one of the things that I enjoy is the kind of challenges of solving hard problems. So I flipped during the latter courses.
parts of my career between working on kind of producty things working as a consultant and that gave me the advantage of those kinds of jobs i think is that gives you a pretty broad perspective
And so I got to see lots and lots of ways of doing it wrong, which I think is interesting. And I was fortunate. I got disillusioned with one of the jobs that I had and went looking for an... another job and I came across a company called ThoughtWorks who are a reasonably well-known consultancy who certainly at that time were kind of thought leaders in the agile development space. So ThoughtWorks applied extreme programming.
to their projects. And I think it's fair to say that Thor Works was one of the few places that was applying extreme programming to bigger, more complex projects. And we broke a lot of ground in terms of figuring out how to... apply what everybody at the time was calling a small team process to bigger projects. That led me into getting things wrong in lots of different and interesting ways and come up with solutions to that.
which turned out to be continuous delivery so Jez Humble and I both working at ThoughtWorks at the time started writing a book about that and that became fairly successful and as you said in my introduction I became fairly well known and my name became associated with what I think of as the kind of state of the art in software development still. At the end of my kind of software development part of my career, I became an independent consultant, and I was being reasonably successful.
companies around the world to help them improve their software development approach based on the ideas of continuous delivery and later modern software engineering, which is another one of my books. Then the pandemic hit.
And in the UK, we were kind of started into lockdowns and all of my work kind of fell off a cliff. And I was thinking, I don't know what to do. So I thought, oh, maybe I'll play with YouTube for a little while. And that's been... surprising in terms of the success and the impact that it's had it's been very pleasantly surprising but it wasn't what we expected we were doing it to fill time more than anything else when we started
So you talked a little bit about your journey as a software engineer and some of the experiences that... Colored the book, Continuous Delivery, how you got to where you are today. I want to talk specifically about your first exposure to remote or distributed hybrid work. Could you tell us or tell the audience a little bit about the first time you were exposed to working in a hybrid or remote context? Sure. So it was around about 2003. So I'd done...
tiny bits of working with people in other countries before and that sort of thing. But in 2003, it was when I joined ThoughtWorks. The first project that I worked on, I was assigned as tech principal. for a large distributed project. So the rationale then for ThoughtWorks was unusual at the time. It was less about... trying to save money by offshoring or anything like that. It was more about having access to pools of talented people because it was hard to find and recruit.
the kinds of talented people that we wanted in the company at that time. So the project I worked on, we were building a point of sale system for one of the larger electronics retailers in the UK. So we were deploying software to 10,000 different stores. So it's a fairly big project. There were about 200 developers working on this project. And we had development centres primarily on the outskirts of London, not far from where I lived at the time.
in India, in Bangalore, in Chicago, and on the west coast of the States. So we got very close to 24-hour... development going on. As I say, this was about 2003 so the internet wasn't very fast. We were working with these people from a range of different cultures and so we had to solve those problems. We got people... Americans and Indian people with different accents to us that made it harder to always...
you know interpret what was going on so we needed to cope with that kind of thing as well as everything else. So we did quite a lot to try and figure out how to make these things work.
One of the significant advantages that we had was that it was already basically an extreme programming project. So we're already doing test-driven development and... full-on continuous integration and we certainly had technical problems to face to make that work globally just in terms of getting the changes between one place or accessible from one place to another.
The network bandwidth to Bangalore at the time, at least for our team, wasn't great. And so getting the amount of data that 200 people are generating and shipping it around, making it available to people without having long latency, which breaks continuous integration. It was an interesting technical problem to deal with. But that was my first exposure. I think that the biggest lesson that I picked up from that is that if you want to do this...
The human connection is the real thing. The technical things you can fix. It's much more about the relationships and the people. engagement that matters. One of the things that we decided on early was that we were going to try and aim, because we were a big team, we were going to try and aim to have at least one person from each location at each place.
pretty much all of the time. So we had Indian people from Bangalore working in London. We had Indian people from Bangalore working in Chicago. We had Chicago people working in London with us and so on. So we kind of spread people around. And the idea was to try and build the human connection so we couldn't kind of sit in our offices and say, oh, they're all idiots over there and they're doing it wrong. We trust one another enough to try and work.
more collaboratively to get to the right answers. That project became a model for ThoughtWorks doing similar kinds of quite distributed projects for quite a long time. a long time before the pandemic and still to this day. So later, I worked for a trading company based in London, but the company was based in Chicago. So our time zones overlapped by three hours when we were on a good day. Part of my job there was to try and effect change in the quality of the software engineering in that company.
The team that I worked closest with was based out of Chicago. So it was me alone in London and four people in Chicago. And so we did pair programming remotely. I had a large screen at the end of my desk. that kind of was like a virtual extension into the Chicago office. And so I could kind of look across and I could see my colleagues so we could kind of interact those ways. So I'd done quite a lot of this. And...
I don't think that remote working is necessarily the barrier. You have to overcome these human limitations and, again, you have to know the people well enough. You have to establish the personal relationship. to really make it work. So in the trading company, we used to travel. Every six months, either they'd come to London or I'd go to Chicago.
depending on where we were in the rota. So we got to know each other personally. You know, we went out for a beer together and that kind of thing and had fun together. So we had a more natural, easier relationship when we were working remotely. I think those kinds of things help a little bit. Yeah. Obviously, the quality of video conferencing and so on alleviates a lot of those problems. But I still think that's a useful strategy to really do high-quality work.
Yeah, we talked a little bit about the how of creating the human connection. I want to pause on the why, because I think what you said at the beginning is that doing remote work well. isn't as much of a tool problem because the technical challenges associated with that are solvable, but the human connection side is the real thing. It's the most important part. And so why is it to you that building that trust, developing that human connection,
and connection is so important in making sure that folks can work productively or drive productive work to completion. I think that I probably have a slightly unusual view. point on software development and one of the aspects that i think is kind of special and interesting about software development is just how intensively creative it is if you think about it in almost any definitional terms it's
inherently a creative process. We'd be stupid if we weren't building something new every time because... We can recreate whatever we've got for free, so why wouldn't we do that if we've already got the thing? So we're always creating something new. We're always trying to solve problems that at least we haven't solved before, even if other people in the world have solved them.
And so with modern software, no one person these days is smart enough, scalable enough, has a big enough head to be able to... hold all of the things that need to be in it to build great software at the scale of modern systems it's a team game and so In order to do a great job, I think you need great teams. You need teams that trust one another, rely on one another, can argue with one another and still get on. We want to be able to chat.
challenging environments where we can, you know, if it was you and I, we could argue about ideas and kind of I could rubbish your ideas, you could rubbish my ideas in order for us to try and find the best idea. We want that kind of freedom. to be able to explore problems. That takes a lot of trust. That means that we've got to be confident that the other person is not trying to do us down, is not trying to...
rubbish our work or any of those kinds of things that we are aligned in terms of our objectives and our goals. I'm a sports fan, I watch.
Football. I think of it very similarly. So the best team is not always made up of all the geniuses. It's how all of those parts come together. And I think Software New Orleans is the same. You need to bring together... a range of different people with different skills, different interests, in order to be able to do this creative thing and solve these very hard problems that we challenge with in software.
And I like that about it. I think that's part of it. But I think it's those human connections. My wife says that I'm a collector of hobbies. So one of my hobbies in my collection is playing the guitar. And I used to play the guitar in bands, and so we used to write songs and things like that. And I was always rubbish at writing a song on my own.
but I was good at doing it with other people. And I think that part of being at the limit of human creativity, which I think really serious software development is... then part of what we're talking about is trying to maximise our ability... to be creative and to solve these interesting problems. And I think human beings are at their most creative when they're bouncing ideas off each other and trying things out and collaborating really closely.
I think it probably used to be more true than it is now, but I don't really buy the myth of the lone genius in their basement writing software. I don't think it works. Professional software... to the 99.99th percentile just doesn't work like that. You talked a little bit about...
The reasons for that and the characteristics of a great team that is able to achieve that. For example, they need to be able to rubbish each other's ideas, give each other feedback, go back and forth, participate in that creative process. requires an immense amount of trust between team members. So you talked a tiny bit about it, but...
what's your best advice for building that trust, especially in a world where on a day-to-day basis you aren't co-located? Even if you're hybrid, let's say, you're not day-to-day co-located with each other, which I do find helps. develop the trust. What's your best advice for how to go about building that trust? The most powerful tool that we would point to, and I'm not saying this just because of the company that you represent, but...
but I think it's pair programming, or at least ensemble programming. I think that working together in that way is a great way of, one, learning from other people, figuring out what they're good at, what they're not so good at. growing your understanding of them in all of its nuances and so on, collaborating on ideas so that it's not my idea, it's your idea, it's our idea.
And so, you know, if somebody else comes along and says, that's no good, we change it, we go, good, how could it be better? Rather than me being defensive, saying that was my idea, I wanted to keep it. So there's a lot to this. And so I think as a person who worked in... technical leadership in the latter part of my career, I started using pair programming and other things as tools to try and foster that kind of environment, that kind of collaboration.
I think there are other things, like in leadership positions, I think there's a... One of the phrases that comes from the Dora research is inspirational leadership. You need people who... inspire people to do a better job, not by being perfect or anything like that, but by being consistent. So demonstrating the things that you want to happen and being fair and open. And, you know, it's important that bosses and people don't...
all the people's ideas and claim them for themselves and all of that stuff it's and i'll keep coming back to that word again a good team the people the members of a good team trust one another and that includes the people around the edges so you want to build this This facility where we are all sharing common goals, common targets, and working together, organizing ourselves to figure out how to get there. Well, you've described pairing as the least understood and most undervalued.
practice of the extreme programming practices. Why do you think it's so poorly understood? I think there's a visceral dislike from people of the concept from people who've never tried it. My experience has been that if you ask people before they try and pair programming, at least 8 out of 10 will say, oh, no, I don't like that. And then after they've tried it, at least 8 out of 10 will say...
I don't want to work a different way in future. So pair programming is one of those things that people don't like the same dog before they train. I was in that camp. I joined ThoughtWorks, and I knew that they did full-on pair programming. And I'd done projects before ThoughtWorks, and we'd done...
kind of what I'd now call pairing light where we didn't do pair programming all of the time but we did it sometimes. So I was familiar with the ideas but I didn't really fancy doing pair programming all day every day. And then I started doing pair programming all day, every day, and I thought, this is wonderful. This is amazing. Going back to the thing that we talked about in terms of team building, pair programming builds these really strong...
relationships with people that I don't think you get any other way, at least I don't get, in software development. Some of my strongest friends from the software development are people that I've worked with in pair programming teams. because you build closer relationships. And that matters if we're trying to do this stuff at this leading edge of creativity. So there's this kind of visceral...
dislike of the idea, which puts up a barrier to start with. And then there's kind of the obvious critique, which is wrong, but the obvious critique, you know, if I may... a manager and I'm counting beans in terms of how to deliver software faster. Why on earth should I pay two people to do the job of one person? Well,
That's a stupid analysis. It seems obvious, but it's wrong. So if you look at the data, the data on pair programming is pretty strong and pretty consistent. If you ask two people to do... attached together and one person to do the same task the two people will do it in about 60 percent of the time that the one person
does it so they're nearly twice as fast but not quite but then if you look at the quality of their output quality is dramatically higher so if you measure productivity over the whole life cycle pairs are more productive than individuals working alone. The most productive teams that I've seen did full-blown extreme programming in one form or another. My favourite approach to software development and continuous delivery is...
Extreme programming with the volume turned up. More extreme, extreme programming really. It's the same thing, it's the same idea. And it just works better than other things in my experience. I think there's some resistance to people, both organisationally and individually, and it's one of those things of the way that you get people to adopt it, or the way that I try to get people to adopt it.
is to try it. And you can't try it for half an hour and say, no, I don't like it. That's not enough. So what I generally say to people is that talk to your team and get your team to try and experiment for one sprint. one iteration, two weeks, something like that, and pair program on everything. Don't write a line of code for production other than in a pair for that two weeks period. That's a bit stronger statement of pairing than I would say long-term. But initially, well, you know...
That's a way of forcing you to do it. It's a way of forcing you to take it seriously. And in my experience, after that period of time, as I said, about eight out of ten people will love it and prefer it to what they were doing before. Probably one person will not really like it very much, but we'll carry on. And one person out of ten usually will really hate it and really won't want to do it.
If you make the switch, you've got to figure out how you're going to deal with that person. Yeah, so I have a question about that sprint setup. This will feel a little bit tactical, but I think it may be helpful for folks because I think... a trap or a challenge that folks fall into when trying something new is the focus is still on getting the work done at the same quality and speed at which they did it before while practicing an entirely new way of working, which is just...
quite a high bar difficult task to do if you're used to doing something in a particular way. and you try an entirely new way to do that thing, you shouldn't expect that the output on your first go, I don't think, to be of the same output. So do you have any advice for how folks should approach... from a mindset perspective to ensure they don't fall into that trap? The problem there is not pair programming. The problem is...
Focusing in the wrong place. It's looking at the wrong thing. It's believing that the schedule, the plan is all. I think that's a symptom of that kind of thinking. And I think that's wrong. I think that... If you look holistically at what the style of software development that I try to promote, it's about focusing on doing high-quality work fundamentally. So quality is more important than speed.
If you and I are working on something this week, whether we're pairing or not, cut corners and generate crap code... Then next week we'll go slower because we'll spend time next week trying to do the new things next week and fix all the crap that we created this week. So that's a bad bet. That's a bad optimisation. You need to measure over the long term.
And if you measure over the long term, then quality pays. And we've got hard data, hard evidence for this from the Dora research. We know that if you build... software with high stability, that is high quality, doesn't introduce lots of bugs, and high throughput, the rate at which you're producing software, is fast, then... you will spend 44% more time on new features than teams that don't score well on those teams. So investing in building high-quality software quickly...
is the game. That's how you win at this game as far as we know so far. One of the other benefits of... pair programming is it removes latency from the process. We don't have to do pull requests and after the fact code reviews because we've got In the fact code reviews, we've got code review exactly the time when you want it, at the point at which you're about to make a mistake.
So that's the best time to learn. So pair programming gives us that feedback and allows us to build software that's kind of greater than the sum of the parts. If you and I are pairing together on something, it will be better than you or I. could work on alone. That's long-winded and not really answered your question but the problem is that there's kind of a philosophical difference between...
organizations that get good at this stuff and organizations that are not good at it and adopt. And that's another one of these barriers to entry, I think. So focusing on the wrong things, that is kind of meeting the schedule and all that kind of thing gets in the way a little bit. But... As a result, as a side effect of that, in looking somewhere else and fixing another problem, we end up going faster and we end up beating the schedule of the people that are keeping their eye on the schedule.
One of the strongest teams that I worked on was when we were building the financial exchange that I mentioned. I was hired as the head of software development for that organisation. while I was in the middle of writing a continuous delivery book. So it was like a clean room experiment in how to practice continuous delivery.
And so we did all of it. We did pair programming, we did acceptance test-driven development, test-driven development, full-blown continuous delivery all the way through, from day one, pretty much. As head of software development... I and the CTO would be the last interview for anybody that was coming into the technical team. And one of the things that I always said to everybody is, say, we do test-driven development, pair programming and continuous delivery.
You probably never heard of some of those things because this was a while ago. And that doesn't matter. But if you don't want to do those things, don't come work here because that's how we work. If you don't know how to do it, that's fine because we can teach you. So we'd bring people in who'd not done it before but were open-minded enough to give it a go. And they'd sit down as part of a pair, and on their first day, they'd be writing production software.
that would be going out the following weekend. And that's quite a good and best way of learning to pay to do test-driven development and all of these other things if you've never done it before. We would manage the pairs a little bit, how the pairing worked, so that those new people coming in were always pairing with somebody that was more experienced. We didn't put them straight with a junior, for example.
But it's a fast way of getting juniors to not be juniors. It's a fast way of getting new people to acclimatize to our software much faster than anything that I've seen before. There are certainly some costs to techniques like pair programming. I think that the benefits so dramatically outweigh the costs that it's the wrong place to look. I think your question kind of raises a bigger point, which is trying to identify what the value really is.
So is the value really hitting some arbitrary schedule, or is it producing great software as fast as humanly possible? I think the second one's much more valuable than the first one. And I think with that in mind, you have to accept that you may, when attempting a new practice,
Take a few steps back before you take a few steps forward, which is the benefit of taking that much longer term view. Because if you measure your success based on the effectiveness of that individual sprint, you're going to have a very, very... narrow view of what success looks like instead of looking at, well, what are the things that we could do today to improve our chances of doing the best work of our lives over the next 6 to 12 to 18 months?
Yeah, yeah. It's the wrong time horizon to look at to optimize the process. Absolutely. And there are times when you need to invest in people's learning. I describe software engineering as focusing on two. principal activities. One is optimizing for learning and the second is optimizing to manage the complexity of the software that we're building, the systems that we're building.
If you're optimising for learning, you've got to give space to allow learning to happen. So as a leader in a technical organisation, I'm going to allow particularly new people coming in. to get up to speed. I'm not going to expect them to come in and be producing as quickly as I want them to produce from day one. They're not. And they're also going to slow down the people around them.
while they're working alongside them, because those people have now got an extra task to do, which is to bring those new people up to speed. So, inevitably... But that's just part of the game, and particularly part of the game in working in larger projects. you're always bringing new people and there are always people moving on and all that kind of thing. That's just the nature of it.
I mean, you're obviously widely recognized for your views and your work in modern software development practices. And so I do want to spend some time understanding your views on where we're headed as an industry. just starting with a summary of where you think we are today as it relates to both the practices and how teams work together. I think of myself a little bit as a kind of natural heretic. I hold unpopular ideas. One of the unpopular ideas that I hold in software development...
is that I don't think that we're very good at making progress. Certainly, things progress. Hardware has changed at an incredible rate. But if you read... Books from the 1970s, like the Mythical Man Month, which describe the problems of writing software, if you ignore the bits that talk about the technology, they're exactly the problems that we face today. There is no change.
We've not improved very much at that. Now, I think that where we're at is that there's quite a big difference between the people that are really good at making software systems. And I think a very high proportion of those, without seemingly modest, do some form of continuous delivery. Because it's what works better than anything else.
And then there's the vast majority of organisations that build software. And from my experience working as a consultant... and consulting with organizations so it's certainly possible that this is just selection bias but my impression is that most organizations these days are working ways are essentially still a waterfall, which is a busted way, a way that doesn't really work, but with a kind of a veneer of agile words over the top, usually not even agile practice.
So I think that's where we are in one dimension. Technically, though, clearly there's something going on because we've switched probably only in the last couple of years from... all software being fundamentally written by people to some software being written by machines. And I think it's wise to be wary of the hype around some of this.
I don't think the machines are ready to take over and make us all redundant. I think there are more complicated aspects to this. But there's certainly aspects of what the machines are doing that are going to change the nature of programming. I think that where we are is that we're on the verge of stepping into the next generation of programming.
We're not quite there yet. I have a YouTube video which talks about this topic and talks about some examples. I think that what we're talking about is kind of raising the level of abstraction of programming so that we're no longer defining the solution. we define the problem, and then we let the AI assistant generate the solution. And I think we might be on the verge of something like that. So...
I don't know what that will mean to our industry in terms of employment, and I think anybody that says that they do is probably either misguided or lying. But my impression of working with AI to write software... is that it's quite a different experience. It's good at some things and bad at others. I observed that the code that I was trying to do...
I think I probably would have written more quickly if I'd written it from scratch on my own without the AI getting in the way. And I've heard experienced programmers say similar things before. And I think that's probably a little bit where we are, but I don't think that's where we're going to be for very long. Yeah. I'm curious how you feel about this shift or this inflection point.
I don't know. There's part of me that's nervous about it. But I think I would have been more nervous about it earlier in my career. The reason for that is a shift in perspective. I don't believe that the hard part of software development is coding. My problem is not the code that I'm going to write, it's how I'm going to solve the problem. And the code is just the way that I express that. I'm good enough at coding to express what I want in code, usually.
But what our task is really about is trying to specify accurately enough to a computer what it is that we want to happen for that to happen. I don't think that's going away. I don't think that can go away, really, because I think that if you think about what a program really is, you know, from a programmer's point of view, we're kind of looking at it from the inside out. We've worked to come up with a detailed set of instructions to a computer to tell it what to do.
What if we could just tell it what we wanted to happen and it filled out the detailed instructions? But we'd have to tell it what we wanted to happen in enough detail for it to do the right things, and then we'd need to... check that it did those right things. And so I think that's a very similar problem to a large part of the interesting parts of software development. The actual translation into a computer language.
That's not the primary goal of software development. The primary goal of software development is to solve problems with software. And so I don't think that the AIs are yet close to solving the problems unless they're... their trivial problems that they've seen before. If I ask it to give me some code to solve FizzBuzz, it's going to do it, and it's going to do it perfectly. But if I'm asking it to do something that hasn't been done before, if I'm asking it to do...
build a low latency trading system or something like that. It's not going to do that because it hasn't seen enough examples of that. We've got to be able to steer what we want the output to be, but... Whatever that actually ends up looking like, there are a couple of problems that we've got to solve. We've got to be able to specify things in enough detail that the machine's going to do what we want the machine to do.
And we've got to have a way of verifying that it did what we wanted it to do, because otherwise it's going to lie to us. That sounds a lot like test-driven development and behavior-driven development. I think that acceptance testing, behavior-driven development... is maybe the future of programming.
because of solving those two problems. And I don't think those problems go away until the AI is solving its own problems. As long as it's solving problems that we want it to solve, we've got to be able to tell it in enough detail. And I think, in general, human language is a really poor tool for that, because it's vague. The reason that we have computer languages is because they are more precise. than human languages. And the problem of being a computer programmer is that precision. It's not...
The typing, it's not translating that precise breakdown into Java or C-sharp or whatever else. That's not really the hard part. Those are the same kind of skills as learning to type. The hard part is how we decompose the problems into tiny enough pieces to be precise. So I think that what AI might do, at least in the first generations, until they can do everything.
that we can do better than we can do. I think that where we're going to go is that we'll have to find an alternative to a conventional programming language to instruct the AI. Natural language prompting ain't it. So I think it's going to be something more like the kind of domain-specific languages that we create in BDD to make writing these executable specifications easier to write. There's still going to be the need for the...
kinds of technical minds and technical thinking that computer programmers have. Yeah. Well, we spent a lot of this conversation... talking about the importance of human connection, of software development as a creative process, and that the creative process happens best when multiple humans are engaging with each other, going back and forth, giving each other feedback, building off of each other. In the world you just described,
what is the role of human connection or formal or informal pairing, teamwork, et cetera? So certainly with the current generation of AI, I've heard lots of people... say that it's a bit like pair programming working with an AI assistant. And I can kind of see that, but it's like pair programming with a kind of superhuman junior programmer.
They have a wide body of knowledge. They know all the APIs and stuff like that, but they're not very insightful. They're not really going to add strong, fresh, new ideas very often. If you want real creativity, if you're really solving hard problems, I think I'd still want the human interaction where I could find it.
I don't think that goes away. Even if we're writing these, the instructions to the AIs, our programs to the AIs in these domain-specific languages that we come up with, I probably want to be bouncing those ideas around with other people. I'm a believer that the singularity is on our horizon, and the machines will end up being better than us. That's everything. I don't know when that will be, but I think I don't see anything that's in the way of that happening, you know, from physics.
computer science point of view. So I'm sure that one day they will take it all over, but I think that's a harder problem than just translating a need into code. Because we've got to express the need. We've got to understand the need. And until they can come up with the need themselves, they can't do that. Well, I'm sensitive that we're...
Coming up on the time that we had allotted, Dave, and so there's one or two kind of final questions I just want to ask before we drop. What's one question about remote work or hybrid work that you don't feel like you have the answer to yet? There's lots of things that I don't have the answer to. I think that the hardest part of remote working is joining a new team without those human connections. During part of my career...
I worked for a company that was a long way away from where I lived. And so I was travelling during the week and living where I worked during the week and coming out on weekends. And then my wife became pregnant. And so I... I quit. And they say, don't quit, work from home. So I worked from home for three years, just on my own. And gradually, I got more and more disconnected from the team. That's a problem. That's hard to solve.
Again, it's down to this human connection and maintaining that. I think it would be easier these days because that was a long time ago.
And so it will be easier with things like video conferencing and all of those kinds, you know, the kinds of tools that we have access to now. But there's still that kind of... body language and if i say something and you think i'm being stupid you know there'll be a little twitch in your eyes and i'll think oh i said the wrong thing there and i'll be able to understand it much more easily than if and if we're doing this remotely you know so there's all those really subtle
that we get from one another. And I'm still old-school extreme programmer enough to think that this stuff is easier, at least, when we are kind of located and working together in the same room. I also don't think that we should be forcing people to do that. There are lots of advantages to working at home for both sides of the equation, for the employers and the employees.
I thought at the time when I first experienced working from home that it wasn't better or worse, it was just different. And there's kind of a trade-off between the things that are good and the things that are less good. You can't have your cake and eat it too. It's a balance. So you have more autonomy, you have more independence when you're working from home. It's easier to manage your own schedule. You can be in when the postman calls with a parcel. All of those things.
that you can look after your kids. All of those things are true, but you lose the sense of teamwork. to the same extent that you get when you are eating together and working together and all of those kinds of things. It's an interestingly challenging thing and I don't know how the answers to that are. Maybe it's full neural link style.
virtual reality i don't know but yeah i'm i'm not sure either though a common theme from everyone that i've interviewed is that Because there are tradeoffs, because there are inherent differences between the two, finding a balance. between in-person and remote time is key. I mean, without exception, everybody who feels confident in their remote working style that I have spoken to talks about being deliberate about getting together in person.
As well, at the start of big projects, when new team members join at sort of these pivotal moments where there's a unique opportunity to create a shared understanding or mutual trust, everyone has made it clear the importance of doing that. of thing and so i'm i'm with you there absolutely 100 i i agree with that i i think it's important and doing it on a regular basis not just on special to keep that human connection going
And even then, it's difficult. I felt really sorry for people when lockdowns happened during the pandemic. And I met many people. who got new jobs and so they'd been working for a year or so with teams that they'd never met in person. That must have been so difficult, so tough to do that and to get the kind of...
rapport and understanding between people to really do good work. Even short amounts of time at the right point have enormous value in establishing that kind of trust and relationship. So it's much easier to work with somebody. Once you've got that remotely. No doubt. Well, Dave.
Thank you so much for being generous with your time and your perspective. I've so enjoyed having this conversation and unpacking some of your perspectives on these things. I hope to connect again sometime soon. It's a pleasure. Thank you for asking me. I had some fun. If folks want to hear more about your work or connect to you or the channel, where should they go? Well, the easiest way to find me is go to YouTube and type continuous delivery into the search bar and you'll find my channel.
Yeah. I had a feeling you might say that. We'll provide links to all that stuff in the show notes for folks who are interested in learning more as well if they don't already know your work. Thank you again, Dave, for coming on. We'll chat again soon. Thank you. Thanks for joining us on Distributed. If you want to learn more about what we covered in this episode, or if you want to share your own thoughts, follow at Tupel on X or visit distributed.fm.