Die Evolution der Entwickler

Good afternoon. How are we doing? Day one. Go to.

Sunday afternoon. So yeah, that was a fun one to explain to my wife. I'm just going to be travelling

to. Welcome. I want to talk about human beings. So who here is a developer? Nearly all the

hands went up. Who isn't a developer? Are you all sort of managers? Are you your causes

of work in developers? Or you coach developers? If you're in Martin's talk this morning,

it's brilliant. I love Martin's talk. And he started off with, there's coming out of some

quotes about, you know, that we sort of think of as fairly modern in terms of software and

you're saying, you know, Alan Perlis said this in 1967 and, you know, Melvin Conway said that thing

in 1968 and all of this stuff like, you know, we've been there before. I want to do what

to do something a little bit similar. I want to go back in time. I want to talk about what it used

to be like to be a developer and how that's changed over the years and what that means for us.

Right? Well, that means for us as developers. So let's go way way back. Let's go back to the

old testament. Okay. So in the beginning, in the beginning, we're not all the way back. 1844. Does

anyone know what this is? One hand went up, go, what is it? No, no, no, the other love

laced. This is a reproduction of, so this is all of the software in the world in 1844. This is

arguably the world's first computer algorithm. So the story is Charles Babbage who's invented

this computing engine, this arithmetic engine thing is made out of steam and goats and stuff.

And he's explaining to people how it works and what it does and that you can get it to do calculations.

And there's this young Italian guy in the audience who went on to it turns out to become the

Prime Minister of Italy. But he's making notes and it turns out he's making notes in French. I

don't know if he's showing off or what, but he's making notes in French. And so a little bit later,

Charles Babbage decided it might be useful to have this translated, so he's got notes of his talk.

So he asks a young lady. Her name is Augusta Ida Kingnoll. We know her better as a

love-laced accountist of love-laced. She is the daughter of Lord Byron, Lord Byron, famous for being

a opium-fiend and poet. And so a Lord Byron sort of run off and galvancing with all these women and say

his wife said, right, there's no way his daughter is going to grow up to be a poet. So we're going to

teach her engineering and science and math and stuff. And so Aida love-laced had a very unusual

education and she was educated in a very scientific way. And so she took on this job of translating

this stuff for Charles Babbage from French. And on the way through she made some notes and they were

very originally called notes. So all of the notes are just a little note. And note G, which was the

previous picture, that is her making a notation of essentially how you could teach this analytical

engine to do binary numbers, to calculate binary numbers. So she saw that you could take a computing

engine and give it instructions and make it do stuff. Okay, no tests. Okay, just going to put that

out there. But you know, they didn't have a computer, so that's fair enough. So this is 1844.

This is all the programmers in the world. So that's two things. Firstly, all the programmers in the

world with female. And secondly, all the programmers in the world really knew how to dress.

Who knows their own t-shirts and shabby jeans and whatever and she's like, I mean, that's quite an

outfit. So okay. So time passes. Okay. Does anybody recognize that? Any hands going up?

No, you have a couple of hands. One of my favorite favorite games of all time from the 1980s,

it's the Hobbit, the Hobbit adventure game and your type in things. And it said, and if you typed

in weight, it said, you wait time passes. And if you were with Thorin, Thorin waits as well.

Which is kind of nice, you know, Thorin doesn't just walk off and leave you, Thorin waits with you.

Which is nice. So 100 years later, okay, it's now 1944. Things have got a bit serious now.

So the only deal of a computer has become, and as with many of these things,

okay, Martin alluded to this in the morning, most technical innovation tends to start in the military,

tends to start in defense. And then it goes into academia and then it goes into commerce,

it goes into business. And so for instance, the internet started as an exercise in getting

computers connected to each other by DARPA, the US defense, advanced research project

agency, and it was originally called ARPANET and then it went into universities, it was called

Janet, the joint academic network, and then we knew it as the internet. So computers are being used

to crack codes, okay? So this is two women, because again, all of the programmers are at the time

more women. And these women genuinely are hackers, right? Because they're hacking, they're hacking

the rent cipher, the crypto that went into the, into the enigma, cryptography machine.

And according to Wikipedia, the, the, the, the, the founder of all knowledge, this is Dorothee

Divosor, an LC booker, who are a couple of early programmers. And so in assessed his mother

invention, and then then what happens? And then we invent tools. So this is Admiral Grace Hoffa,

one of my heroes. She invented the compiler, because, because she had to, because it sucks not to

have a compiler. There's a wonderful interview with her on a chat show. And I can't remember who's

interviewing her. But he says, he says, so, so, so, so they hired you, um, because what you

were that you were a computer expert. And she's like, they weren't any computer experts. We were

inventing this stuff as we went along. So she invented the compiler. She also invented the nano

second. I don't know if you know about this. So what she was doing, she was trying to explain to

other admirals in the US Navy and US military in general. She was saying, you can't have

instantaneous communication with your ships at sea, because space. Right? And they said, well,

well, why do I? I can pick up a telephone and blah. And she said, no, let me explain. And so she

phoned down to the machinery. She said, I need you to cut me off a bunch of lengths of wire about that

long. Okay. And so, 100 lengths of wire. So she would walk around with these lengths of wire

around her neck. And when she was in a meeting, she said, here, have a nano second. And she'd

pass one of these lengths of wire. And like, what's that? That's a nano, that's how far light

travels in a nano second. And so then she'd say, right, so now what happens is this, when you send a

message, the light travels in nano second. So we've got to lay these things out. Yeah. So every one of

these all the way up to the ionosphere and all the way back down to the ship, right? Every single one

of those is a nano second. That's the shortest possible time you can have communication in.

And they were going, oh, oh, she also had some micro seconds as well, but they were much longer.

They'd be coils of wire. That's how we invent tools. And then, okay, so now we've got some tools.

And now people start to specialize. So this is now in the 60s and computing has become

simply enough even men can do it. And, and so we've got these two guys here debugging a mainframe.

This is an academia now. And of course, pair programming, which is nice, right? So, you know,

they got into that pretty early on. And so people start to specialize. And so you get into

these different kind of specialisms. So it wasn't just come in and fix stuff. It was, well,

you know, we've got the idea of an analyst and a program and whatever else. And so we got

commandments. Okay, so then we just want to lay down rules. And we'd say things like,

you shall have a business requirements document. Okay? Because this is what we do. When we take

things into industry, we like to put rules around it. And we say things like, you shall have a functional

specification, you shall program in the manner of the specification. Okay? You shall have no other

specification before me. Okay? There is one truth, right? And you code to that truth. Analysts

shall analyze architecture, architect. We have these silos of specialism. And then we say program

and show program. And by that we mean take a detailed functional specification and turn it into code.

It's like an intray out tray kind of thing. And then a test of the shell test, which is taking the

crappy code and turning it into bug reports, right? Similar sort of deal. Okay, there's more.

There's more commandments. It doesn't stop there. You shall complete a formal change request.

You don't just go, this could be better. I think if I brought my baby and put it at my feet

and figured out how to land a rocket on the moon, right? I could probably, no, no, no, no. Do you have

a functional specification? Do you have a formal change request for that? No, no, I don't.

You shall provide release documentation. Okay? You don't just get to put stuff into production.

You shall not release to production yourself, list you incur the wrath of the release manager.

We still have that one. That hasn't gone away. You shall not hack on that, which is in production.

More of a guideline, really.

But then, this was my early career. This is probably up until I'd know, 1998, 1999. I started

programming. I'm much younger than Martin. I started programming in the mid-80s. Okay, about two years.

But like professionally, as well, not professionally, but as a graduate,

probably 91. 91 onwards. So the first 10 years of my career, this was normal. This is how you did work.

And then, and then stuff happened. Right? Then we got the new testament. And this was around

about 2001. It was a new covenant, a new deal, a new contract. This is Linda Rising famously

calls this the Council of Middle-aged White guys, which are quite like. This was Bob Martin

late 90s, early 2000s. He knew a bunch of people. And all these people were trying to solve similar

problems. Okay? They were essentially what they were trying to do was help teams deliver stuff

in big companies. And what they were tend to do is, you know, we have these multi-year massive

programs of work. And various different people had these guerrilla approaches. And these guerrilla

approaches had names like XP, DSDM, FDD, Feet of Driven Development, Crystal, Adaptive,

Scrum. Right? So all these loads and loads of different methods that people have come up with

the name. And it's like, okay, this is great. But that's really kind of fragmented. We need an umbrella

term. It's come together and come up. And so they did. And it turns out that they actually tried this

in 2000. And they all met up in a ski cabin in Utah. And they spent the weekend drinking whiskey,

because that's what happened when he gets 17 middle-aged white guys together. And apparently nothing

happened. And so they went, oh, well, I mean it was great fun, but nothing happened. So then the following

year they got together again. And this time they came up with a thing we know as the other

agile manifesto. So agile manifesto, I think it's a fantastically enduring document. Okay,

if you stand back and squint, everything about this is true, 15, 16, 17 years later. And I suspect

we'll still be true in 10 years time. We are uncovering better ways of working is how it starts.

It doesn't say, hey, we've solved software. We've done it. See, we got this. It's no, we're uncovering

ways of working. It's an ongoing. It's a continuum. We value a bunch of things. We value processes

and tools. Those things are important. We value individuals and interactions more than that.

So the stuff on the right isn't rubbish. The stuff on the right is valuable. Otherwise it

wouldn't even have made it onto the sheet. But the stuff on the left is more important. That's what

they say. We like comprehensive documentation because that's how people are going to understand what's

happening later on. Famously with Amazon, whenever someone's going to start a new feature or new

product to Amazon, they start with, what do they start with? Meetings, functional specification,

BRD. They start with a press release. The first thing they do is they write the press release

as though the product already exists and is awesome. And so they write this amazing press release

and they go, right, shrug. Let's go build that. Because that's a really, really good way to focus.

Very good friend of mine. He's like my favorite programmer. He, whenever he starts anything,

he starts with the read me. He starts with the read me that he wants to read in order to build this thing.

And then the second thing they do is they write the FAQ. Imagine this is already out there and

is super popular. What would the questions be and how would we answer them? And I did this once.

I'd written a thing like a little hero who kind of rip off. So the internal cloud deployment thing.

And, and I was leaving the company and I was handing it over to my buddy and I started writing

the documentation for it. I thought because I don't have a dump it on him. And I wrote the read me

and I said, here's all the things you need to do to install this. And as I was writing it, it got

to about two or three pages long. And I was embarrassed, right. And so, and so I figured, right,

well, what could I clean up here to make the read me smaller? And so we ended up, so I iterated,

I only took like a few days. But eventually this read me, went all the way down, it said, right.

Install this thing, change that thing over there and just choose a port number. So the whole thing

you could configure with an IP address and a port number. And so I thought that was embarrassment,

driven refactoring. I couldn't look him in the eye and hand him this thing. I had to clean it up.

So, okay, so we've got this Agile Manifesto. And this changed a huge amount of stuff. Who's been

in technology for less than 15 years? Okay, probably half the over half year. So that means

this stuff's always existed. Your whole career, this is always existed. Who's been around

more than 15 years? All the tired arms go, oh me, I have, right? So you've seen this kind of

sea change during your career. So revelation. Revelation is, there's more going on. I'm now not

a person who turns functional specification into code. You know, testers are not someone who

turns deployed software and a testing environment into a bunch of test scripts and test script reports.

We need to think beyond developer. Okay, we need to think about things slightly differently. So I'll

tell you what I am now. I think of myself, I am a multi-dimensional creature. I'm a developer, sure,

but I'm a developer in a team. Okay, I'm not a developer on my own with my own little pile of

work. I'm an developer in a team. I'm building a product. So I've got to start thinking about what

it means to build a product. And I'm not, again, I'm not building that product in isolation. I'm

building that product on a platform. Okay, so that means I need to start thinking about the ecosystem

I'm working on in the organization. I mean, a department is not just my team. You know, this is

a little silo team based thing. There's probably a whole bunch of teams working towards a single

program. There may be a whole bunch of programs going on across the portfolio of work within a

department. And that department exists inside an organization. So there's a bunch of stuff going on here,

right? But I don't want to talk about me. I want to talk about you. Okay, because you are

all those things too. So what I want to do is unpack each of those things and have a think about

how that impacts what you are, who you are, your identity, things that are going to help make

you a more effective developer. Okay, so we'll be on this little silo program a thing.

So you're a developer. What does that mean? We're thinking about some stuff. Obviously, it means

you need to learn the language. Whatever language you're programming in, you need to learn that

language. And there's learning and there's learning. Right? There's I can know roughly how to get

by in C-Sharp. Right? I can figure out what to type. I can figure out that kind of thing.

That might help. But then for instance, C-Sharp and Java look very similar as languages. I'm

much much more proficient in Java. Because a language isn't just the syntax. It's the libraries.

So there are some core libraries in there. And it's not just knowing where they are. It's

knowing what they do, knowing what their performance characteristics are. Great example, Ruby has a

data structure called List. And I can make lists in Ruby and they're a list. Right? There's another

data structure called Set. In Java, I have a plethora of lists and sets, different types of those,

for any occasion. Why? Because the sorts of problems that Ruby solves, it usually doesn't

really matter what's going on under the hood. Right? By the time it does, you have to invent stuff,

like MemCash. Right? Because Ruby really wasn't designed to do the things that people try and

beat it to do. Yeah? Ruby has a great prototype in language. It's a great sketching language,

like Python. They're really good sketching languages. They're really expressive. But again,

they don't have an opinion about things like so in Java, I could have a regular array list,

which is a list back by an array. I could have a linked list, which is typically going to be slower

to do a bunch of things faster to do a bunch of other things, much easier to, for instance, resize.

In certain things in the middle of, muck around with. Whereas on a ray list, I've got all of the

behavioral characteristics of an array. With sets, I could have a regular hash set. So I've got a

bunch of buckets. I could have a linked hash set. I could have a concurrent hash set, which means

it's got certain safeguards, which means it's safe under concurrent modification, which probably

slows it down a bit, but means that it's safe in certain circumstances. As a Java program, I need to

think about those concerns, typically, and I need to choose the tool, the most appropriate tool for

the job. Or, if I'm most Java programmers, I go, oh, hash set. New hash set. Set, set, equals new hash set.

If you think about what's going on under the hood, what Martin's talking about earlier on,

these algorithms and data structures, the fact the language has them, you should know what's

going on in there. I had a conversation with Josh Block once many years ago. He was one of the

core early contributors to Java, so he wrote the Java 2 collections API. He did a whole bunch of

stuff early on. And he said in Java 1.0, if I think it was pre 1.0, the implementation of hash code

in Java-lang string was made a hash of the first seven characters in the string. Now the only

of a hash code is that it comes up with a number and they use that number to put it in a particular

bucket. And then what they realize is that most of the strings people were using in Java started with

H, T, T, P, colon slash, slash. And so your perfectly balanced hash set, your hash base list of

whatever, everything was ending up in the same bucket, right? Or, could. Now luckily they didn't publish

that implementation. What they published is it has a hash code and it has an equals. And this is

the relationship between hash code and equals. So they could slide in a whole, another implementation

of hash code for Java 1.1 and no one noticed. Yeah. And so be careful about the behavior

characteristics of what you're doing. So you need to learn the libraries. You need to know

what's there. My brief phrase into closure have been, which is a kind of list that runs on the

JVM, have been every time I do something in closure. I end up writing a bunch of code and I look

at the core libraries and some code goes away. And I look at the core libraries and more code goes away.

So I do this and then my code goes, did, did, did, did, did, did, did, did, and it's mostly being

in the core libraries. Because the people who design closure are much, much smarter than me.

Okay. And so really a good way to become proficient in closure is to really understand what those

core libraries can do for you. Because there's a huge amount of power to wait in that.

What else? It's not just about knowing your own stuff. It's about being aware of what else

is going on out there. So JVM folks, who's been looking at Kotlin? He's been saying,

that Kotlin and obviously Scarler and Closure and some of his other JVM languages. There's a huge

amount of stuff going on on the JVM. It's a very exciting place to be. If you're in the

dot net world, you're suddenly seeing like, you know, dot net core on Linux. SQL Server just came

out on Linux. Since it's as I never thought I'd hear myself say in my lifetime. So understanding

what's going on in your ecosystem, understanding what's going on elsewhere as well. So this is

all the part of what you need to do as your day job. And it's not just about programming. It's

not just about writing code, that intellectual masturbation we're talking about this morning. It's

not just about, you know, I'm going to write beautiful code. It's I need to get this stuff live,

right? So I need to know what the tool chain looks like for my language or for my technology stack.

If I don't understand the tool chain, it limits me. It limits me in my abilities.

And again, I don't exist in isolation. Okay. So a big part of you being a developer now in the

modern age, in the post Agile or in the Agile, I guess, whatever age, is there is a huge amount of

stuff out there. And engaging with the community doesn't mean copying some stuff I found on

Stack Overflow, right? And upvoting it when it works. Right? That's not engaging with the community,

you know, meetups, any kind of gathering where you can go and learn share knowledge, come into

conferences. Everyone here is at a conference. Epic, well done, fab. Right? So share your knowledge,

talk to people you haven't met before, right? I know you're saying this to Danes and that's like,

we don't even talk to that family. So what are you talking about? So, you know, try it, try it.

It's going like, you know, walk up to somebody you've never met before and say, hi, where do you work?

What do you do? What are you here for? What are you excited about learning? Okay? So that's what

you do as a developer. But again, you're not just you on your own. You're a developer in a team.

So what does that mean? That means you need to understand how work gets done. You need to

understand what is the system of work looked like in your team. Right? And how could you improve

that system of work? Understanding that we're not generic, fungible, exchangeable things.

Each of us has a skills profile. Each of us has capabilities. But also, each of us has interest.

Each of us has aspirations. Each of us has stuff that they get really excited about.

And also stuff that really, really bothers us. And if you get me doing something I'm excited about,

guess what, you'll get great work out of me. And if you get me doing something that sucks

for me, then I'm probably not going to be at my best. However hard I try. So understand in the roles

in a team. I think of this as two stages. The first stage is understanding what the different roles

are, what people think the expectations are. And the second part, which I'm much prefer is messing

around with them a bit. Right? And this idea of T-shaped people or M-shaped people or Pi-shaped people.

Or whatever. The idea that you can not just, you're not just known for the thing you do.

You know, if I take Martin Thompson is a Java performance specialist. That's a pretty, most people

say it's a pretty accurate description of Martin. He's not. He's a really bloody pro-grammer who

happens to be working in Java, and happens to get really excited about what happens close to the

metal. Right? That's him now. I don't think for the last jump on to time. There will be other

languages that won't make him redundant or historic. What it means is he'll go, oh, let me

try and take all of this stuff I know and apply it to a completely new context. What if this were

operating the safety critical machinery? How would that affect things? What if this were in a small

mobile device? What if this were in a pacemaker? I don't know. So understanding the roles in the

team and mucking around with those roles a bit. I'm sorry kids. You have to learn to share your

toys. Collaborating is really important. There's a bank, a well-known investment bank. I know

and they're American, but I know I'm in UK. And when you first join there, as a graduate,

they're kind of a graduate, accelerated whatever development program. They do two things. They

throw you together with a whole bunch of other graduates from all over the world and they tell

you there are there's two things that matter to make you successful at this bank. And they call it

impacts and influence. Impact is what you can do. Influence is what you can cause others to do around

you. So early in your career, most of what you'll do is impact. It's you being good at what you

do and getting better at what you do and growing in that way. Later on in your career, it's about

influence. So even if you're the best programmer in the world, there's only one of you. If you as a good

programmer can infect other people, infuse other people with those habits, with those capabilities,

you just became a 10x 20x 50x programmer. Yeah, that's how you scale. Can Beck famously said,

I'm not a great programmer. He said I'm a good programmer with great habits. What makes him a fantastic

programmer is he goes into organizations and teaches those great habits to other people. He is a

500x multiplier. So collaborating with others, being aware that you solve problems better when

there's more than one of you. Per programming isn't two people at a computer, at a sitting

in a computer, programming. It's two people programming. It's not one of you navigating and driving

and all these crappy metaphors. It's two human beings collaborating to solve a problem. They

happen to have a computer with them. But all of the magic happens by the fact that these two people

are collaborating and disagreeing. And I maybe I'm pairing with I know on something and she's

solved this a hundred times before and she says, I know the answer, this is the answer.

And I've solved this a hundred times before and I know this is the answer. So we start working and

this sort of happens. Let me go that way a bit and let me go that way a bit and then we end up

sort of here and we both go, whoa, that's so cool. Right? Because we would never have thought of

that either one of us on our own. Yeah. And all of the software in my career that I've been

really proud of, most of the software I've ever written that was any good, I didn't write.

I was one of a pair that wrote it but I cannot put my hand on my heart and say I wrote it because

I didn't. Okay. And not just people you like. Collaborating is about really reaching out,

really getting to grips with all of the people in the team. So you may be very much a technical

program. You'd like to be down in the weeds and the technology and all of that. And maybe the

idea of, you know, I happen to be building a trading system, I happen to be doing health care,

I happen to be doing finance. It doesn't really matter the domain because I'm really down here.

You still need to collaborate with people towards the business side, towards the commercial

side of the product you're building. That makes you a better programmer, that makes you a better

developer. So collaborating with all the others. And again, it's not just about you. So there's

six of you in the team. If each of you is looking out for yourself, each of you has one person

looking out for them. If each of you is looking after everyone else in the team, you now all have

five people looking out for you. It's just basic maths. Okay. So you attend to the team's health.

You sometimes you pause and there are other people, you know, go ahead of you. There was one team

I was working a bunch of years ago in a bank, most of my story is a bank, sorry. And there was a

particular manager who wanted to understand each individual team members contribution in terms of

story points. Okay. So we're going to measure everyone's story points and we're going to

call the weakest people in the team. And so there's a chat. I don't know if any of you guys have

come across him. His name is Tim McKinnon, fan nominal developer and wonderful wonderful coach

and all around lovely human being. So he's in the team and he's coaching in his team. And his

velocity was zero. Tim's velocity, Tim's personal velocity was zero points. And so the project

manager said, well, it's obvious, isn't it? That's the person we call and I said, no, no, no,

you don't get to do that. The reason Tim's velocity is zero is Tim never signs up for stories.

Because Tim knows he had much more effective pairing with everybody in the team. He has the minister

without portfolio within that team. Right. And so what he does is he accelerates the whole team.

He is that 10x developer by not committing to anything himself. He enables the whole team to go

fast. I said, if you take that guy out of the team, everyone on the team will slow down.

You will cripple that team. And it took a bit of fighting, but we got to hang on to it. Yeah.

So attending to team's health is a really, really important thing. There's a bit of a tail wagging

the dog thing that happens in, even in some quite forward-looking organizations where they get a

bunch of agile coaches, right? And the agile coaches coming into agile coaching. And what that

does, and particularly I see this in Scrummelock, because you have a Scrummaster and a Scrummaster

job is to remove obstacles. No, the team's job is to remove obstacles, because that's how you get

worked done. Right. But as soon as I have a person, I can absolve responsibility onto them.

It's probably the product owner. I've got a product owner, so I can absolve responsibility of

product thinking. I don't need to think that anymore. So originally these were coaching roles,

but we've lost sight of that, and now they become the systems kind of gone back in the other

direction, which is sad. So the team attends to the team's health. The team removes the team's

obstacles. Okay. See you in a team. You're building a product. What does that mean?

That means we need to start thinking about product. There's a parallel track going on about

kind of lean UX and product development, and all that kind of stuff. I hope you guys are taking

the opportunity to bounce between the two, because there's some gold in both tracks. It's really,

really, really fun. It's a really well set-up day today. Or it's a really badly set-up day,

because you want to be everywhere. Right. But I'm building a product. So that means I need to

understand why I'm here. I can't get excited about something unless I know why I'm here.

You know, we hear all the time about how do I motivate my team? Give them something meaning

full to do and they'll do the rest. Yeah. If they don't have a sense of meaning, if you don't

have a sense of purpose in your work, someone needs to pay you a lot of money to turn up.

If you do have a sense of purpose, I was talking to someone who you're on about games

that are the game industry. And an awful lot of particularly independent games development is just

done out of passion. I've got this game in my head and I have to get it out of my head. If I don't

get it out of my head, I'm going to explode. Right. How much you want to get paid? I don't care. Get

out of my way. Right. I need to build my game. Yeah. So you need to understand the business objective.

What's the point of what I'm doing? Because if I understand the point of what I'm doing,

I can start making trade-offs. I can start moving towards that goal. You study the domain.

If you're building health care software, find out how health care works. If you're building

banking software, find out how banking works and work with an enormous German bank at the

moment. And we're going through an exercise and it's wonderfully life affirming where people who

think their job is to move data from point A to point B. You suddenly, so actually your job isn't

to move data from point A to point B. Your job is to enable the flow of information so this guy can

pay his mortgage or so this lady can have money arriving her bank so that her family can eat. Right

and do stuff. Your job is to create the mechanisms by which money flows through Germany.

That's what you're building. You're building an entire system of finance for a country. And you

look at it and they are. And they suddenly go, whoa, A. They start taking it a bit more seriously,

which is always nice to see in a bank. I have things quite healthy. But you just see the motivation.

They energize. They're like, you know, I'm not turning this set of requirements into the

there. And they start to become much more empowered. And I'm a bit into who minds about this word

empowered. Because in power times that's something you do to someone. I'm going to empower you.

Right? It's as an asymmetry. No, you can empower yourself. You can decide you're going to go and

do stuff. You can decide you're going to think differently about things. That's how one can empower.

So we study the domain and by studying the domain, that means we can understand

we can solve problems in that domain. You can't study a domain unless you know about the

people, unless you interact with the people who care about that domain. So if I am, again,

building a finance system, I've got traders. I've probably got brokers. I might have some

compliance people and legal people, right? Some security people. How else might I have?

Well, I've got the tech operations people in the support team. Right? Those poor buggers who are

going to have to run my software. Yeah. We don't usually think of those. So we need to get to know

all the stakeholders. Mark McNeil, who's on my favorite UX people. He has this lovely phrase for

stakeholders. He's a stakeholders. A people whose lives you touch.

Right? Anyone whose lives you touch by doing work, they are stakeholders. So anyone who's

involved in the work you're doing. So those security people, the scary legal people, their lives are

touched by the work where you're doing work. Chaapaino was working in another bank and they were

building a new system and he said, I'm going to build security in. I'm going to build security in.

Rather than what we usually do, which is the security at the end where we have the rip holes in it,

and my send us away for three months, I'm going to build security and tell you go, so the security

office only says, hey, security officer, can you tell me what I need to do to build a secure application?

And the security officer said, sure, show me what you've got. And you haven't got anything.

I'm going to start it. Is it, no, you need to show me what you've got and I tell you what's wrong with

it. That's how security works. And you guys, no, I want to do it the other, I want you to tell me

because I'm good at software, but I'm rubbish at security. Will you explain to me how security works?

And he's like, he says, no one's ever asked me that before. So he said, well, okay, let's figure it

out together. What's the first thing I should know? And they started talking about like a tax

surface areas and threat analysis and threat modeling and risk and trade-offs. And all this

kind of, and so between them, they built up a collaboratively, a body of kind of your idiot

list for security 101 for securing an application. And so that was a side effect artifact of this

product. And so the next time they came along with that application, someone said, oh, what about?

And also, what it meant is that when they got to the security at the end, the review was a bit like

this. You know what that stuff we talked about? Yeah. Did you do it? Yeah. On your way.

Because they'd already been engaged. And so these people who are often gatekeepers,

policemen down the line, they become upstream, you know, it's a shifting left thing. They become

upstream collaborators. You know, they become consultants into your process. So getting to know the

stakeholders is a, there's a reinforcing virtue of cycle there. So you're learning about them,

they're learning about you, you're figuring out how you can solve problems together. It's

pretty exciting. And of course, you contribute to the product. I'm working for a retailer in the UK,

one of my clients. And everybody literally, everybody who works there, shops there.

Okay, partly because they get a really big employee discount. Yeah. But everyone who's writing code,

everyone who's testing systems, all the product team, the back office, all of the commercial

guys, every single person there, shops in their store. So when they say, well, what would our

customers want? Well, I can tell you because I am one. Yeah. And I'll go into their shop because I

like their shop as well. And I try using their mobile app. And it's not great. It's not great.

They're amazing brand of amazing products. Pretty good website. No, well, products kind of okay.

You know, but they know this because they use it. And so what's happened is the mobile product

in the last probably year has gone from OK to actually really pretty good. You know, and

because they didn't have meeting after meeting of business requirements, documents, and flow charts,

and blah, they said, what do we want to be better? Let's go make it better. What's the next

thing we want to be better? Let's get in front of some customers and let's see what they think.

So you can contribute back to the product. And we've, I'm asking you, this is a plea,

this is a call to action. Everyone here who's in a development role is to shake off that mental

shackle of we have requirements come at us. We are told what to do. In psychological terms,

it's called being at effect. You can either be at cause or be at effect. If you're at effect,

that means things happen to you. If you're at cause, that means you make things happen.

So we tend to be at effect when it comes to requirements, when it comes to what we do in a product.

Everyone here has a brain. Everyone here has empathy. I mean, apart from the sociopaths,

you guys are fine. Apart from the sociopaths, everyone here has empathy to different degrees.

And so you can contribute to the product. I've seen probably some of the highest performing

teams I've seen were in trading firm I was working out a few years ago, and you had developers

and traders sitting in amongst each other. And it was just as likely a really cool idea for

improving the trading stack would come from a developer as it would from the traders. And over time,

if at the traders, they knew their way around Excel anyway, but they started learning Python,

because it's a really easy language to learn and it meant they could just sketch for things. And once

I was sketching things, I could say, hey, I've had this idea. I know it's really crappy code,

because I'm a trader. But what do you think of this? And then one of the developers would go,

that's a really cool idea. I'm going to iterate on that and then turn it into a product and it

may learn a money. Right? So you get technical algorithmic ideas coming from traders. You get

business ideas coming from developers because they both care about learning the domain,

care learning the product, and they contribute to the product. So putting a product.

We're putting a product in a platform. In defense of web logic six,

which took a bit of a kicking this morning. So I was also, I too was using web logic six in

probably 2005-ish. But interestingly you see, and this really is the kind of figure to gain into

one more thing to talk about earlier, is yes, we understand principles and things like data structures

and whatever else. At the time we were wrestling with web logic six, there was web logic,

there was web sphere, there was Oracle had a product that no one even knew what it was,

and there were a bunch of these things, and all of them were equally massive, unwieldy,

complicated, heavyweight, and all very clicky configurations. So you had to click on a really

slow ugly UI that would crash a lot and do bad things. And what we noticed was

behind the scenes, web logic was a Java app, and we pretty much knew our way around Java apps,

and everything it did was XML. So what you could do is, and this is what we did,

whereas you could install web logic, and then just snapshot the directory, snapshot everything that

just changed on your file system, and you got a whole bunch of XML files, and then you go into

the config pages and start changing some values, and then see what's changed to like a recursive

diff, the whole thing under version control. And that started to tell us where in these XML files,

those values were being stored. It wasn't a great leap to then take those values and tokenize them,

and then have an automated build process that would drop the values in for us, and so we had this

idea of a template server. And so you could take a server, you could template it up, you could drop

the values in, and now you had build time configuration completely automated, and a whole bunch of

other patterns and techniques came out of that period, and a bunch of them were then collated

into a book written by Jez Humble and Dave Farley, because Jez was on the team with me, I heard Jez,

we were doing the build engineering side of web logic, and Dave Farley was heading up a bunch of

development teams that were chucking stuff into it, and I guess, again, in terms of necessity

being the mother of invention, all of these things turned into what we now call continuous delivery.

So we can thank Quad Logic for that, because if it had been easy to use, that might never have

happened. But even when you're using these tools, you can be at effect, all this tool is horrible,

it's, I hate it, okay, biz talk, I have no love for biz talk, right? There's nothing good

came out of biz talk, but you know, a lot of other tools and technologies, you're in there

and you're thinking, how can I make this easier for the next person to use, okay? So I need to

understand the technical landscape within my organization, right? And you to understand what the

APIs are, what other technical platforms there are. I need to understand my path to production,

we talked about this already. So it's not just enough to write code, I need to be able to deploy code.

I then need to think about runtime concerns, monitoring, telemetry, instrumentation,

alerting, even prediction, you know, once you get to a learning sufficient,

sophisticated, you can put a machine learning on there, and guess what you can start to

predict when bad things are going to happen, Netflix does this with their Amazon stack.

So I need to care about runtime concerns as a developer. This is something I do in teams,

as I put all of the developers, I rotate through the build role. For a period of time,

I find it makes them a safer driver, okay? I'm a huge fan of development teams carrying a

page, right? Because if someone's going to get page three in the morning, it might as well be you.

Oh, oh, now you're going to think twice about whether that's a warning message or an error message,

because a warning message you won't get page three in the morning.

No, okay? And usually it's someone else that gets page three, so we tend to care about that.

We value automation, okay? We care about automation, but not all the automation.

We can get obsessive with automation. Automation has a trade-off, it has opportunity cost,

automate things, automate repetitive tasks. My here is sick is automated when it gets boring.

Okay? Boring means you've done it enough times that you know how it works, and it's been similar

enough times that it's boring now. If it changes every time, don't automate it yet. Once it becomes

boring, that's a good time to automate it. And again, you contribute back to the platform. As

you're learning things, you're feeding that back to the other teams, the other custodians,

of the other platforms. And you end up with Dave Thomas calls these organizational APIs.

You end up being able to communicate between departments or between groups through their APIs,

because you've got a robust enough business process modeled through those APIs.

In a department, so what does this mean? This is that. Remember, I'm talking about impact versus

influence, this is the influence part. So you understand the wider context, okay? And you can make

trade-offs. I'm in a position now where even though locally for my team or my program,

this would be, this would get me forward. The right thing for the organization is to do something

a little bit more sensible. Organizations like Spotify have this, you know, this wonderful matrix

model of tribes and guilds and whatever. That mostly exists to try and get some consistency.

Okay? To try and create those communication channels, communities of practice, so that people

can find out what's going on. It's a very, very clever idea. It breaks under really,

really big scale, but there's other stuff you can do. Right? And then now you're showing

your knowledge across teams. So you're maybe having meetups internally, internal open source,

internal conferences. One of the things I love about the work I do, I'm an independent consultant,

I often get invited into companies, doing internal conferences, like really big companies,

often do internal conferences. And they've run like this, they're run very professionally,

but it's just for their internal employees. And it's great because that's a clear message that

we're investing in people. We're taking everyone out of their day jobs and moving them all

time, no, Berlin or Paris or somewhere cool for a couple of days and we're going to decount.

Right? All of those people are now not at work. Right? That's a really cool thing.

So sharing your knowledge across the teams. All your knowledge. So when I first started out

as a contractor, which would have been probably late 90s, I very quickly realised that there are

two ways to be a successful contractor, to be a successful independent. One is to hoard all the knowledge,

but if you hoard all the knowledge, you're unsackable. Okay? The other is to share all the knowledge.

Because if you share all the knowledge, people want you to be around. They like having you there.

And I also learned, and this was during my Thought Workstays, there was a really interesting

thing that happened, was this, you were going there and you had to solve a problem and you'd

make yourself redundant. And what happens when you make yourself redundant? Usually isn't,

go away. It's usually, that was pretty cool. Can you come and solve this other

nirally problem we've got over here? So you don't really make yourself redundant. You just

make yourself available again. And then you go off and do something else. So I realised fairly

early on, I was going to have to choose one or the other, and I went with all the knowledge.

So this is why I do this stuff. I love sharing knowledge. I'm a huge fan of sharing knowledge.

I encourage it in others. You contribute to the department. Okay? So this is now about care and

feeding of the organisation. You know, I've seen really, really high performing developers move

into people roles. So they've burned out as a developer. No, they realise that they could have a

much bigger multiplying effect by helping loads of other developers. A lot of programmers

I know who speak events and things. They could be a lot more productive if they weren't

speaking events. If they were sitting there typing stuff. But do you know what they are trying

to contribute to the wider, the wider group? So, and now this is about the influencing. So you're

influenced at across the organisation. So this is like building your communities of practice.

This is doing your learning lunches or that kind of stuff. Okay? And then finally, in an organisation

then, so an organisation wherever you work has values. That may be one of the reasons you joined

that company. Do you project those companies values? And as a nice little kind of rule of thumb,

in terms of are you proud of where you work? Would you proudly wear a t-shirt with your company's

logo on it? Okay? I know lots of people who would. I know several people who probably wouldn't.

Yeah? Or who would be completely indifferent because they're just sort of, you know, they work

somewhere. It's neither great nor whatever. But that organisation has values. Right? And so,

and so your values are either aligned with them or not. And if they're aligned with them,

you should be projecting those values. You should be walking down the street and someone says,

oh, that's a so-and-so person. They must work at that organisation because of the way they

conduct themselves. And so you care about the organisation's reputation. It matters to you. You take it

personally. Right? And so that means that you get out there, you get out into the world.

There's a lovely phrase, a destination employer making your company a destination employer.

It's kind of exciting. So that is somewhere that other people would want to come and work.

I have an idea that I'd like to do is a couple of my banking clients. I'm calling it the reverse

cockcroft maneuver. Okay? So Adrian Cockcroft was a conference not unlike this and he was

talking about Netflix and some of the cool stuff they do because he loves talking about Netflix and the

cool stuff they do. And someone on the front row they put their hand up and he's doing a Q&A

and they said, oh, but Mr. Cockcroft, you've got all these incredible engineers. You know,

I'm just a bank and he looks across the front row and he's looking at the company names on the

people's kind of land yet. And he said, I got them all from you. Right? And he said, I got them all

from you and then I got out of their way. Yeah? And because that's what he did. You know, these

people were really high performing engineers. They were really frustrated. Their organisation

didn't get quality, didn't get why you'd want to care about this stuff. And so they all went

off to somewhere cool like Google on Netflix or whatever. So I'm proposing the reverse cockcroft

maneuver, which is I want to make some banks. Some of the places I'm working so cool that we're

going to start hiring like Netflix and Google engineers because they're going to want to come

and have more fun. Right? Because they can do more meaningful stuff. Because again, this isn't

moving a bunch of money around. This is creating the infrastructure whereby you can pay your mortgage

or you can get your money moved around or you can send money to your family and

India or back to your family and wherever else. Because we've created the financial structures

that can do that. And well, I want to say too much because it's all ongoing at the moment,

but I'm hoping in about a year or so time when it has some really exciting stories for you.

So, but not all the knowledge. Because you have to be careful about IP and stuff. Yeah. So when

you are speaking externally about your organization, be aware that you're speaking about your

organization. So, and again, you contribute to the organization in those ways. So, so you're all

those things. Okay? You're a developer in a team building a product on a platform in a department

in an organization. You're beyond developer. I love this quote is saying, if you want to go fast

go alone. If you want to go far, go together. If you want to go far quickly, pack light.

That's what I think. But yeah, if you want to go far, go alone. If you want to go far, go together.