Mat Ryer gathers a gang of ghouls and ghosts to tell spooky developer stories! Join us to hear tales of Matās $1k nightmare, Deeās infinite loop of horror, Natalieās haunted time as a junior dev & many, many more.
Featuring
Sponsors
Sourcegraph ā Transform your code into a queryable database to create customizable visual dashboards in seconds. Sourcegraph recently launched Code Insights ā now you can track what really matters to you and your team in your codebase. See how other teams are using this awesome feature at about.sourcegraph.com/code-insights
FireHydrant ā The reliability platform for every developer. Incidents impact everyone, not just SREs. FireHydrant gives teams the tools to maintain service catalogs, respond to incidents, communicate through status pages, and learn with retrospectives. Small teams up to 10 people can get started for free with all FireHydrant features included. No credit card required to sign up. Learn more at firehydrant.com/
Notes & Links
Chapters
Chapter Number | Chapter Start Time | Chapter Title | Chapter Duration |
1 | 00:00 | Opener | 00:30 |
2 | 00:30 | Sponsor: Sourcegraph | 02:24 |
3 | 02:54 | Intro | 00:38 |
4 | 03:32 | Welcome to Ghost Time! | 01:28 |
5 | 05:00 | Are you scared of horror movies? | 02:21 |
6 | 07:21 | Dee tells us about bluemonday | 02:38 |
7 | 09:59 | Mat's $1000 nightmare | 02:14 |
8 | 12:13 | Here's Johnny's on avoiding massive bug bills | 01:20 |
9 | 13:33 | Dee's infinite loop of horror | 03:13 |
10 | 16:46 | What is a greedy regex? | 03:04 |
11 | 19:51 | Natalie's haunted time as a junior dev | 02:12 |
12 | 22:03 | Advice for junior devs to stay out of trouble | 03:20 |
13 | 25:23 | Juniors should be able to make mistakes | 01:29 |
14 | 27:03 | Sponsor: FireHydrant | 01:18 |
15 | 28:33 | Campfire chill session | 01:24 |
16 | 29:57 | On hot CPUs and energy costs | 01:10 |
17 | 31:07 | Dee's support request from hell | 03:02 |
18 | 34:09 | Kris won't share imaginary marshmallows | 00:32 |
19 | 34:41 | Johnny's infinite loop of terror | 04:12 |
20 | 38:53 | On devs and consequences for their mistakes | 03:06 |
21 | 42:05 | Kris's spooky security hole | 03:21 |
22 | 45:27 | Dee thinks too secure is a problem | 01:12 |
23 | 46:39 | What's your pin number, Dee? | 00:31 |
24 | 47:10 | How are we gonna put this camp fire out? | 00:34 |
25 | 47:43 | Dee's SQL typo still haunts him | 01:54 |
26 | 49:37 | What *is* that sound?! | 01:33 |
27 | 51:11 | It's time for Unpopular Opinions! | 01:02 |
28 | 52:12 | Dee's unpop | 01:36 |
29 | 53:48 | We love you, Mat! | 00:56 |
30 | 54:45 | Natalie's unpop | 03:37 |
31 | 58:21 | We're afraid it's the end | 00:33 |
32 | 59:00 | Outro | 00:56 |
Transcript
Play the audio to listen along while you enjoy the transcript. š§
Hello, and welcome to Ghost Time. Iām Matt Ryer. Today weāre talking about tech horror stories. Iām joined, as everā¦ Johnny Boo! Johnny Boursiquot is here. Hello, Johnny.
Hello, Mattā¦
Welcome to the spooky Go Time episode. Again, in the spirit of it ā youāve really got to get in the spirit of itā¦ No? Yeahā¦ [laughter] Weāre also joined here by Kris Brandow. Spooky ghostsā¦ Hello, Kris.
Hello! Iām back, again. Finally.
Yes, welcome back again. Weāre also joined by your friend and mine, Natalie PistunoWitch. Hello, Natalie.
Hello!
Yeah, getting into the spiritā¦ [laughter] We have a special guest joining usā¦ Youāre not gonna believe this. Itās spoopy Dee. Dee Kitchen. Welcome, Dee.
Thank you. Iām enjoying being here. I even got the backdrop rightā¦
Good. Well, thatās a good start, because weāve literally just started. I mean, really, the only way is down now, in a lot of waysā¦ But hopefully we donāt go there. But we are talking about scary things today. How are you generally with scary things, Dee?
Thatās my career. All of it.
[laughs] Yeah. Okay. Anyone else? Anyone scared of ghosts?
Iām scared of Ghost Time.
Yeah, youāre scared of Ghost Time.
Iām actually scared of horror movies. I donāt really watch them.
Oh, yeah?
Same.
Heebie-jeebies for me.
Hmā¦
I just find them boring.
Yeahā¦
Did you come from the industry? I remember you saying, Kris, that you see a movie, the first few minutes, and you know exactly how itās gonna be laid out.
Yeahā¦ Itās the curse of having a creative writing degree and specializing in screenwritingā¦ All movies are just kind of ruined.
Itās all generics.
Thatās what I said, youād be happier if youāre just an idiot. Iāve always said that.
Is this something you know from personal experience, Mat? [laughter]
Ooh, shots firedā¦
I also donāt really like horror films, especially if thereās any kind of contradiction in it. I canāt deal with that. Like, if thereās an invisible thing that can grab you, first of all, itās invisible, it would be blind; weāve covered this. But also, if it can grab you, you can grab it, you can hurt itā¦ Like, itās not fair. Itās like when the physics donāt apply generally; then Iām just out. And I just tell everyone in the cinema, Iām like, āSorry, everyone. I canāt stay. Iāve got to go because of the inconsistencies of the physics.ā And I just go and get some popcorn and go.
[06:10] Do you get sweet or salty popcorn?
Salty.
Do you have a choice? Or is it always salty?
No, you have a choice. [laughter] Donāt you have a choice? Yeahā¦ What do you mean? Like, the police are going around saying āHey, are you only having salty? What are you doing?ā
I only discovered in my late 20s that some other countries sell popcorn that is not just salty in the cinema.
Oh, right? Yeahā¦
And then I came to the US, and then itās like not just two flavors, but 15.
Yeah, of course. Yeah. Yeah.
Thatās a horror story thereā¦
Yeah. You can choose individual bits of corn, and have different flavors, and just have as many as you want. You just program it. You do it as an app, and then it pops it on demand.
You say that, but we do have soda machines where you can choose your own flavor.
Yeah, Iāve seen that.
Those freestyle Coke thingsā¦
Has anyone come up with a good one yet? Because I imagine theyāre all terrible. Someoneās like, āYou know what? Iāve accidentally pressed these three, and Iāve made a brand new flavor that never existed before.ā
Well, noā¦ I think they make it so you canāt make any truly terrible-tasting ones, because that would be perhaps bad for them, soā¦
Oh, really? Clever. How did they do that? Well, weāll never knowā¦ Well, speaking of horror stories - letās get into this, shall we? Who Wants to kick us off with a spooky story? Oh, by the way, we should actually introduce Dee, because Dee, you wrote a package that I think a lot of people here will be familiar with. Can you tell us about bluemonday?
Oh, bluemondayā¦ Itās named because there was a package weāll call Black Friday, which has all the best markdowns, and itās a markdown package. And after youāve generated markdown, markdown can include HTML, which makes it dangerous. Itās probably youāre using this because youāve got user-generated content, and you want to sanitize it. So bluemonday is named after the New Order song, but follows Black Fridayā¦ And it basically sanitizers HTML; itās the only Go package that sanitizers HTML, which is a foolish and reckless thing to attempt to take on. But thatās what I did.
Amazing. And what do you like about it, and what donāt you like about it?
I like that it works. [laughter] Itās a streaming parser, itās got fixed memory, so you can use it quite comfortably in a lot of situations, and [unintelligible 00:08:20.10] I donāt like when people tell me thereās security issues with it, and then I have to go āOh, Iām supposed to take this open source thing seriously?ā I do appreciate it. I should actually say, I do appreciate security reports. But at the same time, you never can predict when theyāre going to turn up, and you never know what kind of words youāre going to open to try and actually figure it out.
Yeah, there must be a lot of responsibility, actually, because it is a package that is used, and quite trusted.
Yeah, itās used. I donāt know how many stars itās got, but the stars donāt portray the amount of times itās used. Like, itās used in Hugo, and everyone uses Hugo. And this is the HTML sanitizer that keeps Hugo safe. And itās used in so many things. Itās got literally thousands of dependencies. Do I take it seriously and stressfully? No. No, I donāt. Iāve figured that if someone is brave enough to take an open source project with an MIT license or a BSD 3-Clause, or whatever it is, and incorporate into their production software, thatās on them.
Okay, fair enough. Well, I have done that, butā¦ Good to know. I genuinely have used it though, quite a few times, soā¦ I like it, because itās like you opt into what you want to support. You explicitly say the things that you want to allow.
Yeah, thereās no way of defining what makes a good HTML sanitizer. Everyoneās got a different rule, depending on their use case. But the Java OWASP, Open Web Application Security thing - There sanitize it to find this really beautiful interface for sort of going, āI want to allow images, but I donāt want to allow these images that end in .gif.ā And I copied their API, and then extended it for my own use. So yeah, itās a really good way of doing it.
[09:58] Nice. Okay, well, Iām gonna tell you about a horror story in tech of mine, that happened quite recentlyā¦ I have this project which interacts with Twitter, and it interacts with the Twitter APIā¦ And so it polls results and then compares them, and stuff. And thatās just one of the things it does at a regular interval. And then what happened recently was something happened where the API key changed, and that request failed. And because of the way I was doing it in GCP, it meant essentially that it would retry. And because it was scheduled, it kept compounding. And this ran up a $1,000 bill for me, for yours trulyā¦ $1,000 given, paid, goneā¦ So thatās a bit of a tech horror story. And the advice for me ā
Is it tax-deductible? [laughter]
Probablyā¦
AWS famously refunds you if you get something wrong. Did GCP not do that?
I donāt know. Itās quite recent. I havenāt yet tried that. Do you think I should get in touch with support and see if theyāll ā
$1,000 would motivate me.
Yeah. There you go, $1,000. Okay, well, Iāll try it, and Iāll let the listeners know how we get onā¦
It could have been worse, right?
It could have been $2000ā¦
Yeah.
Or just $1,001. It would be worse, wouldnāt it?
It would.
What would you do, Johnny, if you saw thatā¦?
Iād call you and say āHey, youāve got a grand? I hear youāre loadedā¦ And just wasting $1,000 here, $1,000 there, on your bugs, and stuffā¦ā
Honestly, when I found out about it, I wanted to just karate-chop the air. That was the kind of spooky reaction I had to it. Just like [Whew] in the air. Angry. But yeah, itās a good lesson though. Like, set budgets and stuff on your things.
Do set an alarm, yeah. Budget alarms.
Yeah. Observability.
Yes, yes. And youād know a thing or two about that, yeah?
Yeahā¦ Okay, who can beat my $1,000 bill? Not $1,000 bill? Oh yeah, it was a $1,000 bill; but that makes it sound like it was one thing, doesnāt it? Like a single bill that had $1,000 on it; so itās not that. It was just paid through a bank transfer. Okay, whoās got another one?
I have one that could have cost many 1000s of dollarsā¦
Oh, Johnnyā¦
ā¦if it wasnāt spotted. So one of the things you can do with function as a service things, like AWS Lambda, for example, is that you can trigger a Lambda when you write an object to an S3 bucket. Word of advice - do not have your Lambdas write to a bucket that they are themselves responding to. [laughter]
Ohhā¦!
Because thatās gonna give you a very nasty bill. Yeah, and you will not like what you see. So yeah, thankfully, budget alarms came to the rescueā¦ [laughs]
Yeah, there you go. Thatās the lesson there. So what happens is, an object goes in the first time, that triggers the Lambda, the Lambda then writes something into that same bucket, which then triggers another Lambda, which then writes something.
Right.
And how quickly does that get out of hand?
Very quickly. [laughs] Like, if you want to see how well a Lambda scales on your own dime, you can do that. And, yeah, itāll cost you money very quickly.
Wow. Yeah. Okay. Pretty goodā¦ But yeah, thatās ā the alerts came to the rescue. Nice one. Okay, anyone else got one for us?
Iāve got another infinite loop oneā¦ Are we allowed to name company names? I donāt know, maybe itās internal and I shouldnātā¦
Yeah, I donāt know.
I worked for a certain company which has an orange logo that has a bit of a light shining behind it, and they man-in-the-middle the entire internetā¦ Now, with that in mind, when I was working for said company, in their DDoS teamā¦ We didnāt DDoS people; we were protecting against DDoSes.
Yeah, Iāve wonderedā¦ The DDoS team!
[unintelligible 00:13:56.02] thatās the opposite of what weāre doing. No, we were trying to protect, and they have a systemā¦ Theyāve got all these 200 POPs (points of presence), and thousands and thousands of serversā¦ And every single one of these is protecting some of the traffic; each machine can do like 20,000 requests per second.
[14:15] And yet, they need to be able to actually show the value back to the customer, and make these sort of decisions centrally. So you send all the logs somewhere, and theyāre all been sent to one data center. So what you end up with is like, if youāre doing globally 10 million requests per second, you get 10 million log lines per second in one place.
Niceā¦!
A certain customer, on a certain point in time - industry and type to be non-disclosed - wrote an infinite loop in their client, and it basically spikes 8 million requests per second on top of our normal load.
Oh, wow.
And they basically broke our logging, the entire visibility. So they were effectively under attack, but now flying blind, because we couldnāt see anything because theyād broken all the logging. That was not a good day.
Yeahā¦ That one doesnāt sound fun? What happened?
We figured out which customer it was, but we couldnāt figure out the rest. But we asked them what theyāve done, and they figured out that bit and stopped it.
Oh, wow.
They fessed up to it, they owned up to it? Somebody wrote an infinite loop?
Yes. [laughs] I think they realizedā¦ They must have seen what was happening on their side.
So they didnāt pull a well ā well, I will not name names, but they didnāt blame it on on of the interns?
Oh, weāve got a certain thing where actually an intern did that. I had that intern, and heās actually really good tie. Heās become a full-time engineer in that team. Heās really good. Learned a lesson that none of us will replicate.
Oh, yeah. I love interns. I just donāt like to throw them under the bus when something goes wrong with my companyā¦ [laughs]
No, that one was interestingā¦ Also, at said man-in-the-middle company, we had a system ā the system was brilliant, right? You could send an instruction to any machine in the world in under 10 seconds, and every machine received the same instruction. And thatās great when you want to say thereās a new domain name, because you just have the whole world at the same time. But itās really bad when you say thereās a new way to stop traffic. And weāve made a greedy regex. And the greedy regex was the problem. Now, frankly, the system shouldnāt have allowed it, but the system did allow it. And we were all at lunch, it was an all-hands lunch, and the next thing we know, we just get people running and going āThe internetās down.ā Because we used our own systems. And we lost everything internally at the same time. That was hard, too.
I feel like there are many lessons thereā¦
There was a lot of lessons.
What weāre having for lunchā¦ [laughter]
Lunch went coldā¦
Thatās scary, aināt it? But hang onā¦ So can you explain - someone that doesnāt know what a greedy regex isā¦ What do you mean by that?
Yeah, a greedy regexā¦ I mean, if you do something like .*, what youāre saying is match any character, any number of times. So if you .*.*, youāve now exploded this any character, any number of times, followed by any character, any number of times. And what youāre doing is youāre increasing the CPU computation. Youāre still putting the same fixed input in, but what it can match is now ā youāve doubled the possibility in just that one go. And essentially, thatās what happened. But some of the inputs were web pages and web traffic, so they werenāt small. They were quite large inputs. And under that condition, they consumed all the CPU.
So wherever this rule was applied - and we had shipped it globally to every single website, every single bit of traffic - we fried every single machine instantly. So it was about four hours for us to recover from that. And the teams I saw, they did interesting things. We were connecting directly to machines, and looking at the Prometheus on them, because we had no other observability.
Wowā¦ And what was the impact of that? How many people were affected?
Everything was affected. We knocked out a lot. DNS, TLS, HTTP, everything. It was one of those nightmare scenarios. And you sit there as a company, you sit there and you sort of go, āWhat are these meteorites?ā the dinosaurs went extinct by a meteorite. āAs a company or product service offering, whatās the meteorite thatās going to hit us?ā At that company, we were hit by every meteorite we predicted. It survived, but still, on the days when they hit, it lays waste to everything.
[18:15] And everyone has them. The thing that youāve got to realize is when youāre there, youāve got to sympathize with ā you can accidentally see another company go through thisā¦ Theyāre having a bad day, and youāve got to sympathize, because one of those meteorites is gonna hit you one day.
Yeah, we see the HugOps goes around often on social media, and things, of people sending their support in those difficult timesā¦
Yeah, thereās a good tradition of sending cakes to each other to sort of go āThinking of youā¦ā
Yeah.
And try and not have your salespeople ambulance-chase.
How well was your break-glass procedures documented?
It was pretty good. We were lucky that this happened during a London lunch hour when all of the SRE team - the original SRE team - were there. Itās possible for a few people to break glass; they could do so in about five minutes once we actually understood what we actually had to do. It took about 20 minutes for us to gain any visibility and to sort of understand, āHey, itās this feature. Go turn that off.ā
Regular expressions, huhā¦
Thatās still hard. Theyāre hard for everyone. Easy to write, hard to understand what theyāre doing.
Why are they called that? What is regular about them?
Thatās out of my domain. I donāt know if anyoneās got the answer for thatā¦
No, genuinelyā¦
Iāve just watched a talk from Strange Loop about regular expressions, and the speaker did go into this, and Iāve completely forgotten what she said. But we can probably put that talk in the show notes. It was a really good one, about just like the history, like Ken Thompson came up; it was pretty cool. So Iām like, āOh, I know that dudeā¦ā Yeah, but no, it has to do with like mathy things, and finite automata, and all of thatā¦
Yeah.
When I was a junior, which is the closest to intern I was, I was working with a team lead, and when we deployed something together, we looked at itā¦ And I forget what it was exactly, but this is a company that receives a lot of pings from the SDK of the many clients, and itās all real time. And if that is not logged, then the entire transaction flow, user flow is gone forever. And we deployed something we worked on together, we worked on it for half a day, we tested it, we did all the good practices - because thatās how you do with a junior, you want to show that youāre very thorough, and you go through all the tests, deploy, look at all the metrics, and see that it behaves as expected. And then he went to lunch, and then I stayed. Ta-daā¦! [laughter] And then I proceeded to do something else, and then suddenly, a weird behavior started pinging Slack, all the monitoring channels, that āSomethingās wrong, somethingās weird.ā
And then some of the colleagues that were there tried to see where it comes from, and we couldnāt figure this out in 15 minutes, and then, bravely, I came to the head of the DevOps team - there was no SRE team at the time - and I said, āI think itās this thing that we did. Can I revert it?ā Nobody else from all the other senior people that was - I donāt have another better word than brave, but I donāt use the word braveā¦ Nobody else wanted to do anything about that, because nobody was sure. And then I was like, āLetās do this. Letās try. At worst ā it cannot get much worse than thatā, and reverting that indeed succeeded, and then we were all very happy. And then I was like, āI think I know how to fix it. Can I try?ā and then he looked at me and said āNo. Stay away.ā [laughter] Yeah, I to next-level brave.
Yeah. Well, what a great way to learn stuff though, isnāt it?
Break them, yeah.
How often does that memory come back to haunt you, Natalie?
Every time Iām asked, at leastā¦ [laughs] Every time I get to speak with other junior people. To give the good example of it, obviously, weāll break something, soā¦
Right.
ā¦be reasonable about your expectations.
Iām curious if you have a way ā like, now that youāre older and wiser, and youāve been through the experience, and it was a great teacherā¦ Iām wondering, do you have strategies now for doing things that are scary, that could break things? Like, do you have a strategy for tackling that now?
The thing is we did everything right at the time, right? So we did all the tests we could think of, we thought what do we expect in the logs, in the monitoring, in the dashboard, and we observed. So the only thing that I would do different is not deploy before lunch. [laughs] So you can, I guess, observe for longer. Speaking of spooky things, right?
What were you having for lunch?
I donāt think I had lunch that day. I mean, I was like nudging stuff, but I donāt think I had a lunch-lunch.
Yeah, thereās another theme emerging hereā¦ One of the main reasons to write good code is so you can just have lunchā¦ For a good reason.
Thatās another thing I would the differently; I would write good code. Yeah. [laughter]
Thatās optional. If youāve got good tests, you donāt need good code. Controversial.
So to me, what I usually tell junior members of staff is to be like, āLook, we expect you to break things. Itās just part of sort of maturing as an engineer. What is helpful, and even if you follow the playbooks and you do the right things and everything else, sometimes things will go wrong; whoever writes these things, how many people have touched the documentation youāre looking at, thereās a chance that they might have overlooked something, or they took something for granted that you as a junior havenāt encountered yet, so you donāt take it for granted. So thereās some steps in between. So thereās some unwritten things in between the lines, that are sort of being conveyed, that you have not yet matured enough to kind of pick up on. So just document every step you take.ā
Itās much easier for the team to go back and say āOkay, what āā Because the first thing theyāre going to do is ask you, āWhat did you do?!ā Right? [laughter] So after everybody calms down, you can say, āWell, these are the steps I took.ā Even to this day, I do this, right? If Iām working with a system that I havenāt come across before, and I donāt know what the side effects are of the things that Iām going to do, Iāll literally, in a document somewhere, literally be copying the commands that Iām issuing in the command line - Iām literally gonna copy them into this doc, and Iām basically Iām capturing the output as I go.
Now, one could say thatās sort of extremeā¦ I mean, again, if there was a playbook for it, if there was some automation that I could just click the button, or issue the command and let it do its thingā¦ But if I have to do this step-by-step thing, that means thereās no playbook for it. That means thereās no automation, thereās no script, whatever it is. So Iām just gonna be literally documenting what Iām doing step by step by step, and if something breaks, I know exactly what broke. Or if I canāt tell what broke, I can ask my team and say, āHey, these are the steps I was following.ā Right? And then nine times out of ten - maybe Iām just lucky - theyāll be like, āOh, yeah, this thing - you should have done this command before you do thisā, whatever, and then we find out that thereās a gap in the documentation, or a gap in the process, or something like that.
Yeah. And you can update it.
Yeah. So literally, just track what youāre doing; that may actually end up helping you. Hey, guess what - that might even turn into a playbook or an opportunity for automation for whatever it is that youāre working on.
Yeah, itās like step one, SSH in. Step two, check the Go version. Step three, drop all the database tables. [laughter] Spot the problem.
Itās just pen testing. Itās fine.
Exactly. Yeah. You shouldnāt be able to do that, really. If you can do thatā¦
I think thatās important though, that theyāre taking steps, because it helps with something elseā¦ It helps people admit that theyāve possibly done something. Who in their early career has got the courage to say, āIāve mucked upā, right? āI potentially have lost you money, or time.ā Most people are terrified; and youāre terrified legitimately, because youāve got no experience in the industry, youāre brand new, youāre finally being paid to do something, and you think youāre not very good. Weāre long in our career, and we probably think weāre not very good. So early career, youāre crushed. And that ability to turn around and go, āThat might have been me. I think I did that. I pressed this button, and then it broke.ā Thatās tough.
[26:01] Yeah. Well, I think that speaks to like the blameless culture thatās important. Itās important to reach the point where your people arenāt punished for these mistakesā¦ Because the last thing you want is people - like you say, they bury it, they try and hide it, or just donāt tell anybody, which could make the problem much worse. So yeah, I think that culture plays a big part, doesnāt it?
Yeah. You should always blame systems and not people. If something went wrong, itās not the personās fault, itās why did the system allow the person to do that?
Right. So when Johnny says something thatās mean to me, itās not Johnny that I have to complain about. Itās the system that lets Johnny get on the podcast and be horrible to me. [laughter]
Exactly. Itās part of the system to be mean to you, Mat, donāt you know?
Indeed.
Yeah, it feels like it sometimesā¦
Have we got any more horror stories? Oh, by the way, this campfireās warm isnāt it? We can probably put an effect of a campfire over the top; letās pretend weāre all gathered around a campfire. Oh, what do you think of the campfire, Johnny?
Sure. Yeah, yeah. [unintelligible 00:28:44.21]
Iām convinced by that performance, Johnnyā¦ Have you done actual theater? What about you, Kris? What do you think of the fire? Itās cozy, isnāt it?
Sure.
Okayā¦
Crackly, warm fireā¦ We donāt have any marshmallows, so itās not as goodā¦
Donāt we? Itās imaginary land. Itās podcast land. You can have anything you want. Check this outā¦ Whatās this? Look, look at your faceā¦ Look, itās marshmallows. Natalie, what do you think of the fire?
It shouldnāt be burning serversā¦
No, it shouldnāt be burning servers thoughā¦ No, this is a fire that doesnāt actually release any carbon. Itās a good fire.
Itās basically my GPU overheating. [laughter]
Itās the sound of my computer
The money fireā¦ My electric billā¦
Itās some old Intel Macs, you knowā¦ We just turned them on, opened Slack, and now theyāve made us a nice fire. Itās good.
[laughs] Just have Slack and a regular expression running; itāll generate enough heat to cook your marshmallow.
And those fans can definitely fly us somewhere. We could all go visit Mat in the UK.
1:Yeah. I mean, make sure you do go through proper passport control. Donāt just fly in at any point, because thatās illegal. But yeah, otherwise do, please visit; weād love to have you.
[29:57] Yeah, I remember talking about hot CPUsā¦ The CPU Hot program that I used to have on an Amiga, and basically run it, and it made the CPU hot. And that was a program that you could have ā it was on like a front of a magazine, for some reasonā¦ āWhatās that doingā¦?ā
Someone wrote another infinite loopā¦
Yeah, there you go. Theyāve turned their horror story into a big success story, because they got on a magazine cover with a floppy disk. Soā¦
Interesting. Now with the energy costs going up here in Europe, all the heaters are becoming more expensive, because people assume they will not have gas to heat their house. Many apartment buildings have these systems with gas. So you buy like electrical heaters to warm the place in case you might need that. And theyāve become really expensive. So really, what youāre saying is that all you need is an old computerā¦ Which is probably cheaper at this point.
I bet we see a spike in the downloads of Slack in that areaā¦ [laughter]
Or that CPU Hotā¦
How many Electron apps can I install on one machine?
Okay, has anybody got any other horror-horror stories?
Iāve got moreā¦ Iāve got one which is something thatās kind of triggering. I donāt know if anyone else has got sort of triggers from being horrified. One of my old bosses used to come to me, and if he started the sentence with, āWhat do you know aboutā¦ā, then I knew immediately it was downhill. Itās like, āWhat do you know about Perl?ā It was like, āUh-ohā¦ Where is this going?ā Or āWhat do you know about directory services in exchange?ā Itās like, āUmā¦ That they exist?ā āGreat! Youāll do!ā and off youāll be shipped to a client site. [laughter]
And I ended up at one of these clients sites, and there was a customerā¦ And it was a big, big company. And they were basically doing a split. Merger and acquisition is the normal thing you hear about; theyāre doing the other thing, theyāre splitting in two. And they basically said to the contractor, the company I worked for, to split their Active Directory, to clone it, and then rename it to the other company name, so they had a perfect copy renamed. And I just turn up on site, I know a bit of Visual Basic, a little bit of C# at that pointā¦ How do I approach this problem? I did not know at all.
So I get in touch with Microsoft Professional Services and go āHow would you do this?ā And theyāre like, āYou donāt. Thatās impossible. Donāt do that. Thatās reckless and foolish, and itās not supported.ā And I was like, āOkay, but Iām being paid for this, and I know no better, because Iām barely in my mid-20s, and Iām gonna take a stab at this.ā
And I wrote a script for the registry on one of the cloned Exchange Server machines, and I basically renamed everything. And I fired it up afterwards, and it worked.
Wowā¦
That was my dayās work done. I left. I have no idea whether that workedā¦ [laughter] It appeared to work.
āWhy is your two-week notice exactly after this project ended?ā āOh, I donāt know. I donāt wanna know.ā [laughter]
Anyway, contractors, thatās what you get.
Wowā¦ That could have just worked though. But you know, I never trust code that works first time. Thatās why I like a failing test beforeā¦
The only thing that I was really, really scared about ā the name of the company in the Active Directory was six characters long. And I was reasonably sure that that was a magic value. So I asked them for a new name to be the Active Directory name that was also six characters long. Thatās the only thing that I think was intelligent about what I did that day. The rest of was luckā¦
And lots of regexesā¦ [laughs] Again.
Yeahā¦ Good call.
Spookyā¦ Spoopy.
Spoopyā¦
But yeah, thatās the scary questionā¦ No oneās asked me that for years. āHey, what do you know aboutā¦?ā
Now youād be like āNothingā¦ Nothing. Nothing at all. I donāt want to know anything about it. I know nothing.ā
Maybe thatās the thing thoughā¦ When you see people late in their career, and youāre just like āWhat do you know about this?ā and you think theyāre doing the āIāve forgotten more than youāll ever learnā, but no, theyāre actually going āI donāt want to do thisā¦ā [laughter]
Active Directory. Never heard of it, mate. Never heard of him. Thinks itās someone manās nameā¦ Active Directory. Thatās a weird name for a man. I think thatās a man, just really selling that you know it, just to get the jobā¦ Oh, just a tip there for people that want to get into that. Like I said, Iām jet-lagged. And this is a spooky Halloween party specialā¦ How are those marshmallows looking, Kris?
[34:15] Theyāre toasty, and brown, and delicious.
Oh, perfect. Well done. Are you gonna share, orā¦?
Noā¦
Nahā¦
These are my marshmallows now.
Yeah. Although theyāre imaginary, butā¦ But you know, I still want one.
We have an infinite supply. Everybody can make their own marshmallows.
Oh, yeah. Okay.
All you need is an infinite loop.
Speaking of loops, I have a scary storyā¦ But itās actually the story that I think helped me gain a new appreciation for sort of how to integrate systems, how distributed systems have sort of pitfalls, thereās a trade-off for everything, and all the things that we value as best practices for dealing with integrating systems.
So I was working for an organization, a very awesome organization, a nonprofit, which basically helps students, especially in underserved communities, sort of prepare to take sort of standardized testing, and that kind of thing. So for months, leading up to a major sort of testing day - students are going to come, sit down into their classrooms, theyāre going to be logging in and taking an assessment to help them with the real things. And this is like a coordination across multiple schools and everything, so that the whole county is doing this thing. So weāre talking maybe like 3,000 to 4,000 students that are gonna all sit down and do this thing.
Wow.
And basically, Iām part of the team that basically has been working on this sort of integration for months now. We had different systems talking to each other, and everything else. And development, and even in staging, everything works perfectly. [laughs] Systems can talk to each other, weāre sending lots of traffic, keeping an eye on things, and we are observing to the best of our ability with the tools that we have on production day, basically, which is when students actually sit down to do the thingā¦
What we didnāt test against is basically having roughly 4,000 students trying to log into the system at the same time. [laughs] And because you have these systems that are talking to each other for authentication, and pulling things, whatever it is, basically, we just had a thundering herd kind of situation happening, and we didnāt account for that, because all of our tests, even our integration tests and everything else - they didnāt factor in that kind of scale. And I take responsibility for that, because I was one of the team leads, and basically, one of my questions was supposed to be, āWhat is the expected number of users and clients on this system?ā And we touched on these things, but there were bottlenecks in the system that we should have better accounted for. And thankfully, we had enough of an understanding of what was happening, we had enough observability to be like, āOh, crap, we know where the bottleneck is. We need to go do thisā, whatever.
So within a matter of about an hour and a half or so, while students are waiting there - because they canāt really dismiss everybody and send everybody home; weāre talking like countywide 4,000+ students, all this coordination across monthsā¦ To me, this remains the best and worst moment of my career, because Iām like, āHere I am, Iām supposed to be serving these kids.ā Often, we are so far removed from the consequences of our code, right? Good or bad. Weāre so far removed from it. But here I am, I knew exactly what the impact that my mistake was having on these kids, right? And they already have been given a short straw in life, and here I am just making that worse, right?
So after that incident, I was never again, like, āWhat do I need to do? What do I need to learn? Who do I need to talk to?ā Like, it was ā I had to level up. And any point in my career - I canāt remember a single incident that has driven me to level up as much as this one, because the impact was so real. It was so in my face. Just undeniable. I thought that was scaryā¦
[38:11] That is the $1,001 bill.
Yeah.
Listen, I would have gladly handed over $1,000 out of my pocket like to be like, āLook, whatever this is, make it go away right now.ā
Like, to the kids. Just give it to the kids.
To the kids. [laughs]
āUncle Johnny has messed up again. Come and collect your $20 bills, everyoneā¦ No college for you, but hereās someā¦ā Yeah, thatās horrific. Yeah, but when the stakes are that high, Johnny, itās likeā¦ That is scary.
Yeah. And you feel awful. Like awful, awful, awful for being the responsible for that.
What do you think about engineers sort of having that sort of sense of consequence? Because it comes in multiple directions; you get salespeople going, āIf you donāt do this, weāre gonna lose a million-dollar deal.ā Itās not that the engineerās gonna receive no million dollars round. Theyāre just gonna get their normal salary; theyāre getting the normal pay. Thatās a little bit abstract. Itās a ton of stress.
And likewise, when youāre working in incidents, someone will turn and go, āItās affected this air traffic control signalā or āItās affected this sort of kids, or hospital, or the traffic lights are downā or whatever. Kind of unhealthy, isnāt it? Itās like, weāve got to keep it abstract enough that ā because I get that it changes us. Probably all of those incidents changed all of us. They were all horrifying moments. But Iām also like, āThatās the path to burnout, sort of accepting the consequences for all of these things.ā
Yeah. Some value in being somewhat abstracted from the consequences.
Yeah. If you consider it too much, it just weighs so heavily. Itās too serious. Itās too much of aā¦ And the things you need to do to actually get out of those situations - they become even more horrifying and scary. āWhat if I prolong this? What if I make it worse?ā And sometimes youāve just got to be a bit fearless, and you canāt if youāve got that sort of burden on you that we put on ourselves.
I feel like this is where systems can be helpful, though. I think we as an industry are pretty bad at understanding that there can be bad consequences. Itās like, something terrible happens and weāre like, āOh no, this terrible thing happenedā, but so much of the time, that terrible thing was completely predictable, and we just didnāt predict it, because we thought itād go fine.
Like, I worked for a lifeguard ā when I was young, I worked as a lifeguard, and I remember one of the things that we always did is we trained a lot, but also did a lot to make sure that the environment was always a safe one. So we did a lot of that. Thatās why lifeguards yell at people so much, and theyāre like, āDonāt run! Donāt do these things that might result in you getting injured.ā I kind of feel like in software engineering we just let people do whatever, and then people slip and bash their head, and theyāre bleeding all over the place, and weāre like, āOh no, how did this happen?ā And itās like, āWell, not only did we not tell people not to run, but we also left giant puddles of water on the floor, because we didnāt put down the proper mats to make sure that, if they are running, they can do it safelyā¦ā Like, thereās all these other things that you have to set up as precautions. I feel like in software engineering we just kind of donāt doā¦ And part of me wonders if we donāt do that because there arenāt enough consequences flowing down to the engineers.
I feel like the number of times Iāve been at companies that ā Iāve worked at banks, and people have been like, āWell, this isnāt like life or death.ā And Iām like, āThis is affecting peopleās money and their livelihood. What do you mean?!ā And like, thatās always the thing that gets rolled out, is if itās like, āOh, well, weāre not doing things that could kill people.ā Itās like, āWell, but weāre doing things that can substantially affect peopleās livesā, and I feel like we have to take that into account. Because when we donāt, we do lots of immoral things, like run psychological experiments on people without their knowledge, and other terrible things, because weāre like, āAh, whatās the harm?ā
I havenāt done that for weeks. I donāt know why youāre bringing it up. [laughter] Itās spooky, aināt it? Itās a spooky show.
I have a spooky story, I thinkā¦ It feels spooky. So Iād recently joined this company, and of course, because itās the modern day, theyāre using Kubernetes.
Classic.
And of course, theyāre using all the shiny things with Kubernetes, so thatās using Istio. No one actually knows how any of this works. Itās just like, āOh, this is what weāre supposed to be using.ā So we have this big olā cluster, and itās running, and our DevOps people are pulling their hair, because they hate all of thisā¦ And I start like reading through the codebase and looking at things, and Iām like, āOkay, these auth policies look a little funky.ā And then I go talk to people, and theyāre like, āWe donāt really have any auth policies. Everythingās just kind of open right now. Like, everything in the backend can just talk to each other. Thereās no auth policies.ā And Iām like, āAre you sure? Because I see these auth policies in the codebase.ā And theyāre like, āYeah, but we donāt think theyāre being used for anything.ā Iām like, āOkayā¦ā So I just kind of like let it go, and go about my businessā¦ And then I have like a few more of these conversations, and Iām like, āThis feels weird. But you know, all these people know more than I do.ā
And then months and months later, someone stumbles across this one auth policy that has no labels, and no access rules, which in Istio language means that it applies to literally everything, and allows all traffic in. So this one policy had just opened our entire API, including the public API, to the entire internet, for anybody to do anything without needing any authorization. You just needed like a JSON web token that you could easily get from anywhere. And I was just like ā so it caused all these problems, everybodyās freaking out, and then they just rip that policy out and theyāre like, āOkay, well, without this policy, weāll be fine.ā But then all of those auth policies that had been sitting there, that I was like, āThese look funkyā, all those took over, and all of those were broken. So then it broke all the APIs. So then they had to put the other policy back, and then go through, and like, go find every single auth policy within Istio, and then fix all of those auth policies, and then they could finally remove that one policy that was opening everything to the world.
I think the total amount of time that the door was just open was about nine months, and to the knowledge that people had, nothing bad happenedā¦ But yeah, it was quite horrifying.
That is still a security incident requiring disclosure, Iām afraid.
Yeah.
I know. Iām just like, āIs this disclosure?ā [laughter]
Yeah, it was like, āOhā¦ Oh, no.ā It taught me a lesson that like when I see funky things, I should probably bring them up a little bit. Like, āNo, no, that policy is thereā, and that policy definitely doesnāt work. And some of the broken things were like some YAML white spacing thing, where itās like something was tabbed in a little too far, and then people were just copying and pasting these policies, and then not testing them, which was like another thing that we had to go back and be like, āPlease test the things that you put into the codebaseā¦ Pretty please, thank youā¦ā
Yeah, I think that also is a bit of a lesson, is if there are bits of code and youāre like, āNo, yeah, but that doesnāt do anything now. Like, that used to be doing something and now it doesnāt.ā Itās like, either take it outā¦ If itās really not doing something, get rid of it.ā
Prove it.
Exactly. It probably is doing somethingā¦ And if it isnāt, maybe it should be, like in your case, Kris.
Yeah.
Spoopyā¦
The zombie apocalypse.
Yeah.
ā¦will be caused by Istioā¦ [laughter]
Zombie code just haunting us.
Iām never sure whatās worse than those thingsā¦ Like, the insecure environment, where it just like nothing applies, or the extremely secure environment. Iāve seen somewhere, theyāve been really locked down, and like everything; youāve got an IP firewall rule for everything, and youāre like, āI have total confidence.ā And then mysteriously, API calls between machines just didnāt work. And itās like, āWhy now?ā
And what we realized - the debugging for this went wild; it went really low. And we were down at Wireshark and weāre watching whatās going on, and weāre watching whatās going on inside the kernel, but we were turning on contract connection tracking. And this is in TCP, itās got little tables, state tables in there to keep track of the sort of TCP connections. But you can overflow these tables; we were turning them off, and every time we turned them on and off, we were toggling which IP firewall rules were actually matching or not.
[46:16] So we were taking existing connections and then just randomly dropping them every time we flipped these thingsā¦ But we could never observe it, and we were just there the whole time, just going āWeāve lost it again. There goes the connection.ā
And it took us weeks of just poking around, going āWhatās going on? I canāt see it. Ghost in the machine.ā Yeah, too secure is a problem. Honestly.
Well, in that spirit, Dee, whatās your pin number? Just give us three of the numbers. Letās play mastermind.
Itās just like ā what was it, Spaceballs? 1234ā¦ [laughter]
Yeah. No oneās gonna suspect that, I think. No oneās going to try that, are they?
0000ā¦
Does it allow you? I donāt think systems allow you to do that.
Why?
I donāt know. Iām gonna try and change my pin nowā¦ [laughter]
Oh yeah, I donāt knowā¦ Maybe because itās too easy. But I donāt know. Any other horror stories before we throw a ā what do you put on fire, water? You donāt do that, do you? You just let it die out on its own. No, weāve got to be responsible. How are we going to sort this fire out?
By throwing water in the electrical equipment?
Foam. Weāll use foam.
Turn it off.
Weāll use found close Slack. Yeah, close Slackā¦
Yeah, and the fire will die down. So before we put the fire out, has anyone got any other final horror stories?
Well, you know a few of mineā¦ Any one you want to hear?
What, do you mean in real life? [laughter]
I wrote one down, which actually I wrote in advance, about doing a SQL statement and accidentally double ā putting in the semicolon after the from table. So an update. So the WHERE statement didnāt applyā¦ And that was to a production systemā¦
So what was the effect of that then? So normally, you would be updating something and specifying the WHERE, which will limit what gets changed, right?
Yeah, exactly. I tweeted this when you actually asked about it, and I think no one really appreciated what it does and how it happened. But I executed the query; I was just tidying up some debt that was leftover, and it should have been really trivialā¦ And I practiced it, and then I copy and pasted it into the console. But after I copied and pasted the first one, for whatever reason, I fingered a semicolon, and then put in the WHERE line. But that makes it two commands. So it successfully did the update column set value equals on table, and it didnāt apply the WHERE. So it updated ā I think was like 90 million rows, or somethingā¦
Oh, Godā¦
And the machine was very fast; faster than I was at finding Ctrl+Z.
Oh, noā¦!
And thatās why you work inside of transaction blocks, kids. [laughs]
Thatās why thatās advisable, but it was not what I was doing that day. The real mess though was actually sort of going āHow can we restore this when our database backup was like 12 hours ago, and thereās 12 hours of changes in other tables since then?ā
Ouchā¦
So youāre not going to sort of do anything there. So itās a pull the old sort of thing, extract that table, and then go and update all the necessary rows to the right things. It takes timeā¦
Yeah. I liked that you couldnāt keep up because the machine was so fast. Is that why you now insist only on running on Raspberry Piās?
Intel Max. Run on Intel Max. Itās the solution for everything. [laughter]
Okay, well that sound - we all heard that sound, didnāt we? How would you describe that sound that we just heard?
Spookyā¦
Natalie? Spooky, yesā¦ Natalie, how would you describe that sound weāve just heard?
Did I miss the sound?
Yeah, we heard that soundā¦ Kris, how would you describe it?
Was it the marshmallows?
I think itās the sound of us closing Slack so our fireās going away.
Was it marshmallows? Yeah, itās kind of a spooky soundā¦ Wasnāt it, Johnny? How would you describe that, Johnny?
As silent as your hairline? [laughter]
You asked for it. I mean, you did ask for it.
Amazing. Yeah. Is it silent because itās so far away? Like, itās in the distanceā¦ Thatās what we mean. Like, itās screaming, but you canāt hear itā¦
Itās too far back?
Yeah. Itās just screaming āWhy, dad?! Why?!ā You know what I mean? If you know youāre going to look like this, donāt have kids. If you know youāre gonna make kids that look like me, donāt have them. Thatās my adviceā¦ But dad didnāt listen.
Weāre all talking about recessions nowadays, but youāve been in one for quite some time, right Matt? [laughter]
Oh, there we goā¦ That was a good oneā¦ That was a good one, yeah. Good point. Okay, wellā¦ That sound of Johnny talking tells us itās time forā¦ Unpopular Opinions!
Okayā¦ Whoās gonna kick us off with the first popular opinion? Dee! Youāve been chosen.
You scared him. He was like, āWhat?! What happened?! What happened?!ā [laughs]
Itās just sounds. I promise no oneās pushing their hand around the Ouija board to make it spell out about my hairline. I donāt want to hear anything from the ghosts about my hairline, Johnnyā¦ Right? So donāt make it do that. Everyone put your hand on it. Let it be natural, and weāll see. Yeah, itās floated over to Dee. Okay, Deeā¦
It was a fixā¦ [laughs]
ā¦whatās your unpopular opinion? It was a fix, yeah.
Mine comes from the last Go Time. One of the guests said that Go is brilliant, you donāt have to worry about security; it does everything for you. You donāt have to worry about the memory management. Everythingās super cool. And I think it actually has made Go more insecure, because people are so ā they put so much trust and safety in the actual sort of language, that a lot of the basics are dropping by the wayside.
For me, the number one thing people should do is sanitize inputs. And itās not because I wrote bluemonday but they should do it on everything. And I just donāt think I see anyone doing it anywhere. Thereās just great, big holes in everything, but people are still there going āBut weāve got memory safety.ā Memory safety saves you from yourself, not from others.
Hmā¦ What do we think? Is that popular, or unpopularā¦?
Well, it should be popularā¦ Sanitize all your inputs?
It should be. But if you look at all of the open source stuff thatās out there, very few people actually sanitize, check, validate their inputs. Theyāre just like āIāve mapped this input directly to a struct, and Iām going to use it.ā They take their form fill, and theyāre on their way.
Yeah. One simple version of that is just a limit reader when youāre reading a body, or like of a request; you can error if itās too big, and things like that. Thereās bits like that. But you end up doing quite a lot of that heavylifting yourself every time.
There are libraries out there where you can add tags and say āThis should be a text field. It should be no longer than this length. There should be a number, and it should be no longer than this.ā But far too few projects do it.
Do they use reflection? I think Iāve avoided them if they ā but itās not a great reason to avoid it. I just tend to notā¦
Why are you afraid of your reflection? Are you a vampire?
Well, itās because I am DraCool ā Yeah because you know, thatās myā¦ Russian accent there.
Because he doesnāt want to see that hairline, obviouslyā¦
Ohhā¦!
Thatās why I donāt have mirrorsā¦
Kris is in on itā¦ Alright, everybody take a turn.
Yeah, Kris is in on it.
Take a stab at Mattā¦ [laughs]
[54:10] Iām like a pinata. Iām like a really rubbish pinata. Imagine buying a pinata for kids and itās me. [laughter] Youād take it back, wouldnāt you? Youād be like āNo, weāll probably go for the unicon instead, on second thoughtā¦ I should have guessed that, reallyā¦ā Okay, yeah. Fine. Thanks, Kris. Itās a Halloween special, youāre allowed to do thatā¦
Spooky pinata.
Yeah, exactly. Okay, and other unpopular opinions?
I have one.
Natalie PistunoWitchā¦! [wolf howl] They donāt know Iāve just done that, so it just sounded like a sound effect in the background. Come on.
Some of the training that you should be taking occasionally throughout your career, even annually, should not be about things that are in the future, like new things, like new technologies coming and so on, but also a little bit about the back. A little bit of Assembly every now and then. It might be useful accidentally at some point in your life, because you did it, and even if not, it might ā like, youāll see patterns, because itās all the same things, with just more and more abstractions. But itās still the same things. Just seeing how itās done, and how things were solved, and how problems workedā¦ It might help you figure out the future when you rely on the past.
And itās unpopular ā I know, you all will not agree with me, itās unpopular. I also did not do that, and donāt allocate time or budget for that.
Hmmā¦ I do know what you mean. I actually have this book called, āBut how do we know?ā I got it off the Amazon website. And basically, it talks about computing from the very bare beginnings, like literally logic gates, and then how you make a bit out of two NAND gates, just showing how the logic worksā¦ And then building up everything in a computer like that. And it is amazing. But yeah, that was like, not something I need.
And actually, something else that occurred to me when you were saying that one is having like training or paying attention to things that you already think youāre good at. So not just new things that are new to you. Things that you already think, āYeah, Iāve got that nailed.ā You might be surprised; like, plenty of other things to learn. Yeah, I like that one. Weāll test that one, and see if thatās unpopular or not.
Even the way you did that is interesting, because you were already a couple of years a software developer, and then you look into gates, and so on, and that kind of helped you put this in place. When I started my degree, the first course I did was those logic gates, and everything was scary; calculus was scary. And then those gates - like, what? I donāt know, just let me pass that test and leave me alone. And if it could be the other way around, start with the programming courses, and then you go about semiconductors, and then you go about circuits, and then you speak about gates - it might have been more interesting, and actually it would make more sense. Maybe for me, at least.
I think thatās the path that people take accidentally. Like, those who do bootcamps, and then they gradually, eventually, over like 5-10 years become like systems engineers and are working on like the Kernel, or TLS, or something - they donāt know theyāre doing that, but thatās kind of what weāre doing. Theyāre looking back at the fundamentals. I agree itās unpopular. I donāt know anyone who does that, but I think itās genius, and we should.
We should open a university teaches that way.
I feel like thatās how my career has been. I just have gotten like down the stack further and furtherā¦
Thatās interesting, yeah.
Itās been fun. Iāve written like a few operating system kernels, like toy kernels. It was infuriating. Modern processors are terribleā¦ But mostly because theyāre so old. Like, āOh, maybe I have this code from the ā70s I might need to run on my Intel 12-gen chipā, or something. You never know. Itās like, āNo, Intel, I donāt need to run code from 1980 on my new processor. Thank you.ā
I like that too though, that people can start higher up in the stack, and can still be doing things without understanding everything. Because Iāve seen it, people held themselves back because they think āWell, I just donāt know how all of this stuff, and I need toāā They donāt know that they donāt need to know it necessarily, which is why I say you sometimes donāt need to know a lot of this stuff. Just sort of get on with it, and try thingsā¦ But it doesnāt work for everybody. I think thereās so many different styles and things that people appreciate, and things that workā¦ So I wouldnāt like to force it on everybody; as we like to say, it depends.
And Iām afraid - put down your goblets of red wine. Yes, it was definitely wine, yeahā¦ And put also away those sandwiches of miscellaneousā¦ No, there werenāt any sandwiches. No, letās just not do the sandwiches, but weāll do the wine but, and then keep the wine, because they think itās blood.
Okay, and thatās all the time we have on todayās Ghost Time. Thanks for joining us, everybody. See you next time, and stay spoopy!
Our transcripts are open source on GitHub. Improvements are welcome. š