“You cannot compromise on integration tests.” Kelsey Hightower expands on this idea to discuss real world testing of complicated systems.
Transcript for episode 43 of the Test & Code Podcast
This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.
Welcome to Test Encode, a podcast about software development, software testing, and Python.
I’m your host, Brian Hawkins, and in this episode we talk to Kelsey Hightower. Kelsey is an amazing public speaker. I first heard him speak during his 2017 PyCon keynote. I then got to meet him during a Portland Tech Crawl event later that year, and he mentioned that he had some views about testing that he’d like to discuss on the podcast. So here we are. We do discuss testing and testing big, hairy, complicated systems like distributed systems. But I also wanted to start with some questions to let you and I get to know Kelsey Hightower. So that’s where we start. It’s a wonderful interview, and I’m sure you’ll learn a lot.
But first, I’m very happy to say that this episode is sponsored by JetBrains and PyCharm. Of course, I had heard of PyCharm, but I hadn’t tried it until after I saw a Python 2017 presentation about how changes to Python Three Six allowed the Pythagorean team to change their debugger so that it runs almost as fast as not using a debugger. That’s incredible. I learned more about it and found out that the PyCharm team is very much focused on improving developers day to day work in so many ways.
My team has now switched to PyCharm, and here are a few of the features that save us time. The virtual environment support highlighting Pep eight violations, code completion, code coverage. The Get integration is incredible, and it’s just built in. You don’t have to turn it on or anything, it just works and it’s intuitive. Also, the visual diff and merge tools are top notch and huge time savers. A few of us, including me, are long time Vim users. The Vim emulation and extremely easy to modify keyboard shortcuts made the transition from Vim to PyCharm painless. And even some nonvim users like the keyboard shortcuts too. And of course, the main reason my team switched to PyCharm that the Pie test support in PyCharm is awesome, and it keeps getting better and better. There’s so much more. I don’t know which of these features or a long list of others are going to be the features that save you and your team time. But if you value your time, you owe it to yourself to try PyCharm. And guess what? The PyCharm team have set up a special promotion just for test and code listeners. If you use the link Testingcode PyCharm, you can try Pycharmprofessional for free for three months.
This offer is only good until September 1, so don’t forget and you know, going to Testinggo.com Pie PyCharm and trying it out shows. The PyCharm team that’s sponsoring this show is a good idea. So please give it a shot. And now let’s get to know Kelsey. Hi, Tower.
Actually, I’m Super excited to have you coming on the show just because I think you’re doing a lot of cool things. Awesome.
I appreciate it.
The first time I even knew you heard your name was one of the keynote sessions last year at PyCon.
Yeah, that was my first PyCon in a long time.
Yeah, I think it was last year.
Yes, it was.
Since I didn’t know who you were until I saw you, other people might not know who you are either. So who is Kelsey Hightower?
Oh, I’m just a regular guy working on infrastructure stuff. So my background started as a system administrator, so I took that route early in my career, various jobs, financial, web hosting, and then eventually product companies like Puppet Labs, Core OS, and now at Google. And kind of my job these days is there’s a little bit of building things and a lot of helping people understand what those things are and helping seed some of the vision of how those things should be used. And when that doesn’t make sense, go back to the drawing board and try to build things to fill those gaps.
What do you mean by help people how to use things? Are you internal to Google or are you helping Google customers? Yeah.
So I think it’s my first job in a product company, namely Puppet Labs. And I started at Puppet as a developer. So working on the open source configuration management tool known as Puppet, written in Ruby.
And during that time, that was my first introduction to this whole open source community, where the things you build are used in a much broader context than you’re paying customers.
Right.
You have a whole community of people that are not only using the things that you’re working on, but also contributing to them. So a lot of the times before you’re allowed to even touch the keyboard, you need to get community consensus on what the feature should be, what problems you’re solving, and in many cases may be reviewing someone else’s solution to the problem. So when I look at my work these days, it’s very similar. I work on a project mainly called Kubernetes, which is kind of focused on containers, but these days it’s probably much more than that because people are building new systems on top of Kubernetes. Maybe it’s a CI system, maybe it’s a network control plane like we see in Istio, which is a service mesh for connecting microservices either in a Kubernetes cluster or even across VMs. So when you start to have a community that big with people with different ideas, you have to listen to them and kind of takes one to be one, right?
It takes one to know one. So developers that are coming into our community, they’re looking to use Kubernetes as part of the development flow or process, or maybe they’re building things directly on top of it. So listening, being a user myself, you start to see where the gaps are. And for example, in Kubernetes, some people find it very difficult to kind of get started, especially like provisioning, let’s say a TLS certificate for their application.
So filling the gaps, in my case could be either building a tool that integrates things like let’s Encrypt with Kubernetes, or helping other people fill those gaps by learning the Kubernetes API or speaking at a conference or even flying off site to a Google customer and whiteboarding with their engineers until they get it.
That actually sounds kind of fun, me enjoying the role.
Of course, I think in many ways, most people building things have the role as well. They just really haven’t embraced it. For example, if you’re at a company working on products that they sell to their customers at some point in time, it could be advantageous for you to help out on, let’s say, closing a really large deal with the sales team. So your sales team is out there trying to convince the world that you should pay for the software that you’re building. And this is how you kind of keep your job. And if you like your job, this is kind of keeping that going. It takes paychecks to keep this going. And sometimes it’s helpful to jump on those sales calls and be very honest with the customer. Here’s what the product does, here’s what it doesn’t do.
And also, as a person building this thing, I’m listening to you to understand where the gaps are so I can make them better. So in that particular capacity or that particular role, you could consider yourself doing some sales engineering. Right. If you were to talk about the thing you’re building at a conference and you’re really passionate about it and saying, hey, I’m working on this product. Maybe here’s some of the foundational components, maybe here’s some of the principles from White papers. In that capacity, you could be seen as an advocate. So I think a lot of people inherently have these roles at different points and times of a project. And for me, I just kind of get to focus on that for full time.
So Puppet was one of your first jobs as a programmer?
Well, I would probably say as a full time developer. Before that, I worked in the financial services space. So this is the typical enterprise in some similarities, like the Phoenix project. Right. So you can’t move too fast, lots of enterprise cultural challenges. But there I wrote a lot of code for like, back end systems, batch jobs, those things, and also kind of let the infrastructure. So before we call the DevOps, you just had people who cared a lot about making the whole thing work. So regardless of your role was primarily apps or development, you did a bit of both and you did what was necessary to kind of move things forward.
Yeah. Now, when did speaking at conferences and stuff like that start.
So when I was in financial services, I remember really looking around the industry and saying, how could I actually be better? Right. So you buy all the books you learn, go buy a book on Python and a book on Python. And then eventually I decided, what are these meet ups all about? So I remember going to my very first meet up, and that was kind of some of the significance of being able to keep up with Python, especially a Python being chaired by Brandon Rhodes. So he was we were in Atlanta together at the same time. And my very first meetup that I’ve ever attended was a meetup at Georgia Tech University, and it was a Python meet up. So I was writing Python at the time at the financial services company, and I decided to go check out this meet up. And I remember watching a few people speak, and I was like, some of the speakers are great, but some were like, wow, if they could do it, I know I could do it. So I decided to put together my first meet up talk.
I think it was list comprehensions, Python versus Haskell. And I gave that talk, and it felt really natural. I felt really good at it, and I just incorporated that kind of thing into my routine. So whether it’s a meetup or a conference, my style remains the same. Right? Go and talk about something that I’m working on that I care about. I have a show don’t tell philosophy. So this is why I love to do the live demos, to show people like, look, this is how it works. There’s no magic. You can do it, too.
Let’s see, I talked at Python for the first time this last weekend, and that was a lot of fun.
Congratulations.
Thank you. I did not prepare enough. You brought up that you were watching people that were great at Lightning talks, but it also helped you to watch people that weren’t that great. Nothing against them, but it lowers the bar a little bit. And one of the best feedback I got from my talk was somebody came up to me right afterwards and said, one of the things I loved about your talk was at the end didn’t go so well.
And I realized you’re not on a pedestal above me. You’re just a guy that knows some stuff and you’re trying to teach it to us, the stuff that you know. But there’s nothing magical about what you’re doing. I could probably do this, so I’m glad I fumbled at the end so that I could inspire somebody else to try talking at Python.
You’re right. That is the point. The point isn’t for you to show mastery and be the person that everyone looks up to. The point, I think, for me personally, is to inspire someone. So some of the feedback that I love the most is that, Kelsey, I watched your presentation, and I decided not necessary to copy what you’re talking about, but I decided to do something better for my team or for myself.
And thanks for the inspiration. That’s the end game, right? We don’t have enough time to change everything in the world. But if you can inspire a few people to either think outside the box or have the courage to say, wow, if you were able to get on stage and do that, so can I.
Now what are you passionate about right now? Any things that you’re really itching to try to fix.
So as much as I talk about tech and sometimes I’ll also talk about other things on especially like my social media feed is I’m a minimalist. I’m a minimalist by force and by discipline. I’m also a vegetarian by discipline. And in those worlds, I think early on in my life, I decided to get debt free maybe 15 years ago now, maybe a little longer.
And when I got debt free, I decided I didn’t have to show anyone how much money I had. The car I drove didn’t matter as long as I liked it. And part of I liked it was figuring out who I was. Right. So you grow up your whole life being advertised to buy this, buy that, and you’re not quite sure why you like something. Do you like it just because you’ve seen the ad so many times? Do you like it because it’s the status symbol that it carries? Or do you like it because you generally like it? So I spent and I still do a lot of time making sure that I know who I am and I can kind of shift through the signal and the noise and just kind of live a life that way. So I guess I’m practicing minimalist, meaning there are things that I could buy, but I choose not to if I really don’t like it or just don’t need it. And for me, that’s pretty liberating, and I find it refreshing. So that way I can focus on the things I do care about, like my family or the work that I do. Right. So if I’m working on a particular thing, my mind is pretty clear where I can dive all the way in and kind of figure out that technology for myself. And hopefully that comes out in my presentation. So that’s what I’m passionate about is people figuring out who they are, not necessarily being trapped or sucked away into the hype. And then when people get to talk from the position of who they are and if they’re covering topics that are currently in the hype cycle, you get this new, refreshing set of opinions that’s not polluted by how people want them to think or what people expect them to say.
Wow.
I think I see that in your presentations, too. You seem to try to boil all of the decoration off of whatever you’re talking about and get down to the exact meat of really what it is that you’re trying to talk about.
Probably not a good phrase getting down to the meat of it to use for a vegetarian, so I apologize for that.
We’ll just consider the meat tofu roll with it.
Yeah. Well, you’re in a good city for vegetarianism and minimalism.
Yes, I am. It’s like I’m at home in this region.
So what brought you to Portland?
Just something new. I grew up in Long Beach, California, to the age of like 15.
Then I moved to Atlanta, where I spent the majority of my years, maybe up until mid 30s, and met my wife there and had a child there. All my family’s there, all of my wife’s family’s there. So Atlanta will always be home. But this region is really great for me in terms of the community base, the technology base, easy to get to the Valley, easy to get to Seattle. And it’s a place where I can come and just relax and kind of escape everything else.
How long were you in Atlanta?
Oh, I was in Atlanta for at least 15 years. Right. So from 15 to 30, 31.
Okay. I was only in Atlanta for like an hour as a layover.
It was hot.
Is Atlanta a hot, muggy place? Normally, yeah.
Not just hot, but hot and humid. So a lot of people don’t understand this humidity thing.
It’s just when your clothes stick to you. Right. Like, you just start sweating and it’s really the sticky feeling. But Atlanta is pretty nice in the fact that it has seasons. Right. A lot of people in Portland don’t know what that is. Right. In Portland, there’s like summer and not summer for the most part. And I think in Atlanta, one thing that’s nice is you can kind of get all the flavors of what the Earth is capable of.
Really? Okay. Does it snow there?
Yeah. So in Atlanta, sometimes you’ll get snow super cold. I mean, winter is winter. Right? You will have a coat, and then when it’s summer, of course, it’s very clear indication of summer, but the fall seasons and the spring, all of those things really highlight themselves. Like in Atlanta, when it’s springtime, you will see the world covered in pollen. Right. So it’s very clear and visible when the seasons change in Atlanta. Not that I miss all of that, but it’s a very different thing in Portland where if you’re not really paying attention, in Portland, it feels like there are days few of them would sun, and then most of the days don’t have very much sun. Right. So it’s kind of a weird mode to be in.
Yeah. I love Portland so much that I tell everybody it rains 300 days out of the year. You’d hate it.
Don’t come here.
Don’t come here.
No.
I think of the rain as a tax that we have to pay for all of the green.
That’s a good way to put it.
One of the things I ran into you at a we did like a tech crawl or something like that last year. I think it was. And you said you had some opinions on software testing. I was wondering if you could share any, if you have any.
Yeah, I know for some people this is like religion, right? There is a way you’re supposed to test. There are things that work. There are books and studies about what works. Right. So look, this is not for them. I know I’m not going to try to invalidate any of those.
I’m not trying to prove any of those. This is me thinking independently.
And I was going to talk about testing in the context of jobs. Right. So this is just not theory. This is just kind of like my experience. So I would guess my first introduction to testing for real was at the financial institution. Right. So I remember writing a set of libraries that were replacing COBOL for software that had to manipulate data on its way to the mainframe. So this is financial services. So when you mess it up, you mess up money. And when you mess up money, that’s bad for everybody.
So testing in that context is EndToEnd testing has to happen. Meaning.
I remember writing a pack decimal library. So this is like old school stuff, how to arrange bytes in a way that is more efficient for the mainframe memory layout and parsing old school formats like fixed length field Epstein.
And you need to test that stuff because you have to get it right. But it’s not enough to do unit testing. Right. So I remember writing a bunch of unit tests because, hey, that’s what you do. But then sometimes things will get through the mainframe or the database after being processed by the mainframe and you start to see issues that of course our hearts articulate in unit test. So at that point in time, I kind of like these unit tests are good for certain types of assurances, but not necessarily comfortable enough for me to sleep at night. Having unit test pass was never enough, especially in the financial sector. You need to test this stuff end to end. And sometimes end to end means you have to wait until 30 days to run a report to see if the fields are even valid. Right. Of course you can speed that stuff up. And that’s where you get to integration testing, where you deliberately take your code and run it all the way through the system in a way that doesn’t compromise what production would look like. And I found a lot of value in integration testing to the point where if you were going to compromise on testing, which I think a lot of people do, even though they won’t say it out loud. Yeah, some people will write all the unit tests in the world and brag about it. Hey, this project has test coverage, or I have seven to one test code I’m like, Congratulations, right? What are you accomplishing with that if it’s still broken?
So I think if you’re going to compromise somewhere, I don’t think you can compromise on integration testing. So again, I’m not saying integration tests are better than unit tests. I’m not saying you can skip writing unit tests. What I’m saying is you cannot compromise on integration testing. And there are cases where I’ve chosen to skip the unit test boilerplate in favor of getting the integration test done first. Therefore, if I can’t get back to some unit of testing, I didn’t fail the end to end flow. And that served me well over my career. Especially now, especially when I’m building prototypes where I find more value in end to end testing, which usually contribute to documentation what the flag should look like, what they should feel like versus just a small unit test. So that’s been kind of my philosophy around testing in general. Just make sure you’re testing something that helps you sleep well at night and the people who have to support it.
In your world or your definitions. Can you tell me what the difference again is between system test and integration test?
So to me, like an integration test, let’s think about Kubernetes. For example, if you’re going to do an integration test for Kubernetes, you may want to set up an environment that has the latest bits of code that you’re working on and build all the binaries in what you consider a complete system. Right? So if you want to do in integration testing with Kubernetes, then you’re going to have to have a real etcd. Back end that represents what most customers would install, provision that whole stack, and then think about what the expected behavior is from the outside. So some people think about this as like black box testing. I’m going to create a container, I expect it to run like this, and I’m going to have to use the front door into the entire system. In the case of Kubernetes, that would be like the API server, not necessarily Docker, not necessarily some of the other back end components, but I’m going to go through the front door and then I’m going to observe all the output. So maybe I get the logs from the container, maybe I get the logs from some of the runtimes, or maybe some of the metrics from the Kubernetes API. And the goal is, does the system work as expected when given a set of inputs, containers or Kubernetes manifest? And do I get the desired results? And that allows me to test all the components, the DNS server that’s hitting away the scheduler, all these other components that you don’t typically talk about. Now when I talk about unit testing, that’s where you say, hey, I’m working on the API server and I just added or modified an API endpoint. And what you typically do is, at least in my case, what I used to do is you typically make the test work like you change this bit of code, you’ve modified the field or two, and then you go adjust the test until they work.
That’s what most people do, whether they’ll say it out loud or not, or say you’re not supposed to do it that way. That’s what most people do. And once it’s all green, they check it in. And then as bugs come up, if you’re disciplined, you’ll write a new test to replicate the bug, and then you go and fix the code until that test no longer breaks. But I know what it’s like in real life. If another test breaks, you will massage it until it works.
I’m still a little confused.
The integration test is on a system that replicates the real world system, but like at a local scale or something.
Honestly, it could be the real world system itself. Okay, so if I know that Kubernetes is going to be deployed into, let’s say, Google cloud platform, that I’m going to install it on some VMs, I’m going to put Etsyd there. Because guess what? The networking matters, the firewall rules matter.
All of those things that we don’t think about matter. So if you change the API server in a weird way and now you’re no longer listening on Port 6443, by default, you did something, now it’s on 80, 80 it breaks. And that’s something typically that you may not catch in a unit test when you’re thinking about server configuration.
Yeah, testing at that level, it helps you with trying to find out which parts are hard. Are any of the workflows just weird or any flags that just don’t make sense for what people are really using it for? And which documentation holes are there? Are there some white papers or tutorial docs that need to be written to make this more clear?
And that’s a benefit from doing that level of testing that you don’t get from unit tests.
Exactly. And I think that’s what makes a complete engineer. Right. You’re engineering a complete solution. And to me these days, when I write code, I like to start with like, how would I actually call this? What did the flags feel like? What are their names? Do they make sense? And then I like to write these into tutorials where if I were starting from scratch, what binary am I downloading? What’s the name of that binary? If I were to invoke it, what does the help output look like? Is it helpful? Right. And then what steps does it take to do the actual tasks that I want people to do? And once I write it all out, I was like, wow, this code needs to change. There’s no way I should have a config file slurping. Xml file when YAML seems much easier for him as the rock. So I think if you want to be a complete engineer, you have to think about the entire end to end flow from a new user’s perspective.
Yeah. And I love that idea of getting it down to not just writing the test, but writing a tutorial on trying to teach somebody to do that. And even if you never publish it, this is terrible to describe.
This is embarrassing. We can’t publish this. We need to fix the API. I like it.
Yeah. I think that’s what people want to do. So all the hats that we think or sometimes we may take for granted. The documentation team, I love them, like the most in the world. The QA teams, all these disciplines, I think we need them. But I also think as a developer, you should try to learn as many of those disciplines as possible to make you a much real rounded person. So when you deliver, check in that code, check it in with docs, check it in with some UX improvements, check it in with all those things that you expect the other experts to find. And maybe you make the job a little bit easier or you allow them to be truly experts and really focus on the things that aren’t so obvious.
I’m a top down system level test kind of person because I’m not against unit tests. But if you have to make a trade off, I go for tests that reflect the user interaction.
Because you know what? Every company has them, right? You have them when you go to that deployment and everyone crossing their fingers and they run that smoke test script just to make sure that it actually works. This time they’re there, they’re just not really intentional. So they’re brittle. All we’re saying is let’s just formalize that stuff and make it a part of the engineering culture. Then I think you start to get the values from having those things in the first place.
Definitely. And for a while I just didn’t like the entire idea of people just doing testing or just doing QA because I thought that should all be engineering roles.
But the more people I meet, there are definitely some developers that can do like an end to end test. That’s just the happy path stuff. But there is a mindset of somebody that’s able to come up with corner cases and really stress the system.
That’s a skill in itself, and those are valuable as well.
Also focus, right. We always underestimate focus. And I think if you’re using these roles to define focus areas, that’s where the power comes from. So if you took an engineer and say, hey, I know you can do the engineering work and some of the testing work, but what if I told you you can just focus on the testing work? And typically we associate focus with titles, but it’s that focus that zero laser focus on. This is my job. And then you start to go beyond the basics.
Right.
And I think you’re alluding to that. Meaning we’re going to test the Sys calls coming out of this app to see if those Sys calls are appropriate from a security perspective. And I think that’s what we need more of in the industry is people helping out. So that way the baseline is covered and then the people with focus and expertise can really leverage that stuff, not to write the basic stuff.
And then also taking a look at error messages. And when things go wrong, what does it look like to the user? And is it possible for them to know how to fix it? What quote that the best user documentation is a great error message.
I’m filling that. And actually I’ve seen some great error messages where there’s a link to an FAQ like, hey, if you’re seeing this, click here, copy and paste it and put it in your browser and it takes you to a common suggestion to fix it.
That’s amazing.
That’s great because you can’t put like five pages of tutorial in a little help dialogue.
Oh, you can. People call them stack traces.
They tell you about the whole world in the log message. Like, why are you telling me about the number of threads right now? I just want to know why you can’t open this file. And I think that’s where you start to come out with this old world where people don’t understand what they’re communicating via their errors. There’s like error log and whatever happens, happens.
And I’m only looking at the first two inches of the error.
Anyway, I’m glad you measured it that way because I think that’s how humans think. Right? If you scroll up and you see more than an inch or two logs, you’re like, you know what? That’s it. This person obviously doesn’t know where I should be looking because after about an inch or so, it’s just a lot of land beyond that.
I hope one day that all progresses towards like, you know, when you get in your car and the gas light comes on or some other light comes on that says, hey, here’s exactly what’s wrong. And I’m pretty sure there’s tons of data being generated to make that light go off. But almost to the point where you can point someone in the right direction, it’s not perfect. But I wish we just had a little more of these indicators. Maybe logging meets UX or something like that.
It’s interesting the more I talk to people that work with network systems, how we’ve got multiple computers on multiple operating systems talking with each other over transmission lines that have latency and you can’t predict what’s going to happen and how people are going to use it. So sometimes it isn’t like exactly what’s wrong, but exactly what was the user trying to do when things went awry and they might not even know because it’s an automated system or something?
Well, the patterns that I like now that are arising is to assume that it’s always broken.
Like, you have a distributed system, you should just be under the assumption that it’s always broken. Some MTU setting isn’t right.
Some amount of latency that shouldn’t be there, is there there is some threat that’s stuck. You just need to assume that something is broken and what that has manifested to is this chaos engineering community. Right. Or some people would say testing in production. But the idea is that if you assume that it’s always broken injecting a certain level of brokenness on purpose, and just observing the system always helps you really build resilient software where you say, hey, team, we’re just going to make certain services return 403 randomly, and we don’t think the system should be paralyzed or degraded too far below this line in order for us to consider it resilient. And you know what? We’re going to also throw in maybe some other errors that are random, like ten second delays here and there just to see how the system behaves. If you get into a culture of a very hostile environment, then you have no choice but to just assume the worst in all of your interactions between services and your code starts to reflect that. So if that’s just what you’re doing by standard, then you just have a reliable system because you just assume that it isn’t.
The Netflix team has been very vocal about that kind of testing.
I assume they’re not the only people doing things like that. There’s people all over doing this kind of testing.
Yeah. Cloud providers, anyone that’s responsible for these large systems, that on the happy path, they’re great. But when they break, it’s just like unsolved murder mystery. And I think most people are just unhappy trying to respond to those in real time. Like, you see, people have an outage. Like if a cloud provider has an outage in a certain region, the entire world lights up and says, oh, my God, region X-Y-Z is down. What are we going to do? And imagine the pressure on the team trying to resolve that issue. So without constant practice, it will be a nightmare to have to face that challenge when it pops up.
Yeah. And also one of the neat things about that is if you know exactly where the problem is because you’re the one that put it there, then you can like we’re talking about good error messages. You can hopefully build in systems that will point you to the right direction instead of pointing you completely in the wrong direction.
Right?
Yeah. In an entire service, like, say, Netflix or Azure or something, you can’t just say, well, there’s like 5% of the people are having problems. Let’s just turn it off and turn it back on again.
No, that doesn’t work.
You can’t reboot the cloud, folks.
There’s no single button. Right. These systems are incredibly complex.
Yeah, that’s not going to work.
Hey, one of the things I realize I forgot to ask you about is you wrote a book on Kubernetes, didn’t you?
Yeah. So I started a book called Kubernetes the Hard Way and I was joined by two co authors, Brendan Burns and. Oh, wow. My name is Joe Beta. So Joe Beta and Brendan Burns were part of two of the original founders. They aren’t the only ones, but they were at Google when Kubernetes was created, and they’re largely responsible for a lot of its initial design. And we put out this book called Kubernetes Up and Running. And if you notice the book, it follows my typical style that you see on GitHub, which is lots of code examples in their full length. And the idea is that you would like either copy and paste or type the commands out and really see what the output should look like. And I think a lot of people learn, well that way with the whole let me run it myself and observe the output and observe the whole flow.
Yeah.
Well, how was that experience? Would you write another book?
I would write another book and stop at 100 pages, because when I started writing Kubernetes Up and running, I didn’t have any co authors. And I maybe gotten to about 120 pages. I think the final book is almost 200 pages. And Brendan Burns, especially Brendan Burns, he added a lot of good context. So if I were to write a book longer than 100 pages, I think having co authors is good because you can get fatigue, like, writing anything is hard. Writing a book is almost impossible, or it feels that way. So I think in the future, I’m thinking about writing another book called Kubernetes The Hard Way, based off of the popular GitHub repository that I have. I just want to keep it at a solid 100 pages, where you get rid of the crust, you focus on a particular set of subjects, and then you force yourself to have to go refactor until everything is concise and what it needs to be and then just lock it down at 100 pages. It’s kind of like giving a keynote where you only get 20 minutes. Right? You got to get all the right bits in there because you don’t get 45 minutes to say the same thing. And if you’re good at it, I think it actually turns out to be a better product.
Okay. I think that’s a great idea.
I’d like to see a lot more smaller books. I’m tired of seeing textbooks get bigger and bigger.
Yeah. Because then it’s like some content is obviously filler. Right. You’re like, I don’t need this filler right now. I don’t need you to print the standard library in the back. Right. There’s a time and place for that. But I think what you really want is almost some opinions from the author. Like, do not just copy and paste from a website. Like, give me your insight, hopefully through experience that will then save me maybe a year or two just because I read your book. I think that’s what people are looking for from textbooks these days, given that we have the Internet.
Yeah. So after the book I wrote on Pipest, I sent out the first four chapters to a whole bunch of tech collaborators.
And some of the feedback I got was, don’t tell me, like, the three ways I could do it.
Maybe you can list those, but I really want to tell you to tell me.
What do you think I should do? Tell me the right way. According to you, it’s your book.
I want to know what you think. So, yeah.
The same holds true for conference talks. If you go up and you just state the facts, even if you do a good job, people probably won’t remember that too much. But if you go out and say, Look, I know that there’s all these ways of doing it. Here’s how I do it, and here’s why. And there’s just so much engagement you get whether people agree or disagree with you. And that what makes you a memorable speaker, is because people got to know a little bit about you and got your opinion on some subjects they care about.
Yeah. Nice. That’s good advice, man. It’s so fun, to be honest with you.
I think we’re going to wrap it up. But is there any final message or call to action you want to give people?
I guess if we had a call to action, I would just ask people to really focus on the principles of things that they’re doing. Right. So, for example, you can say, I’m a Python programmer, and then the foundation there, and the principles would be I’m a person who can write computer programs using specific syntax that we typically type into text address.
And if you focus on that principle, then when it comes time to learn a new language, you don’t start saying, well, it isn’t Python or it doesn’t work exactly like Python, but I can learn it because guess what? I’m going to type in some syntax into an editor, and it’s going to either build something or run on some VM, and it will work. Right. So then you can actually pick up languages and treat them like tools, the same as for everything else, like CICD, event driven programming. All of these things are rooted in some foundation or principles. But sometimes I think people get too caught up in a particular product or packaging of those ideas or principles. And in the worst cases, people don’t learn the principles. So they believe that without a particular product, they’re unable to leverage those particular principles even in their existing tools, which is, I think, a large miss by the industry. And it creates this sort of tribalism and versus battles that are just unhelpful, given the fact that most people would better themselves if they focus on the foundational bits.
Yeah, I think that’s great. That’s great advice.
Well, it was great talking to you, and thanks for coming on the show.
I appreciate you for having me.
Thanks for listening. And don’t forget you only have a short time to go to testincode PyCharm and get your extended three month trial of pycharmprofessional just for test and code listeners show notes are testandcode.com and transcripts are posted as they are completed.
Also thank you to Patreon supporters especially $5 level supporters. Steve Holden, Evan, Andrew Diedrich Jordan, rink, Steven Oates and Oliver best Walter help support the show and get an honor. Thank you like that by going to testing, cod.com and clicking donate now go out and test something.