The Changelog: Software Development, Open Source - The ONE thing every dev should know (Interview)

Episode Date: June 16, 2020

The incomparable Jessica Kerr drops by with a grab-bag of amazing topics. Understanding software systems, transferring knowledge between devs, building relationships, using VS Code _&_ Docker to code together, observability as a logical extension of TDD, and a whole lot more.

So I can see as a single developer of a team, it's easy to get in your particular, call it a vertical for lack of a better, like your little subsystem, right? And understand that intimately and know where every line of code is. I wouldn't say that's easy. That's not easy. That's really hard. It's easy only when you wrote it. I mean, if you've been on that team for 15 years, okay, but that's because you wrote a lot of those lines of code and you were there for their creation. But if you join a team, that kind of intimacy is incredibly hard to build.

This is why a developer coming into an existing project is not productive for four to six months, even if they know the language, even if they know the frameworks and the things that they put on the job description. You have to know that particular project and the people who are already there who think it's easy to get that knowledge, don't know how to explain it. I mean, like transferring that mental model of how the pieces fit together, where everything is, the hardest part of writing code. I mean, even before naming, you have to decide where to put that code. And that's hard. And it matters. So transferring that mental model is way harder than you think it is. Bandwidth for Changelog is provided by Fastly. Learn more at fastly.com.

We move fast and fix things here at Changelog because of Rollbar. Check them out at Rollbar.com. And we're hosted on Linode cloud servers. Head to Linode.com slash ChangeLog. Linode makes cloud computing simple, affordable, and accessible. Whether you're working on a personal project or managing your enterprise's infrastructure, Linode has the pricing, support, and scale you need to take your ideas to the next level. We trust Linode because they keep it fast and they keep it simple. Check them out at linode.com slash changelog.

All right, welcome back, everyone. This is the Change Local Podcast featuring the hackers, the leaders, and the innovators in the world of software. I'm Adam Stachowiak, Editor-in-Chief here at Changelog. On today's show, the incomparable Jessica Kerr drops by with a grab bag of amazing topics, understanding software systems, transferring knowledge between devs, building relationships, using VS Code and Docker to code together, observability as a logical extension of TDD, and so much more. Jessica, you're a software developer, you're a consultant, you're a somathicist.

I know what a software developer is. I know what a consultant is. What's a somathicist and why do you use it to describe yourself? A somathicist is an active participant in a somathacy. And a somathacy, I didn't coin this word. It is a learning system made of learning parts. Such as the economy, which is made of businesses,

but every business is responding to every other business and the buyers and people and the environments and stuff. Right, it's like a living thing almost. Yeah. Yeah, it's not like bounded like an organism is somebody said that ecosystems and economies are not organisms but organisms are ecosystems with a very strong boundary so how does that apply to software

then i'm assuming it does yeah so our teams are definitely synatheses because the team as a whole learns as each individual learns. And we're constantly learning from our interactions with each other. So like Akoff says, a system is not the sum of its parts. That would be an aggregate. Right, it's more than that. Yeah, yeah, it's a product of its relationships. That's what we call a system. But as Samathasi points out, that each part is a product of all our past interactions.

And that's even more powerful. It's like future you is only the future you because of the current you and past you. Yeah, yeah, yeah yeah yeah yeah like everything we do has some side effect on the world and the next version of ourself just like in the actor model okay so isn't that a little bit overwhelming though is it overwhelming doesn't that put a certain amount of weight and gravity to every single thing you say and think um you know i i think really it puts a gravity on where we choose to put our attention. That in that sense, the control we have over future us is by where we choose to put our attention. So where are you putting your attention nowadays? Bunch of places.

See, it's May now and we've been in the quarantine for over two months and so you'd think we'd have more time but i find that is not the case it it turns out that when you like cook at home every night you have to wash dishes every night and do so much laundry yeah yeah and keep on good terms with your family i can't just ignore them and let the relationship deteriorate until we see each other again. So some of my attention has been on consciously maintaining the relationships within the house because we really need to continue to like each other. So far, so good. We like each other. Yeah. Well, that's a win. Also, now that I can't go to conferences and talk to a bunch of random people,

I have found it easier to focus on something more technical. Like, Opti and I started an app, and this has gotten us to try a new Rails 6 implementation in Heroku. And we're also learning a lot about Docker, especially in VS Code. And let's see, for work, I'm learning about Secure Code. Okay. Oh, and we implemented Honeycomb in our toy app the other day.

That was very exciting. Okay, so you're having some fun. Yeah. Sounds like it. We have piles of things. Yeah. I want to get into some of that VS Code Docker stuff because I'm completely ignorant of that domain. I mean, I'm not

ignorant of VS Code. I can use Docker a little bit, but I don't understand exactly how they fit together. But first, I don't want to bury the lead because as we were preparing for the show, one thing that you mentioned you want to talk about, and I feel like if I wait until the end to talk about it, it's like, come on people, give us what we want.

You teased up the single most important thing to know as a dev. Got to get that right off the top, don't we? Okay, yeah. The tricky bit is, it's different for every dev, or at least every team. Okay. But the single most important thing to understand is how your system works. Not just any system, not any abstract architecture or the specific system that you work on. What does it work and what impact does it have on the world and how does it accomplish that? Could you use a well-known example out there to be less abstract?

Oh, sure. Let's say like Uber, for example, a large system. I'm just thinking out loud. Yeah, I don't know how Uber's system works, but it also depends like where you are in Uber. So for instance, if your team works on, let's go with the piece I can see, the mobile app, then you need to understand from the outside in,

you need to understand generally how ride sharing works and what the point is. And then at a lower level, you need to understand the systems that your app interacts with specifically. And then you need to understand the internals of how your app works and how it deploys. So you need to have a good idea of who is interacting with your system and what they want to accomplish, but then intricate knowledge, at least part of it, that as a team you collectively need this knowledge. So as an individual you have some subset of it.

Right. You need to understand how iPhones work. Well, and if you're on the iPhone app enough and you need a good understanding of your programming language, but the most important thing is what your system is trying to accomplish the business domain and how the different pieces fit together. And I think a lot of the engineering principles and techniques and practices that we use. People talk a lot about, you have to use TDD. You have to use solid principles. Well, okay, solid starts with single responsibility.

First you have to understand what the responsibilities are. A lot of these are just driving us toward a deeper understanding of the system we work on. Making us think about it. So I can see as a single developer of a team, it's easy to get in your particular, call it a vertical for lack of better, your little subsystem, right? And understand that intimately and know where every line of code is. I wouldn't say that's easy. That's not easy. That's really hard. It's easy only when you wrote it. I mean, if you've been

on that team for 15 years, okay. But that's because you wrote a lot of those lines of code. And you were there for their creation. But if you join a team, that kind of intimacy is incredibly hard to build. This is why a developer coming into an existing project is not productive for four to six months. Even if they know the language. Even if they know the frameworks and the things that they put on the job description, you have to know that particular project. And the people who are already there who think it's easy to get that knowledge don't know how to explain it.

I mean, like transferring that mental model of how the pieces fit together, where everything is, the hardest part of writing code, I mean, even before naming, you have to decide where to put that code. And that's hard. And it matters. So transferring that mental model is way harder than you think it is. So what are some ways that people do it? I mean, you got documentation, you got inline comments, you've got tutorials. Yeah, yeah.

You think that helps. None of those help nearly as comments, you've got tutorials. Yeah, yeah. You think that helps? None of those help nearly as much as you think they do. Because when you write that documentation, it says exactly what you meant in your head to you. But the people coming in don't have the same context. Right. Yeah. Well, what do you do then? You sit them down and let me tell you a story 15 years ago. That helps actually, yes. Getting the history of the system is hugely helpful. You'd be surprised how much those old stories make the names in the code make sense, for instance. Right. And then you don't look at it and go like, God, who wrote this crap? You go,

oh, I see that previous circumstance that was a constraint that I heard about 10 years ago, then I know they've broken it now. And so I know it's okay to fix it now. It's like every bad decision in code was a good decision that just didn't age well, or it moved out of its, you know, it's obsolete now. Like, well, that had a reason, like there's a reason that line is there. It may look completely up to, it probably is obtuse to you. You have no idea why it's there. But the person who wrote it then in the time, that person now that's a different person um but but yeah it made sense to them it works yeah this idea story is pretty interesting because we just covered

this on brain science a future show coming out it's probably out by the time this podcast is out there it's called the power of story and it's more like the context right so think of uh your favorite movie where there's a villain right and they're doing all these bad things and you don't like them but then they give you some of the backstory about why they are the way they are and suddenly you're like i'm rooting for them it's because of context if you understand the scenarios of why backstory really matters is you understand the story of like why they made these choices, why in this context this solution made sense, why the system works in this way. Well, then you can sort of like unravel the whys and the hows of the choices and reimagine the future of it because of this context, this backstory. Yeah.

Yeah. You can reimagine a future that includes that person constructively. Yeah. Yeah. You can reimagine a future that includes that person constructively. Yeah. I like this idea of like a fireside chats or campfire chats or whatever around like, this is why our system is the way it is. That wouldn't make sense to me. Is that a thing? People do that often in teams. That's why going out for beer is often very helpful because it's over beers that you about how things are the way they are and how they used to be. And you tell the story of that incident that you still have scars from organizational scars. True.

The other thing that helps is pairing. Right. And I see both of these things like you pointed out when you hear the story, you can kind of put yourself in that character's place. It's through experience that we learn, and it's through shared experience that we converge our mental models and our vocabularies and our viewpoints of the world. Mm-hmm. I don't want to give too much of this show away, and it's not the point, but Dr. Mara Reese, my co-host on that show, she unpacked some research around how we learn differently, better essentially, through stories. The way it connects information, the way emotions are invoked, that emotion response, etc., transmits and keeps memory differently than in non-story form. So there's a neuroscience perspective to memory and learning when it comes to storytelling.

Yeah. It seems like putting a lot on ourselves or a lot on developers where it's like, it's hard enough to get the stinking computer to do the thing you want it to do, but then you also have to be like a storyteller and a beer drinker perhaps. Yeah, you have to be human. Yeah.

That's asking too much, Jessica. Come on. Because every human is a storyteller. You don't have to be human. Yeah. That's asking too much, Jessica. Come on. Because every human is a storyteller. You don't have to drink beer. You do have to drink some sort of liquid. That's also part of being human. And interacting with each other is part of being human, which, I mean, Lord knows we're feeling that these days. Yeah.

When your job is making the system and all you want to do is make the system and not have to be the everyday human, that's tough, though. Well, your system isn't just the software. That's the thing. Just like you need to understand not just the code, how the code works together, you need to understand how it deploys. Because that's the way you change it. And our job isn't writing code or designing code, it's designing change in the system. So we have to understand how the system changes, which includes the deploy system, but also includes every other human who's involved in the changing of it.

How can we achieve that? We do that naturally as people. I mean, when we talk to each other, it's just that we think that's not productive. But actually, you know, when I go into the office for eight hours, way back in the day when I got to go to an office and I've been remote for a while. You're feeling it. Well, yeah, because just this year, I decided I don't want to be remote anymore. And that didn't work out. It backfired on you. But sometimes when I'm working from home and after six hours, I'm just, I didn't actually work. I only worked six. Well, I never work more than six hours in the office.

That would be a lot, actually, of work to get done. But the thing is, those in-between times, we happen to usually talk to humans. Those micro moments. Yeah. What we don't realize is forming those relationships is our work. That builds a company. Avdi pointed out the other day, a company is a structure that's made of relationships with people that collectively forms a capability to do something. But those relationships matter. And that's how we transfer information well.

Like, we don't transfer information from documentation. The documentation that does work, trust me, professionals spend a ton of time tweaking that documentation and getting input from lots of people. And you are not going to spend that kind of time. It's way more time than writing the code. But the way we do transfer information is by trusting people. And we build that trust through those little tiny interactions of, I see that you are a human being. Is the relationship and the interaction process built up

of many parts, though? Does the documentation, obviously it plays a role because people read it. It can help. It can help. But it never conveys as much as you think it does. You can't tell the full story. So what are the building blocks of this that you advocate for? Is it like docs plus relationship or is it docs plus beer plus relationship? What are the, if you had to give a list of like, do these things right, you get these relationships and trust building to happen. Yeah. Start with the people. Start with talking to them.

And this is another thing that you get out of pairing. When you pair with someone, please chit chat for at least the first five minutes. Please, like y'all do with this podcast, break the ice. We are humans pairing together first because that's how everything else goes smoothly. And that makes the pairing session produce more than code. Because the output of every pairing

session is several things. There's a side effect on the world. And then there's the side effects on each of you, what you learned and who you become over the course of the activity. And then there's that relationship. And one thing I've started realizing is that every interaction with a person is about the relationship more than the content. And that lets me chill out and not get impatient in meetings or in chit chat and stuff because the content will be easy to transfer when the relationship is healthy it's like process versus outcome right the process is the relationship the outcome is whatever is formed because of the relationship yeah and the outcome that you see in the course of an hour is that whatever code you made, but you've also built

a foundation for every future pairing session. And pretty soon you work smoothly together and with the other people on the team. And that's when it gets good. When we try to resist that human connection, it gets hard. It's expensive. One trend that I've seen in our industry, which like low key disturbs me, and it actually, you're bringing it to mind when you talk about the knowledge transfer, which takes time, and the relationships, which take time, right? Is that so many software developers are moving between organizations at rapid paces. I was speaking with a young man the other day who had had, he's like, I can't even make it a year just speaking just experientially.

Oh, man. He's like, I've been 11 months at company A and I was at nine months at company B. And whether it's a better opportunity or layoffs or a merger or a startup that fails, like our industry has, I mean, called churn, we're moving organizations. This is one of the reasons why when Adam and I meet people. We have no idea how much that costs. Oh man, it has to be so inefficient because if you're learning a brand new system every 12 months and you're working with somebody who's been there three months before you have. Oh my gosh. They don't have that context. They're still getting it. So this seems like something that we would want to fix, but it's counter-cultural at this point to stay somewhere for very long.

Yeah. I mean, I can't say anything because, well, I've had two jobs where I worked there like four years. Oh, maybe three now. Almost three. But now I need to be a consultant because it gets too easy. Which part? What gets too easy? Your job does?

I mean, like, what's... I know it's too well. Exactly. I mean, when you do know the system really well, when you are that person that people can just come through with questions, and when you do something, you know exactly where to push it and what buttons to twiddle, I can do 15 minutes of work a day,

answer questions for a good chunk of the rest, and be more productive than anyone who's been there for two years or less. Because I'm bored! What about the flip side of that, of being extremely useful? So I do value that. The trick is there that most organizations do have ways of continuing to challenge yourself. And this is where a lot of people get into DevOps and infrastructure and architecture. You broaden

the scope of your influence and you can continue to have challenges. And this is where we need to automate ourselves out of a job. You know, if you do anything repeatedly, automate it. But then the other challenge is, it's correct at that level to spend most of your time helping other people get to your level. I read somewhere today on Twitter that senior developers probably commit a lot less feature code than junior developers.

Yeah, because they're influencing at a higher level. Right. Yeah. And also, I'm only going to get bored like that if I've been on the same team, working on the same piece of the system. So if you move to another team, or as Charity points out,

you can move back and forth between manager and developer. That's another thing you can do. But when you move to another piece of the system, you have a whole new thing to grasp. But all of your context and familiarity with the previous system and the deployment and the infrastructure is still relevant and useful. So if you've got a developer who's not been on one team for 15 years, but been on 10 teams in the same organization over 15 years, but been on 10 teams in the same organization over 15 years. Oh, that's a powerful

person. Also, we don't pay people for their experience at the particular company. And this is one of those, I mean, you used to have the thing where people would get paid for longevity. Yeah. seniority. Yeah, yeah. Now, if you replace seniority with deep understanding of the business and the software as it exists, that is incredibly valuable. But then you've got golden handcuffs because you can't leave, and then you stay even though you don't like it anymore, and then you've just defeated the purpose of having someone productive.

So that's a mess. It's a hard problem. I have a close friend who works at one of the largest credit card processing companies in the world and there are people there. There are a few of them. But you can probably count them on one hand. These people have been there for 30, 40 years and they are literally the only ones who know how certain aspects work.

They're priceless. They're absolutely priceless. Yes, they are. It doesn't matter if they know COBOL or not. You know, like, we need to teach people COBOL. It's like, well, you're not going to teach them this mainframe and the intricacies of millions and millions of lines of code. Yeah, it's not about COBOL.

It's about the system, right? Exactly. And it's like, when those people retire or die off, there's going to be serious problems. So that, to me, my definition of legacy code is code that's not alive in someone's head. So as soon as that person leaves, those millions of lines of code become complete legacy. They're just barely not at the moment. They're hanging on by a tiny thread. But one reason to replace code regularly is to have it continue to be alive in people's heads.

Because it's really, really hard if you weren't involved in writing it to get that familiarity with the system. If you use open source to develop applications as part of your day job, our friends at Tilev would like you to share your thoughts as part of their annual open source survey. They're looking to gather data around the use of open source and how it's changing in recessionary times, how much of the code inside your apps is open source. And they also want to know about the policies your organizations may or may not have in place to allow you to contribute to open source. These topics and more are being covered in this survey. And to take the survey, head to tdlft.co slash changelog. It should take about 10 minutes on average,

plus they'll ship you a Pay the Maintainer shirt for free, as thanks for sharing your thoughts. And as with any survey, the insights are only as good as the input, so the more people who care about open source that take this survey, the better the insights are going to be to inform the future of open source. Take the survey at tdlft.co slash changelog. Again, tdlft.co slash changelog. So you mentioned VS Code and Docker, observability, and some of the stuff you've been tinkering with. Tell us about it.

Okay. So VS Code is the IDE of the future and the present. Okay. And I'm sorry, but Microsoft is now the winner in development space. And they are now going to have a monopoly on development because they are the ones doing it right and making it free. That's my opinion. Well founded. Does that make you happy, sad, or indifferent? Oh, they're doing a good job. because they are the ones doing it right and making it free. That's my opinion. Well-founded. Does that make you happy, sad, or indifferent?

Oh, they're doing a good job. I agree. Yeah. I'm happy about it. I'm happy that they bought GitHub and NPM. That's sweet. But VS Code. You're happy they're doing VS Code, yeah.

Yeah, so what they've got, one of the major things that they've got really right in VS Code is the separation between project space and human space. So you've got the developer, and you like to type with your themes and your keyboard layout and your Vim or Emacs or ParEdit. But I wish they had ParEdit for TypeScript, but we don't yet. Somebody please make that. There's your preferences. And then there's what the project needs.

So if it's an Elixir project, you need the Elixir plugins and the formatter that is your standard for the project and whatever databases and stuff that you need for testing, your testing frameworks and things like that. So VS Code draws a line between them. And then it lets you containerize your development environment. And when we use Docker for development, don't think about production. Okay, everything that they tell you to do for your Docker containers in production, don't.

Use the nice fat Debian instance as a base, not the scrawny Alpine one that doesn't have curl, okay? This is news to me. Why would you do this? Because this is for your convenience. Yeah, yes, you want curl. You want everything. In fact, I always do apt-get update and I do not clean out the files. Oh, you're living on dangerous. Well, what am I using? Extra disk space on my computer. That's it. That's the only reason to clean out those files is to save people disk space. Now, if I'm going to push an image up to Docker Hub that other people are going to download, then yeah,

I'm going to clean out those excess files. But locally, the trade-offs are quite different between development and production. So I'm talking about a totally different Docker container than production. Okay. And then VS Code, when I configure it, which is like control shift P, add development container configuration, enter. If I already have a Docker file, it's going to use that. Or I can pick one, Node and Postgres, and it'll give me a Docker compose and set it up. And then I can play with the Docker file. I can pick one, Node and Postgres, and it'll give me a Docker Compose and set it up. And then I can play with the Docker file.

I can mess with it. Then when VS Code starts up the container, it installs VS Code Server on it. Not in the image, only in the container. Okay. And then, so you've got two copies of VS Code running. You've got one in the Docker container with all the project specific plugins installed. And that one's doing the file manipulation. And then it's talking to VS Code on your host, on your Windows PC or your Mac. And they can be completely different. And

everybody's fine because all your actual test commands and stuff are running in Linux on the Docker container. Same for everybody. But then on your host VS code, you have your themes and your keyboard layout or hotkeys and all of that customization that's about the interface with you. So they've separated the interface with the project and the code and the deployment. I mean, like you can install whatever development tools. Like I will at some point set up CI to do this, but right now I have the Heroku CLI installed in the Docker container, which I would still use for logs and stuff. So everything that's involved with that's specific to the project is there. Everything that's specific to you is in the host. And everyone's happy.

And then on top of that, it means that because VS Code has the server concept, you can connect multiple hosts to the same server. And this is where you get the remote pairing thing happening. Because that VS Code, you can connect two hosts to it. And that means wherever VS Code is running with your project, the VS Code server, and that could be in the cloud or it can be on one person's computer, the other person can connect their host, and you can both type and manipulate the same files because you're talking to the same server.

And that server can point each of you at where the other one is looking. So I can be in, like, just follow what Avdi is looking at mode for a while. And then Avdi's doing this thing, and I have a question about this other thing. And I can just, like, switch out of follow Avdi mode. That's not an action. It's just I open a file and I can go look at what I want until he says something that I have to go back and look at what he's doing. Or I can say, come look over here and he can click to follow me and see what I'm seeing.

So you're both editing the same files. When you say see, do you really mean CC? Like eyeball see or like keystrokes cursor see? Both. Both? Okay. Both? Okay. Interesting. Okay. How do you see without your eyeball?

Well, I mean like, you know, see what Obdi is seeing. So is it what he's looking at or where his cursor is at? You know, what's the metaphor? Oh, his inputs. Oh. Oh. Okay. Yeah.

It's where his cursor is at. It's the files he has open. Like this is really advanced. Eye manipulation and following. Eye tracking. Not quite that good yet. But what files he has open and the place in the files that he has open.

Is there a mode where you can just say track everything that person's doing and when he opens a new file it'll open it on your machine? Yeah. That's the follow mode. Follow mode you can just sit back and see what the other person opens and see what they type. Okay, so he's connected to the VS Code server. And then you can randomly hit a key and bother them.

You just hold the delete button down as he types. That would work, yeah. So he's connected to the VS Code server in the Docker container, and you're connected to it in the container? Is that right? Yes. So VS Code server is running in the container, which could be on my computer or on the cloud. Okay.

And then both of our VS Code clients on the host are connected to that same server. Okay. So when you kick off like a test run, will it run it in the container? Yes. Will Obdi know that those tests are running? Can you clash that? How does that work? It will run in the container. So if he's following me, he'll see the terminal open and he'll see me run it.

Now for security, if that container is on my box, then by default, he doesn't have write access into it. I have to give him permission to type in my terminal. I think you can do this without containers locally, but don't. Just do it in the container. But then you can both have permission to type in the terminal and run tests or whatever. And you can see what the other one is doing. So we have a Docker container, a dev Docker container set up for changelog.com. It's a Linux app, it's open source, etc. I never use it because I just feel like

there's an unnecessary layer in between me and what I'm trying to work on when I could just have, we also can set it up directly on your machine or you can use a Docker container. So do you find that's actually a problem in practice, or am I just being curmudgeon? In open source, it's definitely a thing. If you want someone to contribute to your project,

or someone wants to try it, they don't need to make their computer look like yours. And the Docker container's huge. No, absolutely, which is why we have a Docker file for that. We want people to be able to use it. How do you test it? Mix test. No, the, which is why we have a Docker file for that. We want people to be able to use it. How do you test it? Mix test. No, the Docker container.

Somebody else does that. Ah, okay. Well, you wait until you get a bug report on it. That's probably how. Yeah, exactly. That's okay. So you said in your circumstance, you have the Heroku CLI and it's inside the container.

So are you basically running those commands from your terminal inside the container? Yeah, I have a principle. No, I'm not installing that on my computer. I have Docker on my computer and I will install that in a container and that is it. I mean, where that is specific to anyone's project.

Yeah, I like that principle. You have one project that you're like in tune with. Right. And the setup predates the Docker container. Yeah. Yeah. And you're already there when your laptop is stolen. You'll wish you'll probably use the container for a while because it'll be so much faster to get up and running. Yeah. Yeah. For sure. But in the meantime you like have this symbiosis with that project. That's right.

I'm holding on to the past. It's like IntelliJ also is really great if you use it every day for the same project. Because you get it set up and you get it tweaked and the endless updates don't seem endless to you because they're only once every other time you open it, not every time. It's not really that often. It's just that when you don't use it that often, it is every time. Right. It feels like it. Yeah. Yeah. So you get in that kind of synergy and it's okay that your personal laptop, which is your umwelt, your environment that you have set up that is meaningful to you. It's an extension of my body at this point. Yes, exactly.

Exactly. And because this one project is what you care about, it's fine for you to customize the extension of your body to work with that project. But don't ask anyone else to do that, to work on your project. No, I wouldn't do that. Yeah. I'm actually asking you to convince me that my symbiosis isn't even worth it. I should ditch this and use Docker all the time.

And some of these VS Code things are very interesting in that way. But I'm not sure if I'm quite there yet. So what are some other stuff, the advantages of having this VS Code server talking to the VS Code server inside the container? The VS Code client on your host. The client, yes, excuse me. And the VS VS code server inside the container. The VS code client on your host. The client, yes, excuse me. And the VS code server in the Docker container. Well, see, if it's only about you, then having your own computer set up is probably the best

until you lose your computer and then it sucks. But if you want other people to be able to work at it or pair with you, then isolating that into a defined environment, because right now you don't know what all you have installed on your computer that is helping you right now. You don't know that until you lose your computer, which I have done like three times in the last four years, at least. I think more.

So I've gotten sensitive to this. I can tell you, speaking of experience, Adam, have you ever lost a computer that was all customized and set up for you? No, I haven't. We don't go out much. Well, I have a laptop. It mobiles inside my own home. It doesn't mobile outside my home.

It's not mobile in that sense. It's movable. It's more cordless than mobile. Yeah, cordless. I like that analogy. Well, what I'm seeing here in particular with this is that for us in particular, you know, if we had like a dev with me kind of thing, Jared, where this Docker container was used by you constantly and you know how to use it, it would be easy for us to on-ramp others or just form relationships with them directly, but then also have some documentation and maybe some beers to get folks who are interested in this Elixir app that is marketed by Jose and others. This is a good app to look at for, you know, to learn the practices of Elixir and Phoenix, for example. For one, that's a great thing.

But then if you wanted to pair with somebody, which is something we've been doing before. We've thought about that, doing that on Twitch or live coding sessions. This enables that a lot easier. Yeah, I'm thinking about this specifically for that. So one of my ideas for a YouTube series called Code Review, just testing that term right there, is where I'm joined by an expert in a system. Maybe it's like somebody who works on

Node. And I don't know anything about Node's code base, but it's open source. So I have the code base open, they have the code base open. They're going to tell me the story. Whatever story they happen to know. And I'm the neophyte, so I don't know anything. But I know what some code looks like, so I can say, you know, where does it all start?

And, you know, why is this doing that? And they know the answers, presumably. Yeah, but you have to draw those out of them because what is obvious to them is not obvious to you. Exactly. And so therein lies the rub. That's that challenge of too much knowledge. Yeah. So maybe it's a good idea, maybe it's a bad idea,

but this VS Code setup sounds really awesome for recording video or remote pairing sessions, basically. Not on my Surface Pro, but on this ThinkPad, yes. Do not use a Surface Pro for podcasting. And you could follow them, too like you can be hands-free following like you've mentioned in you know follow the audio mode you can just watch them open files explain the path of where the class is and where it ties to the module for example whatever it might be you can really go deep with them and follow them through their own code base

and hear the story so kind of it layers in the storytelling aspect. Yeah, that'd be sweet. How many people can connect to this thing? Because we could just ditch the video indirection and just have a whole bunch of people following you directly. Just the code. Just a VS Code. Yeah. Is there like a limit? I bet. I mean, it probably doesn't scale very well.

It's a little beta. I mean, it doesn't work perfectly yet with two. Sometimes it just works. So by all means, try it. If you have a Discord server where you talk about this stuff, you can stream it and also give them the link so they can try to join. But if not, just watch the stream. Right. How do you, is it just a URL? You just like here, point your VS code at this? How does it work on a logistic level? Yeah, you pass a link. That's so cool. Well, worst case, I mean, Microsoft is committed to this, this idea of VS code. Obviously they've won developers, as you said, Jessica. So, I mean,

I think that even if it's not perfect right now, they need people using the feature in these ways to hit the bottlenecks and the bugs and the gotchas to give that to the team and feedback and make it better. Yeah. One of the things you get if you do your work in a Docker container, then you know that Docker container works. You know that every tool that you need installed is installed and it's installed in a way that's documented in the Docker file. And I mean, randomly, sometimes you'll rebuild the container or VS Code will rebuild it for you. And everything that you installed but didn't put in the Dockerfile will be gone. And you'll notice and you'll put it

in the Dockerfile. So it pushes you to document your dependencies. I'm now remembering why I don't use Dockerfile besides curmudgeon which is also there but actually Docker for Mac is super slow for some reason and so now I'm going to have to switch OS's if I want to get this going Docker desktop for Mac used to be the best but I think now it's better on Windows it's not perfect one thing that we rely on in our programs

that we just keep assuming the file system is solid. File system is not solid. In a Docker container running Linux on Windows, not solid. And the answer is not restart your container. It's not restart Docker. It's restart Windows. We're back to that. Great.

We're back to restarting Windows. I keep forgetting and get really frustrated but npm install man with the number of files when it's downloading like thousands and thousands of files into that directory oh that can kill it that is no way it's not perfect and when you have that that extension of yourself set up that is more efficient. It is faster. And for your own work, I mean, I'm not going to tell you you ought to use Docker. Anyone else ought to. And you ought to once in a while just so you make sure it still works. As the world at large is spending even more time online,

search will become a more critical lever for engaging your users and your customers. And some good news out there for those fighting the fight against COVID-19 and the coronavirus. Our partners, Algolia, have offered their ProPlan for free. If you are a developer or a team working on a COVID-19 related not-for-profit website or app, you can get Algolia's ProPlan totally free. Check for a link in the show notes or head to algolia.com. Do you want to talk about DevOps and Honeycomb or anything like that? Oh, okay.

So, Adam, you were talking earlier about brains and brain science. Yeah. And some of the stuff I've been reading lately about ecological and inactive something is as people, as animals, we learn about the world in order to act. Acting and learning are entwined. We constantly have to do something, and this is like directly related to our learning. We have to learn in order to choose useful actions, both as animals

and as people. And I've noticed for years that in code, learning and changing are like the same thing. Like if you do want to learn a code base, you need to like refactor it or tweak something and see that change the output or add a printf to see if that's really what it is. We need to see change in order to learn. We need to do something and then see the world around us. And TDD is like that. TDD gives you that buzz because you do something, you see a change. You write a test, you see something red.

Yeah. You implement a test, you see something green. You. You implement a test, you see something green. You refactor it, you can live with the code. And then you write another test and you see something red. In reality, most of us skip the refactor step. Well, that's because it was fine the first time because it is in our head. Come back the next day and then you'll want to refactor it. No doubt. then you'll want to refactor it. You know, now that we have continuous delivery and now that we have systems composed of a zillion different services with actual useful documentation that

people spent more time on than they did writing the code, the level of reuse is the company. That's a thing. Anyway, now that we have things like Heroku and Netlify that we can push our stuff into the world immediately, I'm not satisfied with red to green anymore. I constantly want to see how my actions affect the world. So the first thing I do, so Avdi and I have this toy app, which whenever we sit down to work on it, and it's been a week because it's always been a week because it's the weekend. The first thing I do is push some change to production to show that I can still change the world in this way. And then last weekend, we haven't implemented any real features yet. It's pretty hello world at this point. But darn it, we have system tests running.

There you go. And darn it, I integrated Honeycomb for observability. And I mean, we haven't done anything in Honeycomb yet. All I did was install their gem, tweak their configuration so that I wasn't hard coding my API key and pushing it to GitHub. And that's it. And then now when I deploy the site, I can go and look at the graphs in Honeycomb. And whenever I hit the site, I can see something change in the world. I see that graph bump and I can see, then I can trace down too and see what made it take so long, which it doesn't do anything yet. So it doesn't take long. Well, unless Honeycomb had to boot its, or not Honeycomb, Heroku had to boot its Dynamo,

which case it takes forever. That's okay. Right. First request. Yeah, but I'm probably not seeing that yet because I don't think it, anyway, I can see an effect on the world even just by clicking on my site now. And I can see whether other people are clicking on my site. So now when my app starts being useful someday,

I'll be able to see that and look at it. And that to me is like – it's what TDD wants to be when it grows up. I like the way that you put that. It's like real world. Well, it's testing in production. It sure is. Yeah. Yeah.

And we need testing at all these layers. We need testing both locally and in CI, which is consistent, and in production. You're still not quitting all the way to the end result necessarily, right? Like I think a lot of the move fast and break things attitude, even if you're testing and having your observability in production, is like not seeing the logical or sometimes illogical conclusion of your changes as they manifest in the real world. Yeah, because I mean you can meet requirements. logical conclusion of your changes as they manifest in the real world. Yeah.

Because I mean, you can meet requirements. You can make it do what they told you to make it do. Right. And that's still be totally useless and bad. Right. So if you don't test in production, you're not testing the system in its environment. You're not testing whether the system works. You're only testing whether it does what they told you to make it do.

Right. Yeah. And if that's all you get paid for and all you care about is getting paid, then you're fine. But I think all of us care about more than getting paid. Yeah. In this Zoom anyway.

And one or two listeners for sure. That was a huge qualifier. that was the biggest qualifier i've ever seen she went from everybody to in this zoom from millions of people to three well okay at least extend it to our listening audience if all you care about is getting paid you're not my audience there you go there you go what you're doing though is you're learning about doing though right that's that's what's happening in this scenario to change the world like that. And you need that feedback. That feedback is part of the learning process. Yeah. And you know what? This is another reason that stories are so powerful because as humans,

we were built to learn in order to do, in order to learn, in order to do. Naturally, we only learn with action, but here's the thing. So looking at it that way, it makes sense that we only learn from our own experiences and we're terrible at learning from anyone else's. But the thing is that we can simulate the doing in our brain. When we hear a story, we're simulating the doing in our brain. It's like the mirror neurons thing. Yeah. Where you watch someone do a physical motion and your brain fires in the way

that would make you do that physical motion even if you're not moving. So we have that experience and take those actions with them and see the results with them. Yeah. And so stories are so important that way. The mirror neurons is really interesting because back to VS Code and Docker and watching, you know, watch Av you watch, you get the same, your brain would light up the same way Avdi's did as he's writing it

because of the, you're seeing it and you can see it and you can do it. Hopefully he'll be talking through the why. Right, right, exactly. And the key combo he just pressed. It's really interesting how all that plays out. These mirror neurons, they're a key component to empathy, a key component to compassion obviously but uh you can watch somebody do something and get the same brain response as if you did it yourself do animals have those uh because i don't know

i don't know because this well they certainly don't have it in response to language because they don't have language the way we do well i think they do i don't know how to describe it but uh that's a good that's a good question though i'm pretty sure though you can see monkeys do these things while i do tests on rats and monkeys and things like that mimicry because they simulate a lot of similar and dolphins even too yeah yeah monkeys would monkeys would yeah steep yeah so this could be like a really subtle form of mind control, right? Like the person is informing your mind and firing. Someone's firing mirror neurons in your mind while you're watching them code. It's kind of deep.

We conform to what the people around us are doing. And this gets back to if you want to change yourself, think about where you put your attention. Absolutely. Because you're going to mimic what you want to change yourself, think about where you put your attention. Absolutely. Because you're going to mimic what you watch. Yeah. Your awareness, attention is absolutely key. Where you place your thoughts, the framework in which you have your thoughts, it all begins with awareness and your attention. Agreed. The idea though, Jared, you mentioned mind control

is really interesting because MKUltra is a real thing. It's quite possible that we're in a simulation and this is all mind control. You're just saying that because you want to go watch SpaceX and you're thinking about Elon Musk. Yes, yes. If it's a simulation, they have something way better than this ThinkPad.

A little backstory. That had some crashing right here. Yeah, they probably learned that through osmosis. On the Surface Pro, the ThinkPad's been great. Yeah. And if you want to hear more from me and more thinking thoughts, newsletter.jessatron.com.

For sure. There it is. Links in the notes. Yeah. Cool. If you are familiar with Jessica's voice, you probably heard her on Arrested DevOps and Greater Than Code. Great podcast. If you haven't listened to those yet, give them a listen.

We really appreciate you coming on the show. Thank you for inviting me. All right. Jessica Kerr dropping some wisdom for us. If you have any comments and want to share your thoughts, we encourage you to do so. ChangeLog.com slash 398. Open up your show notes and click discuss on ChangeLog news. We want to hear from you.

And coming up next week, we have Ryan Singer coming back on the show talking about ShapeUp again with us. How is ShapeUp shaping up? That's the question. We encourage you to check that out before the show if you want to. Basecamp.com slash ShapeUp. And if you want to help us to reach more people, do us a favor. Share this show with a friend. Put it on Twitter. Put it on Facebook.

Put it on your blog. Put it in your list of podcasts. Whatever works. We love that. Word of mouth is by far the best way for podcasts to be discovered. And, of course, thank you to our partners who get it, Linode, Fastly, and Rollbar. Also, thanks to Breakmaster Cylinder for making all of our beats. And we have a master feed of all of our shows, so you can get all of them in one single feed.

Search for ChangeLog Master in your favorite podcast app and subscribe, or head to changelog.com slash master. Thanks for tuning in. We'll see you next week.