Zone out, check in, move on
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 170 | |
| Autor | ||
| Lizenz | CC-Namensnennung - keine kommerzielle Nutzung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben | |
| Identifikatoren | 10.5446/50617 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
NDC Oslo 201449 / 170
2
3
5
6
8
11
12
16
21
22
23
27
31
35
37
42
43
45
47
48
49
50
52
54
56
57
58
61
65
66
67
71
74
77
80
81
83
84
85
87
88
89
90
91
94
95
96
97
98
100
102
107
108
112
114
115
116
118
120
121
122
123
126
127
128
130
133
135
137
138
139
140
141
142
143
144
145
147
148
149
150
153
155
156
157
158
159
160
161
162
163
166
169
170
00:00
Güte der AnpassungProgrammierungEinfügungsdämpfungExtreme programmingTermAggregatzustandQuick-SortVirtuelle MaschineDatenflussRationale ZahlBitBenutzerfreundlichkeitSichtenkonzeptProzess <Informatik>NormalvektorTabelleMomentenproblemComputerspielDatensatzPlastikkarteMultiplikationsoperatorDatenfeldCodeMereologieDeskriptive StatistikKonditionszahlProgrammiergerätGebäude <Mathematik>NeuroinformatikOrdnung <Mathematik>Computeranimation
05:53
Interrupt <Informatik>PunktWiederherstellung <Informatik>ROM <Informatik>CodeInterrupt <Informatik>GeradeGraphStabilitätstheorie <Logik>PhasenumwandlungProdukt <Mathematik>QuellcodeWiederherstellung <Informatik>Sampler <Musikinstrument>MultiplikationsoperatorQuick-SortMAPBitVollständiger VerbandExpertensystemPhysikalischer EffektSoundverarbeitungQuaderProgrammierungStrategisches SpielZeitzoneAggregatzustandZahlenbereichMini-DiscEndliche ModelltheorieÄquivalenzklasseInterpretiererSoftwareNeuroinformatikSchnitt <Mathematik>ProgrammiergerätTermRechter WinkelZehnPunktZweiInteraktives FernsehenMailing-ListeZellularer AutomatWahlfreier ZugriffHalbleiterspeicherUnrundheitPhysikalisches SystemComputeranimation
11:46
CodeOrdnung <Mathematik>MereologieCodeMustererkennungEndliche ModelltheorieStrategisches SpielBildgebendes VerfahrenWebcamStrömungsrichtungDigitalisierungMultiplikationsoperatorComputerspielPufferüberlaufKeller <Informatik>SchlussregelStatistische HypotheseKonfiguration <Informatik>PhasenumwandlungWort <Informatik>Selbst organisierendes SystemOffice-PaketInterrupt <Informatik>Wiederherstellung <Informatik>SoftwareentwicklerProdukt <Mathematik>Lesen <Datenverarbeitung>TouchscreenBefehl <Informatik>ProgrammiergerätMomentenproblemVirtuelle MaschinePhysikalisches SystemParadoxonBitDeskriptive StatistikProgrammierungProzess <Informatik>PunktSoftwareKreisdiagrammProgrammierspracheMultiplikationFormale SpracheFigurierte ZahlNotebook-ComputerMinkowski-MetrikMinimumARM <Computerarchitektur>DreizehnGebäude <Mathematik>Web-DesignerWeb SiteFormation <Mathematik>HilfesystemComputeranimation
18:41
SystemprogrammierungDienst <Informatik>VersionsverwaltungUmsetzung <Informatik>NeuroinformatikQuick-SortTouchscreenTypentheoriePhysikalisches SystemBitInterrupt <Informatik>Mathematische LogikSchreiben <Datenverarbeitung>MultiplikationsoperatorFamilie <Mathematik>Office-PaketProgrammierungBildschirmfensterAnalytische FortsetzungHelmholtz-ZerlegungMereologieMultiplikationWiederherstellung <Informatik>KomponententestProgrammbibliothekComputerarchitekturVersionsverwaltungInstant MessagingEndliche ModelltheoriePunktNotebook-ComputerSpezielle unitäre GruppeCodePhasenumwandlungKugelSchlussregelNebenbedingungBildschirmmaskeQuaderVertauschungsrelationFormation <Mathematik>Dienst <Informatik>MomentenproblemCAN-BusRechter WinkelInklusion <Mathematik>BimodulProgram SlicingSystemaufrufProzess <Informatik>Klasse <Mathematik>RegelkreisSoftwareZusammenhängender GraphGeradeComputeranimation
25:36
Physikalisches SystemVersionsverwaltungKontextbezogenes SystemDesintegration <Mathematik>RechenschieberQuellcodeSoftwareentwicklerVerzweigendes ProgrammVariableAggregatzustandVersionsverwaltungOrdnung <Mathematik>ThumbnailHinterlegungsverfahren <Kryptologie>Konfiguration <Informatik>PunktMultiplikationsoperatorExpertensystemNatürliche ZahlSchlussregelMomentenproblemZahlenbereichCASE <Informatik>RegelkreisKontextbezogenes SystemDokumentenserverGraphische BenutzeroberflächeVirtuelle MaschineVerzeichnisdienstElektronische PublikationSoftwareGemeinsamer SpeicherCodeDatenverwaltungDatenparallelitätProgrammierungBitSicherungskopieMini-DiscSelbst organisierendes SystemProzess <Informatik>Gleitendes MittelQuick-SortInterpretiererSoundverarbeitungPhysikalisches SystemGeradeNichtlinearer OperatorZweiGüte der AnpassungBenutzerschnittstellenverwaltungssystemProjektive Ebenep-BlockEndliche ModelltheorieRichtungWort <Informatik>Physikalische TheorieReelle ZahlReverse EngineeringBasis <Mathematik>Rechter WinkelÄußere Algebra eines ModulsProdukt <Mathematik>Computeranimation
35:18
Desintegration <Mathematik>RückkopplungQuellcodeSoftwareentwicklerVersionsverwaltungBoolesche AlgebraArithmetischer AusdruckURLProdukt <Mathematik>Software EngineeringZweiMAPRegelkreisComputerspielSpieltheorieAuswahlaxiomReelle ZahlVollständigkeitKonfigurationsraumMultiplikationsoperatorFahne <Mathematik>Endliche ModelltheorieKategorie <Mathematik>DatenparallelitätQuick-SortTransaktionLeistung <Physik>DatenflussAggregatzustandFamilie <Mathematik>BitGenerator <Informatik>StellenringPunktSoftwareVerzweigendes ProgrammTypentheorieSchätzfunktionProjektive EbeneGeschwindigkeitElektronische PublikationRückkopplungPhysikalisches SystemEntwurfsmusterMomentenproblemPhysikalischer EffektVisualisierungInverser LimesGebäude <Mathematik>HilfesystemVirtuelle MaschineAbstimmung <Frequenz>Prozess <Informatik>EreignishorizontTotal <Mathematik>CASE <Informatik>VierzigFormale SpracheWiederherstellung <Informatik>HochdruckNummernsystemDigitalisierungDifferenteInterrupt <Informatik>Komplex <Algebra>Computeranimation
44:51
RückkopplungRechenwerkSoftwaretestCompilerSystemprogrammierungZeitzoneWeb logGamecontrollerSoftwaretestKomponententestGebäude <Mathematik>Quick-SortSoftwareCompilerSoftwareentwicklerCodeLaufzeitfehlerEndliche ModelltheorieTypentheorieBenutzeroberflächeDivergente ReiheRechenwerkVersionsverwaltungMultiplikationsoperatorZweiIntegralSchreiben <Datenverarbeitung>Verzweigendes ProgrammKontrollstrukturZehnRückkopplungQuellcodeSampler <Musikinstrument>Produkt <Mathematik>BitInterrupt <Informatik>DifferenteArithmetisches MittelDatenbankMini-DiscReelle ZahlPhysikalisches SystemVirtuelle MaschineProzess <Informatik>AutorisierungTouchscreenInjektivitätSelbst organisierendes SystemWeb ServicesGeradeUmwandlungsenthalpieArithmetischer AusdruckNP-hartes ProblemRechter WinkelAuswahlaxiomPOKEQuaderFormale SpracheOntologie <Wissensverarbeitung>Zellularer AutomatHalbleiterspeicherInternetworkingAggregatzustandHardwareEinsComputeranimation
54:23
Computeranimation
Transkript: Englisch(automatisch erzeugt)
00:04
Hello, everyone, and thank you all for coming. Kind of a bit of a surprise to me, but that's cool. So this talk is called, so now check in, move on. My name is Marc Seeman. My voice does not usually sound like this. I haven't been out partying very hard last night.
00:21
This is just a normal bug, okay? So I will give you the last thing, the last pieces of my voice, and then it's going to be all over until it heals at least. So anyways, I am going to assume that most of you are programmers. If you are not a programmer, you're welcome to be here, but I'll mostly talk to programmers, okay?
00:43
So if you're a programmer, I'm also going to assume that you know about this concept, this mental concept we call being in the zone. So being in the zone is something that some programmers call this mental state where you're just totally absolved in programming
01:01
and you just code and you code and you code and you code and suddenly you look up from your code and you realize that five hours has passed by, but you didn't really notice that. And you probably felt very productive while you were doing that, and maybe you were, quite likely you were, and it's a nice thing.
01:21
So being in the zone is a pretty nice thing. So I'm just going to ask you very quickly, raise your hands if you like being in the zone. Yeah, good. It's not a trick question or anything. I like being in the zone as well. You would be abnormal if you did not like being in the zone, so it's good for you that you actually raised your hands because it turns out that this thing we programmers call being in the zone
01:44
is not something that is very specific for programming. This is just a general mental state that lots of people have known about. So psychologists have known about this for a long time. They don't call it being in the zone, they call it the flow. So this is the psychological term for being in the zone. Flow, and lots of people experience flow.
02:01
So, for example, if you do any sort of computer gaming, you probably also recognize this sort of mental state where time just passes by. But it's not a new thing. It's not particularly related to computers either. So we've known about this for centuries. People have been known to play cards or other sorts of gambling where they just go on all night or maybe even nights in a row
02:23
because they can't really stop gambling at all. And it's not really related to just sitting down and sitting at a table. It can involve some sort of very physical activity, so you can have all sorts of extreme sports, which also provides flow.
02:40
Personally, I'm not a skier at all, but I could imagine that when you are skiing down a mountain, you will be absorbed in what you're doing, and you're probably going, Well, was that the mountain? I'll need to go again. So you're completely absorbed in this activity, and you tend to forget that time is passing. So another example might be scuba diving,
03:01
although I think this thing about forgetting that time is passing is probably not so good if you're scuba diving. Well, anyway, musicians experience this as well, so it's very broad. We know that musicians that improvise tend to experience this more than people who play off the sheet,
03:20
so this is something that jazz musicians and rock musicians and blues musicians may experience more than classical musicians. And they call it something else. Depending on the genre, they call it jamming or being in the groove or whatever. And then we programmers experience this mental state as well. And almost by definition, experiencing flow is pleasant.
03:43
This is part of the description. So when a psychologist describes what does flow entail, they say it's a pleasant activity where you're very focused on what you're doing. And I think it's kind of ironic that one of the most pleasant things that we can do in our lives is something where we don't really notice that it's happening.
04:03
So that's just the human condition there. But there are some downsides to flow as well, and one of them is that it can actually be addictive. So that's one problem. Another problem is that we also tend to build tolerance against this. And I guess we need to have more and more of the same thing that we do
04:24
in order to get into that mental state of flow. And I guess if you look at tolerance and addiction, I think you have an explanation for why some people jump out of helicopters with ski on their feet and they ski down the slope of Mount Everest, even though it is very, very dangerous to do, because they have reached a state where that's the only way
04:42
that they can actually get back that rush. Hopefully most of us are not going to be that addicted. So that's the zone, or just in more general terms, that's flow. And I will be relating this to programming for the most of the next hour. So let's just recap.
05:01
We have something that is pleasant. We have something that is very addictive, or it can be very addictive, and you build up tolerance for that. Does this remind you of anything at all? Well, you know, this is Norway, so you don't know about these things, right? I'm just kidding, I'm just kidding. This reminds you, depending on your tastes, this might remind you of alcohol or tobacco, maybe even mariana.
05:24
Yeah, it gets worse. Crack, cocaine, heroin, all of those things. So being in the zone is a bit like being a drug addict. Maybe there's something that we need to be aware of there.
05:41
So that's actually what I'm going to talk about. And particularly this thing about addiction is actually what I'm going to talk about a little bit. I'm not so much talking about physical addiction, but we tend to have a process or a mental addiction to being in the zone. I'll get back to this in a moment. There's actually one drug that's not addictive, that's not physiological addictive.
06:01
There may be more, but I know of one. It's LSD. LSD is, strangely enough, it's not addictive. It's also not physiologically dangerous. There's never been a known cause of someone dying from an overdose of LSD. So there's lots of other problems with LSD,
06:20
like you can get a permanent mental damage out of doing that. That's a bit problematic. But still, we should be like LSD users, in the sense that we should try to learn if we can cut that addiction to the zone.
06:40
The zone is a very nice place to be, but if you're addicted to the zone, if you can only be productive if you're in the zone, then you'll have a problem. And I'll talk about that problem in a little while. Before I do that, I want to talk about tolerance in terms of computer programming. I don't know what your first computer program was, but let's just assume that it was Hello World.
07:01
The first time you write Hello World and you make it compile and it actually runs on your system, that's like a revelation to you. At that point, realize that you have switched from being a consumer of whatever was already in the computer to being a creator, someone who can actually create new stuff,
07:21
new software that can run on the computer. That is a revelation. That is a fantastic experience to understand that. And the next time you write Hello World, that feeling is gone, because now writing Hello World is old news. You already know how to do that, so it doesn't trigger going into the zone anymore because it's just trivial, you know how to do that.
07:42
So you have to give yourself a little bit of a higher dose to get back that rush, and you discover that you can parameterize this thing, and that's fun again. But that also becomes old news pretty fast, and then you need to have a new dose, and you realize that you can do it a hundred times, and that is also great. So as you can probably tell,
08:00
it becomes more and more difficult to get into the zone as you learn how to deal with particular problems. So it takes a little bit of time. The zone is not something you can just switch on instantly. It takes a little bit of time to actually get into it. So that can sometimes be a problem,
08:22
but I think lots of us don't really realize that this is a problem, that we require increasing dosages to get into the zone, to get into this mental state where everything is fun. You know, where computer programming is fun to do. So instead we invent all sorts of other excuses for why we are not being productive.
08:40
And the number one excuse that we tend to invent for ourselves is interruptions. We hate being interrupted. I hate being interrupted, so I mean, I think it's a very common thing. So you've probably seen this thing already. This is obviously humorously meant, geek productivity at work, how non-geeks think it would work
09:01
versus how it actually works. And what I want to do here is I want to zoom in on this little box in the right-hand corner and have a look at this effect of a five-minute interruption. So what non-geeks think, or what non-programmers think, is that we have a productivity that's kind of graphed with that dotted red line.
09:21
So they expect us to work on a stable level of productivity, and obviously when they come and interrupt us or they want us to be in a meeting, they don't expect us to be productive while we are in the meeting. Well, some of them might actually even do that. But they don't expect us to be programming when we are doing something for them.
09:40
But then when the interruption is over, they pretty much expect us to go back to what we were doing and just keep on at the same level of productivity that we had before we were interrupted. And as this graph implies, this is a recovery phase where it actually takes some time to get back on track and get back onto that level of productivity.
10:01
And this graph seems to imply that it may actually take 15, 20 minutes, which actually resonates pretty well with me. That sounds reasonable. And obviously, if you're interrupted during that recovery phase, you have to start all over. So I'm going to talk about the recovery phase a lot
10:20
in the next four to five minutes. So when I talk about the recovery phase, that's the thing that I'm talking about here. So I'm not an expert on how the pain works, but I think there is an explanation for this that at least four programmers sort of make intuitively sense to us. Because what I think happens here is that when we write software,
10:44
what we actually do is we kind of duplicate a little bit of the work that our compilers or interpreters tend to do for us. What we actually do is we read source code and we interpret what we think that source code is going to do, and we build up in our brains a mental model of how we think that piece of source code actually works.
11:03
And it takes a little bit of time. An equivalent is it's almost like taking bytes and reading them from disk and loading them into RAM, and you know that takes a little bit of time. But this is not something that measures in seconds or minutes. This is something that's measured in tens of minutes.
11:23
It takes time to build up that mental model. So you need to have various strategies for how can you deal with these sorts of interruptions, how can you make a recovery phase shorter. All right, so that's pretty much what I'm going to talk about. And I'm going to talk about three strategies for doing this.
11:41
So I'm also going to talk a little bit about three strategies for avoiding interruptions, but mainly I'm going to talk about three strategies for how do we actually shorten this recovery phase. But we hate interruptions, so what do we do, what do we all do? We wear headphones, right? So actually, this is so common that there's actually something called the headphone rules,
12:03
and the headphone rules even have a website. And if you go to that website, you will see the headphone rules goes like this. So if I'm wearing no headphones, you can come and talk to me. And if I'm wearing one headphone, you can talk to me if I like, and if I wear two headphones, you can't talk to me. So I don't exactly know how you wear two headphones,
12:21
but I just copied this from the website. The wording is a little bit strange. But basically, we programmers, we dislike being interrupted. So which option are we always going for? We are always going for the, you know, do not talk to me, do not interrupt me. That's the option we always go for, because we believe then that that will actually enable us to be in the zone if we're not interrupted.
12:45
So that sounds reasonable. Now, imagine a world where everyone knows about the headphone rules, and all your colleagues, including all your non-programmer colleagues, actually respects this rule.
13:01
This is a very hypothetical situation, but just, you know, go with me for a moment here. So what would a non-programmer colleague do who knows about this rule and wants to talk to you? So they'll start off, they'll come out of their own office or whatever, and they go to your space, and they will look at you, and they will notice that you have your headphones on, and they will kind of like, okay, go back.
13:23
I'll try again. I'll try again. So they'll have to, you know, maybe they can install a webcam to monitor you so they can actually capture you when you go to the bathroom. So maybe there's an industry in that, because then you can have, you know,
13:40
digital image recognition that actually recognizes whether people have headphones on or not. Well, obviously that, you know, that's never going to fly, because that's a waste of everyone else's time, so they'll just go and interrupt you in a way. So this strategy does not work. Well, there are other good reasons for wearing headphones. I like, you know, listening to music, so that's one good reason. But it doesn't protect you from interruptions at all.
14:03
So you need something else to shorten that, you know, the cost of having that interruption, because the interruption is an inevitable way or inevitable part of your life. So here's a paradox. As you gain more experience as a software developer, you become less productive because of interruptions.
14:22
So why is that? So the reason is that when you start out as a junior developer, no one really knows what you know. You probably know something already, but no one really knows about it. So you're probably given an assignment and, you know,
14:40
you're given that assignment. Great. As time goes by, your co-workers will learn that you actually know something, and they will learn what you know. And the more they learn about that, the more they will come to you, because they will learn you actually have answers for their questions.
15:01
And this just keeps on going. And if you ever dreamt of being a lead developer, how many people here are lead developers? How's that working out for you? Well, maybe it's working out for you. Maybe you already have all of this figured out. But the problem with being a lead developer, when you reach this point of being a lead developer, your job is to be interrupted.
15:22
That is basically your job description. You have to know everything, and you need to be available for everyone else and keep everything moving. But still, you also need to know what it actually means to program and how you progress your code base. So you can't just totally let go of that.
15:42
So you need a way to deal with that. You need a way to deal with those interruptions. All right. So what about multiple monitors? How many of you here use multiple monitors? Yeah. You all drank the Kool-Aid. So there's this thing, there's this meme going around that multiple monitors make developers more productive,
16:03
which is kind of an amazing statement given that we have no idea whatsoever how we measure programmer productivity. So I'm not saying that it will make you less productive. We don't know. You probably like having multiple monitors because you like gadgets, I guess.
16:21
But we don't know if that's actually helping. Now, what we can try to do is something else, though. We spend more time reading code than actually writing code. And I think that's just a fundamental aspect of being a software developer. We have to relate to the code that we wrote yesterday
16:42
or six months ago. We need to relate to all the code that our colleagues wrote. We need to read new code in order to understand how to do something that we never tried before. We need to go on Stack Overflow to research how do we deal with the problems that we're encountering on day-to-day. So we spend lots of time actually reading code.
17:02
That's just a fundamental thing of writing code. There's nothing wrong with that. But I think this pie chart is lying because it seems to indicate that that ratio is maybe 1 to 2. It's more like this. It's maybe 10 to 1 or 20 to 1. And some organizations spend so much time actually reading code that they never really produce anything at all.
17:23
So that's a problem. And to bring it back to this whole idea about the recovery phase and building up a mental model in your brain of what your code looks like, if you have lots of code that you need to read in order to understand what your current code base does, it doesn't leave you a lot of time to actually write new code because you have to spend so much time actually reading the code
17:43
and building up that mental model in your brain that you don't really have much time writing code. So what can we do? Well, write less code. So, yeah, this sounds a little bit snarky, but I'll try to make it a little bit more real, though. So I'm not trying to sell you a new programming language.
18:01
That's not really on my agenda. And I'm also not telling you that you just, you know, you can't really go to your employer and say, you know, we were talking about making 10 features for this product, but I just went to this talk by Mark, and he says I can only do two, so I'll only do two. That's not going to work. You need to figure out a way to make all of those 10 features
18:23
while writing less code, or at least writing less code that you have to read all the time. So how about using a small screen? So this is actually a screen shot of my development system. It's actually on this machine. This is a 13-inch monitor.
18:41
That's where I write all my code at the moment. I've been writing on laptops of various sizes since 1999, and occasionally I try out this multiple monitor big screen thing, but it doesn't work for me. So the thing here is, as you can tell, by the way, in this setup I have my unit test on the right-hand side, and I have the actual code on the left-hand side.
19:01
That's not really important. But what this does is it motivates me to decompose things into very small parts. It motivates me very, very strongly to decompose things into small parts that I can reason about, and what I look at on the screen is all I need to know. So this might seem extreme,
19:24
but I think it's actually important, and at least it's working for me. And I think the reason why it's working for me is that when we write code, as Martin Fowler says, or I'm going to paraphrase Fowler a little bit. He says, you know, any fool can write code that a computer can understand.
19:41
The art is to write code that other humans can understand. So obviously there's a bit of logical thinking in writing software, but there's also a lot of creative thinking in writing software. So it's very much a creative endeavor. And if we think about other types of creative endeavors, there's lots of examples of artists artificially introducing constraints on themselves.
20:07
So one of my favorite examples is this Japanese poetry form called haiku. You probably heard about that. It has very strict rules on how can you write a particular haiku poem. And despite of those very strict rules,
20:22
great art has been produced in the sphere of haiku poetry. And we have examples of this in poetry, in literature, in music, in motion picture making, you know, lots of examples of this. You know, putting an artificial constraint on yourself sparks your creative genius.
20:45
It actually makes you think, you know, out of the box because you're actually being put in the box. That's kind of interesting. So, well, this works for me anyway, and it's worked for me, you know, like for 15 years now. So that's just an idea. But even if you don't like this, if you love your big screens,
21:02
some of you probably do, at least try to do this. Don't try to build an entire system at a time because that is, when you do that, that is when you have to load a lot of stuff into your own brain before you can start actually reasoning about what your system does. Instead, you know, build parts.
21:22
And I don't care what you call the parts. You can call them, you know, components. You can call them classes. You can call them modules. You can call them slices. Or you can call them microservices. That's the thing this month. This is very popular this month. I don't really care. The point is decompose things into small parts,
21:42
parts that are so small that you can actually reason about them in a finite time, if you will. So we've known this for decades already. So the only thing I'm really saying to you here is that there is, apart from all the other reasons for decomposing, there is this other reason, and that is it enables you to shorten that recovery time
22:02
because if you have less code that you need to interpret, if that mental model that you need to build in your brain is smaller, you can load it into your brain after an interruption quicker, and that will give you a better chance to get back in the zone. So this is actually, what it really does is, it gives you a better chance of enjoying writing code.
22:23
It makes stuff more enjoyable. And I didn't really understand that before I started to think in this way. So I was really wondering about, why is it that I like loosely coupled small library code so much better than big systems? And it's because big systems pull me out of the zone all the time.
22:40
Small systems actually enable me to be in the zone. And then just take all of that stuff and throw it together, and deliberately I'm not trying to sell you a particular style of architecture here. So just throw whatever you have together in a way that makes sense, and then compose your applications out of those small things.
23:02
All right, so that's one thing you can do to actually shorten that recovery phase after an interruption, which gives you a better chance of getting back into the zone and actually enjoying yourself a little bit again. So, but still, I mean, it would be much better if you just weren't interrupted all the time.
23:20
So what else can you do to avoid interruptions? How about working from home? I realize not everyone can do this, but if you could, would that work? So this picture really looks nice. It looks like it's nice weather outside. It has the sun coming in through the window but not on your screen, and everything is in straight lines,
23:41
and there's no clutter, and you have your favorite chair. This just looks like a setup for eight hours of continued programming bliss, right? So unfortunately it turns out the reality is more like this. And I am not too proud to tell you, but this is actually a picture of my home office.
24:00
Not all the mess is mine, but most of it is. Yeah. All right. So reality is something else. If you have any sort of family, your family will tend to interrupt you all the time. And then even if you have family but that family is away because they're at school or at work or whatever,
24:21
it still tends to not really work because I sometimes have this sort of conversation with my wife. So she goes like, so you're going to work from home today? Yes, I'm going to work from home today. All right. Okay. So while you're at home, could you just paint the kitchen, please? I was planning on working.
24:42
It's just like you're at home, so you're just available for all sort of traffic. It's just like being in the office. So that doesn't really work. And even if you don't have a family, you will still need to relate to your other team members, and they will call you on the phone or on instant messaging or whatever. So that doesn't really protect you.
25:01
It doesn't really protect you from being interrupted. So you need some other sort of thing that will make you more productive. So working from home is wonderful for lots of other reasons, particularly because you don't have to deal with other people that much, at least. No, I'm just kidding you. But at least you save the commute. Something else, something entirely else actually works.
25:22
And this is very strange. Use a distributed version control system. And when I'm talking about distributed version control system, at the moment, there are really only two. There's something called Git. You've probably heard about this. No. That switched a little bit too fast. Oh, no. What is it doing?
25:43
I'll just restart from that slide. Let's see if that's going to help. All right. So Git and Mercurial are basically the two options that you have with distributed version control systems today. And I'm just going to talk about Git, because that's the one that I actually prefer. But Mercurial is also a pretty decent alternative.
26:03
So I'm just going to talk about Git. You can pretty much, every time I say Git today, you can just replace with Mercurial. And what I'm going to talk about is pretty much also going to apply to Mercurial. So this is strange, because we are not used to thinking about version control systems as something that will actually make us more productive.
26:21
And so I think we have a long history as software development organizations where we are used to thinking about source control systems as almost like an add-on or an appendix to whatever software development process that you have. You write your code, and you figure out whether it actually works and so on, and then you do code reviews. And when you're all done with your process,
26:41
well, you take whatever you have, and then you save it into your version control system. And the only really reason you do that is because you have corporate policy that says you have to do that, because then you have a backup of your source code, which is a good thing to have. So this has typically been the realm of managers who don't really need to work with these things on a daily basis,
27:04
because that's what it was like. But the funny thing is, if you start using a distributed version control system, this just totally changes everything. So if you don't do this already, get with the program. This will make you much more productive.
27:21
So that is difficult to understand if you haven't tried it. So obviously I can't make you try it, but I'll try to explain why this actually makes you so much more productive. So one of the things that happens is it enables you to switch context painlessly. So by switching context, if you want to look at what's the state of your code
27:43
in a particular branch, for example, you just go check out feature 42, assuming that you have a branch which has the name feature 42. And this is just something that happens on your local machine. There's no network involved at all. It's just going to update your working directory with the files as they look in that version control system at that time.
28:03
And it's basically when you hit enter, it's done. It's very fast. It takes less than a second to switch context in this way. And by the way, if you don't like the command line things, there are GUI tools for Git material as well. So that's not really a problem. So this enables you to look at all your source code
28:22
as it looks like in feature 42. And if you want to switch back to master, you just go git checkout master, another sub-second operation, and then you're back. So when you try this a couple of times, or 20 times or 100 times, you start thinking this just becomes second nature. You just switch things around. If you want to look at something else, bang, go and do that.
28:44
So you can do wonderful things by being able to switch context almost without, you know, without paying. So one of the things you can do is you can work in branches. And there will probably be some of you who have heard source control experts tell you that branching is probably some of the most evil things that you can ever do.
29:05
Those experts haven't really understood what causes the problem. They're thinking about a very specific problem. They're thinking about this problem calling merge conflicts. And merge conflicts can be hell. But it turns out that merge conflicts are not triggered by branching.
29:21
It's triggered by something else. I'll get back to this in a moment. But just for now, just accept, and I'll get back to why that is, but just try to imagine, and it's got to be true, that branching is not evil. Branching is actually very, very beneficial. So if you work in branches, what you can do, first of all, you know, creating a new branch at Git or material,
29:41
something like that, you know, check out dash B, and that creates a new branch called feature 43. Again, no network involved. This just happens in your local machine. It's done when you hit enter, more or less. Obviously it's not really done before you hit enter, but after, yeah. Okay, so that enables you to create a new branch. So what you can do, it enables you to explore fearlessly.
30:03
So one of the things that I think, when we build up that mental model, that interpretation of what we think our source code actually will do when we run it, is that we often build up a too high fidelity picture of the source code because we're afraid to make mistakes.
30:20
And one of the things using a dispersion control system does is it reduces the cost of making mistakes. So it enables you to try things out, and the cost of making a mistake while you're trying things out is just, you know, almost negligible. It's not very high. I'm not a native English speaker. So one thing you can do is, imagine you want to build a new feature.
30:42
You start out by taking some sort of snapshot of what master looks like at the moment, and then you start, you know, creating your new branch, and you put some commits into this branch. So this is important, and I'll get back to this in a moment as well. You have to make many small commits. So what you can do is you can just, you know, try things out, and maybe what will happen is that after that sixth commit that you see here,
31:04
you realize, or maybe I realize, I should talk about me being stupid, but this happens to me all the time. So I realize that I did something wrong. You know, I thought I had a good idea, and I tried it out, but it turned out it was a horrible idea. It doesn't work in practice. It sounded good into the theory, but it didn't turn out that it worked very well in practice.
31:24
But on the other hand, it actually, you know, my start of this work was actually pretty good. It's just the last three commits where I, you know, had a horrible idea. So what I can do is I can just, you know, just throw away the last three commits that I made, you know, roll it back, and then try out a different direction, and then, you know, I'll try out something else, and that turns out to be a good idea.
31:44
And you can do that as many times as you want. And when you finally, when you think now this is actually pretty great, you merge it back into master. Now again, all this happens on your local machine. No one else sees this. You know, and when you're done with this, you can push it to your shared repository
32:02
and share it with everyone else. And what it looked like, you are, it looked like you're perfect. It might look like you're a little bit slow because there will be, you know, times between check-ins where nothing is happening for hours because that's where, you know, deleted everything again. But it looked like you'd make no mistakes.
32:20
And it's not particularly the case that I'm not vain in the sense that I'm afraid to publish my mistakes. I have a blog, so I do that all the time. But it's just, it keeps your source control history clean and also keeps the number of commits down, which in a moment you will realize is very important.
32:42
And so all of this you can do on your local machine, and then when you're ready and it's nice and done and you're satisfied with it, you share it with the rest of the world. So the cost of making those mistakes is really, really low. All right, so one of the rules that you have to follow, a rule of thumb in order for this to work,
33:01
is never be more than about five minutes from a check-in. Give and take. So, you have to work in such a way that you don't make, you know, big, brutal mistakes. You know, work in small increments. So that might be as small as, you know, change the name of a variable. And if you do that and you leave the code
33:22
in at least as good a state as it was before, why not check it in? You know, checking in on a distributed version control system is not a big thing. It's just, you know, one command line thing, and then bang, you're done, and you can move on. It doesn't take more than a second or two. Sometimes I have commits, you know,
33:40
where I have several commits within a single minute. Sometimes I, you know, go 10, 15 minutes without a commit because I'm thinking. But you can have very, very small, fine-grained commits if you want to do that. And that's very important because the more fine, small-grained, the more small-grained commits you have, the better you have an option of rolling back
34:00
onto the exact point where you decided that, well, here is where I made a mistake, but all that, you know, happened before this actually was a good idea. And it even also enables you sometimes to say, well, I have, you know, commit number one, two, and three, and five, which were good, but I don't want to have the fourth one because I made a mistake there, so you can actually take this one out.
34:21
That's a little bit advanced Git trickery, but this is possible to do. And no one else sees that, so, you know, no one is any wiser for that. All right. So, and if you can't do that in five minutes, sometimes you can't do that. There's this thing called git stash. It will just, you know, create a temporary commit on disk and, you know, clean up your working directory, and you can get that one back later on.
34:42
So that's always this safety thing you can use to get out of a tight spot, if you will. All right. So let's get back to this whole thing about merging, and while, you know, so branching, I claimed, branching is not evil, but merging is. So let's try to understand what a merge conflict is.
35:04
A merge conflict is a concurrency conflict. That's all it is. It's an effect of the fact that you're working concurrently on the same piece of source code. You know, if you weren't working concurrently on the same file, you would not have merge conflicts.
35:20
Okay, so it's a concurrency conflict, and it's specifically, it's a concurrency conflict related to optimistic concurrency schemes, which is what we use nowadays. I mean, when we had first generation version control systems it was like, has anyone ever used visual sourcing? Yeah, so you probably remember, you actually had to check out a file
35:41
before you could edit it, and this is called pessimistic concurrency, and it actually has this one benefit that it doesn't cause merge conflicts because you can't edit things before you check it out, and only one person can check it out at a time. So, but then people, you know, someone decided
36:02
that, you know, creating second generation version control system and now third generation version control systems that uses optimistic concurrency. So that's the model. So we know about optimistic concurrency models from all other pieces of software engineering. What is the normal way to reduce the risk
36:21
of a concurrency conflict in every other sort of system? Make sure the transaction happens as fast as possible and get the hell out of there. That's how you minimize the risk of having a concurrency conflict. It doesn't guarantee that you will never have a concurrency conflict, but it minimizes the risk of having a concurrency conflict. So it's exactly the same when you work in a team.
36:42
It has nothing to do with branching at all. It just has to do with the fact that you are multiple people working on the same source code. But the more often you integrate, you know, the shorter you make your transactions, the more you reduce the risk of having a merge conflict. So integrate often.
37:01
How often is often? That depends, you know, everything depends. That depends on the size of your team, the velocity of the team, you know, how quickly you actually edit files. But in most of the projects that I've worked with, I begin to feel uncomfortable if I've had a branch out for more than a couple of hours. So when a branch begins to become, you know,
37:22
a couple of hours old, I really want to merge it at that point. So that's what works for me anyway. All right, so, yeah, and, you know, integrating is just like this. Again, just a couple of commands on your local machine, and that's it.
37:40
All right, so distributed version control system does not solve the merge problem in itself. You know, if you have a merge conflict, it's just as painful as any other version control system. But integrating often will help reducing the risk. All right, so let's have a look at a problem that always occurs. So let's assume that you are building a feature,
38:00
and we could call that new feature, feature 42. And you start building that feature, and you do everything that I told you to do, you know, small commits and so on, and a couple of hours goes by, and then you're kind of like, this is not nearly done. I mean, this was a feature that we estimated would take two weeks, three days,
38:21
six hours and 27 seconds. Well, now you have an estimation problem. But anyway, some features are not just, you can't really complete them in, you know, just a couple of hours. So what do you do? And most people will kind of go like, I'll just leave this branch dangling until I'm done, because I don't really like to do that.
38:42
In most cases, the best answer to this problem is integrate it anyway. Why is that? Because, again, depending on what type of software you're building, the cost of having merge conflicts is bigger than the cost of having incomplete features
39:01
in your master. And then you probably go, I don't like to have incomplete features in my master, because I might actually ship this to, you know, customers, or I might put this in production. I don't want to have incomplete features in production. But the thing is, we don't really know how to minimize the cost of having merge conflicts,
39:21
but we know how to minimize the cost of doing this. And the way we do that is by something called a feature toggle. And a feature toggle, you can imagine, is basically a little configuration file. You can think about it like this. So imagine that you have a configuration file like this. So you say, well, feature 40 and feature 41 are enabled, because those features are done. Then feature 42 is enabled on my machine,
39:40
because I'm working on that feature at the moment. But when I check in my source code, and when we have things running in production, that value will actually be disabled. And then we have feature 43, which one of my colleagues is working on, and she will have it enabled, but I have it disabled. Something like that. So it wouldn't be very 2014 of me
40:01
if I was actually recommending that you do everything in XML. So that was just to give you an idea about this is something that you could make configurable. But you might as well just do it in, you know, a real, true and complete general purpose language, if you want to do that. Your choice. But if you do it in a real general purpose language, what you could do is, you could just set a lot of Boolean flags. But by doing that, you can create any Boolean expression,
40:23
however complicated that you want to make. So you could do something like this. So imagine your system works with requests and URLs. You could say, well, if the request URL is local host, that feature is going to be enabled, because that will effectively make it enabled for any developer, but when you put it in production, production is probably not going to run in local host.
40:41
And you could do a completely different, complex Boolean expression for feature 43 if you wanted to do that. It's up to you. But feature toggle is a design pattern described by Martin Fowler, again, which is specifically intended to deal with this thing, where you have, you know, incomplete features in your master branch,
41:02
because we want to deal with this thing. We want to integrate as often as possible. Okay. So that's pretty much it for distributed version control systems. You have to try it out, but it turns out that, you know, instead of just being an afterthought, you know, version control being an afterthought
41:22
to your overall development process, it just becomes a very, very integral way of working with your source code and interacting with your source code. And it just takes your game to a completely different level. So that's actually much more profound than it sounds, but that is something to do.
41:41
Well, okay, so if you don't buy this, how about avoiding interruptions? That still sounds like... I mean, I'm trying to minimize the cost of interruptions, but wouldn't it just be better if we could avoid interruptions? So what else can we do? How about never bathing? Yeah, so if you do that, you'll probably, you know, end up stinking like a pig, and no one will want to come anywhere near you.
42:04
If you keep this up, you'll probably also not have a family that can, you know, interrupt you. So you'll probably also not have a job. So that doesn't really work out. So the third thing I want to talk about is the last thing that kind of relates
42:20
to the distributed version control system thing. So when I talked about distributed version control system, I said, well, what we're trying to do here is we're trying to minimize the cost of making mistakes. And how do we know that we are making a mistake? And that's what feedback is all about. So again, if we just try to, you know,
42:42
think a little bit about this mental state that psychologists call flow, one of the definitions of flow, or one of the ways that psychologists describe flow is that you have to be constantly interacting with whatever activity you're engaged in, and you have to get feedback from that activity. And you probably, if you think about
43:01
what I just showed you about computer gaming and, you know, about, you know, downhill skiing or whatever, you're always getting some sort of feedback on whether what you're doing is right or wrong. If you're about to fall over on your skis or whatever, and you can kind of adjust for that all the time. So if you don't get any feedback, how long can you actually concentrate?
43:22
How long does it take without feedback before you start thinking about something completely different? You've probably all done it here. I'll try to keep you entertained as much as possible, but you're probably, you know, beginning to think about, well, did I, you know, remember to close the door and did I leave the lights on, you know, whatever. You start to think about these things.
43:41
And it turns out that, you know, how long does it take if you have no feedback at all? How long does it squeal? Isn't it? Okay. What was I talking about?
44:01
So it takes about 10 seconds. It takes about 10 seconds for our minds to start wondering. We human beings as a race are horrible. We are terrible at concentrating. If we don't get any sort of feedback, we start thinking about something else. That's why you have Frocker's powers in your software and everything else, you know, just something to keep your attention going.
44:20
You really need to have that feedback. It's not, you know, totally a hard limit, but it tends to be around 10 seconds. And at least that resonates with me as well. I can't really, you know, I can't really concentrate on something for more than 10 seconds at a time if I don't get feedback. So you really need rapid feedback on the systems that you're building. You need feedback in less than 10 seconds
44:40
because otherwise you're being pulled out of the zone. You cannot maintain this mental state of flow if you don't have feedback all the time. So I'm talking about how to make software development enjoyable or how to, you know, keep it enjoyable if you ever enjoyed it. I hope you enjoyed it one time. I hope you still do.
45:01
I am only aware of two ways that I know of where you can get feedback in less than 10 seconds. One of them is unit testing. So if you have real unit tests, I'm not talking about things that talk to the database. I'm not talking about things that talk to web services. I have built-in timeouts or whatever. They shouldn't even be talking to the disk.
45:21
But if you have real isolated unit tests that just run in memory, you will be able to run, you know, depending on your hardware, depending on your platform, you will be able to run thousands of tests or tens of thousands of tests within 10 seconds. This is one way to get rapid feedback, which is very important if you want to stay in the zone.
45:42
So the other one is, depending on your language, if you're writing in a compiled language, the compiler will tend nowadays to run in less than 10 seconds. I know back in the age of the dinosaurs, compilers were actually something that went on for hours. But most compilers nowadays are actually pretty fast.
46:02
So if you have a compiled language, you can't even run your unit tests before you compile. And it actually turns out that depending on how you design your types, in whatever code you're working with, you can make those types less tolerant of mistakes. So this is out of scope for this talk,
46:21
but if you will search for something called Poka-Yoke code and my name, I have a series of articles where I write about, you know, how can you actually express your type system in such a way that the compiler will catch some of the mistakes you made instead of waiting until runtime. So that's also something that can give you, you know, feedback in less than 10 seconds,
46:41
which is important because you want to stay inside the zone. So just to sum it up, how to stay productive outside the zone and also how to get back into the zone as fast as possible. So first of all, keep things small. If you keep things small,
47:02
what really happens is you don't have to read and understand as much code as otherwise. You don't have to build up a big, complicated mental model in your brain of how you think your source code is going to work when it runs, but you can just keep it small and just have something where you pretty much can read and just keep it on a single screen
47:21
and you can understand and interpret that pretty fast. So the other thing is, you know, if you use the distributed version control system, it enables you to experiment and reduce the cost of actually making mistakes, which again means that you don't have to build up a very high fidelity model in your brain of how your source control works, but you can probably build up a little bit more
47:41
of a more fussy model of how that source code is going to work. And then again, if you have this rapid feedback from, for example, the unit testing or the compiler, it will really tell you whether you did something wrong or not. So I've been in situations from time to time where I was not really sure which way
48:03
was a good way to proceed, but I just had an intuitive hunch that if I write a specific expression in code, that would probably work. And instead of sitting down and actually trying to think it all through, what happens if I write this line of code? I just write the line of code and run all my tests and try to compile.
48:21
And if everything is good, that probably meant that that intuition was a good intuition. And sometimes it turns out that it was a horrible idea and I just roll everything back because there's no cost to making mistakes in this model. So I've also had this experience. Sometimes I've been working at something. It's almost like that. I'm almost back at how non-geeks think
48:42
that interruptions work because I'm working on something and then I'm interrupted and sometimes that interruption goes on for hours. And then I come back to my system and I'm kind of like, I wonder, I can't even remember what I was doing before I was interrupted. And I just look at my stuff. So I just take a minute and look through whatever is open, whichever files that I have open, and I try to compile it.
49:01
If it compiles, I'll try to run my unit test. And that gives me a pretty good idea of where I left off. And I'm pretty much, you know, that does not always happen to me, but it has happened to me from time to time that a couple of minutes after I'm back in this thing, I'm just up and running and being as productive as the non-geek would expect me to be.
49:21
So that is something that works for me. I'm not saying that this exact way of doing it will work for you, but this is just meant as inspiration and I hope that you get something valuable out of that. So if you have questions, I actually do have a little bit of time for questions, but otherwise, I'll be around in the conference for the rest of the day, and then I'll have to fly back home to Copenhagen,
49:42
unfortunately. But let me see, do you have any questions now? Yes, there is one question here.
50:23
So the comment is, as far as I understand you, is that instead of integrating from your branch into master, you can go the other way around as well. That's what you mean. So yes, you can, but again, that tends to break down if you have lots of people involved and if everyone is doing that.
50:40
Martin Fowler has a pretty nice article that describes why that is, because if everyone does that, everyone is merging from master into their branch, but master is not really being updated very often because everyone is just pulling from master into their own branch, but each of those branches on different machines diverge more and more, if you will.
51:02
So when you try to get those things back in the end, all hell breaks loose. So if you're the first guy who puts your things back into master, you don't have a problem at all, but then the other guy, when they try to pull from master into their long-lived branch, they have the exact same problem. Does that make sense?
51:34
So I think what you're trying to do is, it works pretty well if you're the only one who works like that,
51:42
because then you're the only one who has a long-lived branch and you get all their integrations pretty fast. If you have lots of people who do that, you have diverging branches again and that becomes dangerous. So I hope that answers your question. Okay, anyone else? Yes?
52:16
Yeah, okay. So the comment is that the gentleman here doesn't really trust having incomplete code in production
52:25
and you ask about how can you isolate this. So that depends a little bit upon what sort of software you're building. So I'm not saying that feature toggling is something that you should use for every sort of system, because again, if you're building life-critical,
52:41
mission-critical systems, like if you're building control software for an airplane or if you're building pacemakers, you probably have to go through a very rigorous quality assurance process before you can have everything that can potentially ship. So this is not a one-size-fits-all model, but it probably fits quite a lot of organizations
53:04
and probably more than you think about. But it probably means that you need to start at the right place, because you have to start about, when you start working on the feature, you have to start thinking about how do I model this feature so that I can turn it on and off, because you don't want it to be visible in the user interface
53:20
or you don't want it to be something that's callable through your API or something like that. So you need to start at a place where you don't hurt yourself. Does that make sense? And it's really hard for me to give you a very general answer because it really depends on specifics, but it can be done in various ways.
53:40
So shameless plug, I am also the author of a book called Dependency Injection in .NET, and that book talks all about how you write loosely coupled code. Loosely coupled code pretty much means isolated code, a code that is isolated from other things. So if you buy my book, I will also happily sign it for you, if I'm still there. So there you go.
54:01
This is why I'm here. So this was a little bit of a wishy-washy answer, I'm afraid, but that's probably as good as I'm going to be able to give you one now. So I hope that it's not too wishy-washy, though. Anyone else? All right, so you are relieved, and you can go to lunch.
54:21
Thank you for coming.