Learn back-end development - https://boot.dev
Listen on your favorite podcast player: https://www.backendbanter.com
Jonathan on Linkedin: https://www.linkedin.com/in/jhallio/
Cup o Go Podcast: https://cupogo.dev/
Boldly Go YouTube: https://www.youtube.com/@boldlygo
What is Backend Banter?
The only podcast dedicated to backend development, technologies, and careers. Lane Wagner, the founder of Boot.dev, interviews successful backend engineers to get their takes on various trends, technologies, and career tips for new backend developers. Golang, Python, JavaScript, and Rust are the programming languages most commonly discussed, but speakers dabble in all sorts.
**Jonathan:** [00:00:00] They talk about this dichotomy between.
Software developers whose sort of mission is to get new features in front of customers as quick as possible versus these sort of imagined gray-haired, grumpy old ops guys who like sit there with their hands across their chest.
They're like, no, you can't do that. You can't push that feature. It's gonna break my servers, it's gonna bring down the internet, whatever.
The developers are all excited. They're maybe the younger guys trying to get the new, new stuff out. And these older guys, they're disgruntled jaded old sys admins who are like, you're not doing that on my server, when you think about it, the traditional ops goal is to make nothing ever change at all, because they want stability. So how could we get these two groups of people aligned behind the same goals?
**Track 1:** Jonathan Hall, it is great to finally have you on backend banter. I've guested it on two of the podcasts that you host.
**Lane:**
why don't you take just a second and [00:01:00] tell everybody about yourself.
**Jonathan:** absolutely. So thanks for having me on. This is great. I've enjoyed chatting with you over on my side of the, the, the show, whatever you wanna call that. But yeah, so I'm a, a go developer, a DevOps guy. Tech leadership kind of person. I've done VP of engineering, c t o type of work the last few years,
I really like to help companies find ways to be more productive in the sense of not wasting developer. Skills and time with ridiculous slow processes and, and antiquated to, to building, deploying, and testing software.
**Lane:** Yeah, that makes a ton of sense. So maybe we should start there. So a lot of people listening to this pod are just getting into backend development and, and, and have probably heard this term DevOps.
**Jonathan:** Yeah.
**Lane:** what, what do you mean when you say you do, you do the DevOps?
**Jonathan:** Okay. DevOps has an interesting history. It started a little over [00:02:00] a decade ago and kind of the, the, there's a video that was produced it's on YouTube. You can find it. We, we can probably put a link in the show notes that kind of kicked off the DevOps movement, even though that, that word was never used in that video. It's called 10 Deploys per Day. And they talk about this sort of dichotomy between.
Software developers whose, whose sort of mission is to get new features in front of customers as quick as possible so they can see this exciting new thing as they're doing versus these sort of imagined gray-haired, grumpy old ops guys who like ha sit there with their hands across their chest.
They're like, no, you can't do that. You can't push that feature. It's gonna break my servers, it's gonna bring down the internet, whatever. These sort of grumpy old, old guys, and this is. For a long time. There's a caricature, but there's truth to it. And for, for for decades, I think. Certainly in my experience, that's the way it is.
The, the developers are all excited. They're maybe the younger guys trying to get the new, new stuff out. And these [00:03:00] older guys, they're, they're, they're disgruntled jaded old sys admins who are like, you're not doing that on my server, and
**Lane:** Yeah.
**Jonathan:** the idea of this video is what if we could figure out how to make these two groups of people the same goals? The developer's goal is to make things change as fast as possible. And when you think about it, the traditional ops goal is to make nothing ever change at all, because they want stability. So how could we get these two groups of people aligned behind the same goals? And so that, that's and then, and then just a few months later the first DevOps days was held in Belgium.
And so that's where the term came from, DevOps. So it's the idea of merging dev. Who want to move fast and ops, who traditionally don't want to move fast, how do you get these goals So I, I like to simplify. Admittedly oversimplify
and say that DevOps equals collaboration. And so if you hear the word DevOps in a sentence, just mentally put collaboration in its [00:04:00] place.
And does it still make sense? If it does it, they're probably on the right track and, but you'll hear all over the place where it doesn't make sense. Like the, the Azure DevOps, like Azure. Collaboration doesn't make sense. Or DevOps team, is it a collaboration team? Maybe that makes sense in certain contexts, but often it doesn't.
When you look at what they're doing, like you, you would never say, oh, that team handles the collaboration in this company,
**Lane:** Yeah. Yeah, yeah. Okay. Like all communication and collaboration has to go through this one central
**Jonathan:** right?
**Lane:** That's pretty ridiculous. In fact, you could it sounds like by your definition, the the idea of DevOps would be to remove things like that, to remove things that are getting in the way of developers and operations people just like getting stuff done.
**Jonathan:** That's definitely a big part of it. Yes. Yes.
**Lane:** Okay. So I want to provide a little bit of history for some of our listeners. When you talk about traditional ops teams and traditional dev teams and how in the past, or maybe even in some companies still [00:05:00] their goals are at odds.
**Jonathan:** Mm-hmm.
**Lane:** from a very high level, what's the point of an ops team? What does an ops team do?
I think most of my listeners understand the developers write code and features and fix bugs.
What, what do ops people do?
**Jonathan:** Yeah, that's a good question. I, I would say there, there's many answers to this. So I'm not gonna necessarily cover check all the boxes that some ops person listening might think I should check. But I would say the ops handle the sort of non-coding. Stuff Of necessary for code to run so that that could, in the old days, that was physically installing servers and putting hard drives in them and running network cables and stuff like that. these days we usually outsource that to Amazon or Google or Azure. And so now the ops people are more commonly, running Kubernetes commands or, or setting up Kubernetes clusters or managing Amazon uh, rds or EC2 instances and, and these sorts of things. They probably manage DNS and so either directly or indirectly. So all the sort of stuff that, basically think about.
I'll try [00:06:00] to speak to the, to the beginner backend developer here who is excited. They've just written a great rest API and they wanna show the world. Everything you have to do from writing your REST API until your grandmother can use it, that's Ops
**Lane:** And if your grandmother can use your REST api, like she's pretty cool. You should hang on to her
**Jonathan:** So whatever that means. Everything from, you've written the last line of code, you've tested it locally and it works. Now what do you do so that people can use it? That's opposite. So deploying it to a server, choosing the server, installing an operating system on the server opening the firewall port, setting up, firewall rules, all these sorts of things. Whatever you need to do. That's ops.
**Lane:** Got it. So to I'm, I'm gonna repeat what you said cause I, and, and make sure that I understand it and that, hopefully my listeners can understand. The, i, the idea behind a development team, or I should say the incentives behind a traditional development team is literally just to write software that, Releases new features,
**Jonathan:** Mm-hmm.
**Lane:** like solutions to new problems, [00:07:00] fixes, bugs that kind of stuff.
The goal of an ops team, like their incentive isn't necessarily so much on the product side, right? They're not necessarily worried about, bugs in the software. They're not as worried about maybe, getting new features released as quickly as possible. They're more on the hook for.
Making sure that the software actually runs properly is, is that kind of where you would separate the domains of responsibility?
**Jonathan:** So I, I would say that that's how it's traditionally viewed. But I, going back to this video, I, I think that that's not the correct view or at least often is not the correct view. I, I the, at the time that this video came out, they referenced a game server that had recently crashed, I think it was World of Warcraft.
They don't say it by name. If I remember. And I don't, I'm not enough of a gamer to remember 10, 13 years ago when this video came out, which exactly crashed that week before that, that conference. But they, they make the interesting point that part of the idea of getting dev and ops aligned, Is choosing a common goal that they can work [00:08:00] towards.
And they say, if your business requires downtime because that's what your customers want, then, and, and they were, making a winking nod to, to this game company, I think World Warcraft then that's what your operations people should be aiming for. The traditional idea is the ops want 100% uptime, 15 nines or whatever they can come up with.
If that's not what the business needs, then it's foolish for them to do that. And, and they're not doing their job correctly if they're aiming for higher uptime than the business requires to serve customers. If your customers are happy with the site that goes down for five minutes every, every hour, by all means do that if that's what makes you money, if that's what makes your
**Lane:** Yeah.
**Jonathan:** happy.
**Lane:** Okay. Yeah, that, that makes a lot of sense. Okay, so DevOps is this idea of collaboration that we are, we're aligning the incentives essentially of both teams. They're both rewarded for shipping product faster. They're both rewarded. And it goes both ways, right? Like developers are now more on the hook for like infrastructure type stuff.
Is that accurate to say?
**Jonathan:** So it, it [00:09:00] can be that way. So I, I see there are two common views of DevOps. When you're like, look at boots on the ground, what does it mean to me on a daily basis? There's two common views. A lot of people, especially those who aren't really familiar with the idea, just have the idea that, oh, that means everybody does everything. a developer. I have to also do Kubernetes. I have to learn docker, I have to learn networking, blah, blah, blah. And that can work. And if you're in a really small company, say a startup, and you're like engineer number three. That's probably gonna describe you. You're probably doing a little bit of everything.
You probably have somebody on your team who knows more about AWS and somebody who knows more about Python, and that's fine. But in general, you're gonna share responsibilities. But I have a, I hear a lot of people when, when I, when I teach DevOps, I do, I have a, a half day workshop I do about DevOps to introduce Scrum masters in particular to the topic. And this is one of the things I talk about myths of DevOps. One of 'em is that DevOps means everybody does everything. That's not true. It can mean that, but it doesn't have to mean that a mu much more common approach to DevOps, which is what by necessity in large companies [00:10:00] is a, you still have this sort of split where devs do dev work and op ops people do ops work, but they do it in a different way.
They do it. The ops people, more or less give a platform to the developers. That provide all the visibility and access they need to do their job. And this sounds, you might think this sounds amazing. Oh, great. The developers have everything they need, but it comes at a cost too, and that is that the developers take on a new responsibility. In the old days, developers would write code and they'd throw it over the fence to the ops people, and then the ops people were responsible to make sure it worked right. And if there were bugs in that code, ops people would get called at three o'clock in the morning and they'd have to fix that bug or wake you up to fix the bug if they couldn't figure it out or whatever. And this new approach, this platform approach, and you'll, you'll hear the term platform engineering all over the place too. it's part of DevOps. It's not an alternative to DevOps. Basically the, the ops people give the developers all the tools they need to be woken up at three o'clock in the morning [00:11:00] instead of them
**Lane:** Okay. Okay. So is the idea that there's more touchpoints involved? So for example, before the, the developers would like compile the binary and give it, put it on a flash drive and hand it to the opper. And I know I'm being I'm exaggerating a little bit. But now there there's more visibility exposed by.
The ops team or whatever you want to call them so that the developers get things like telemetry, get things like logging can restart servers themselves. I, I is, is that the idea is to give more tools to the developers to, to fix their own problems and have visibility into like their code running in production.
**Jonathan:** That's exactly right. A healthy, team that's doing DevOps or company that's doing DevOps should have the ability for, for the development teams to deploy their own code on, on demand when they need to. Maybe they're using continuous delivery, so it's every. Every time they merge code, or maybe it's on manual deployment, whatever but whatever they choose to [00:12:00] deploy according to business needs the developers do that.
They're not waiting for the ops people to do that for them. And if they need to roll back, then the developers have the ability to do that without waiting for the, for the ops people. And perhaps most important, the developers have the ability to, like you said, read logs. They're getting alerts to them to, whether it's just alerts for errors or catastrophic alerts, maybe a Century Alert or. Your pager's going off at three in the morning, all of that gets pushed to the developers. And that might be scary to a developer especially one who hasn't done that before, feel like it's a whole lot more responsibility. And that is true. It is more responsibility, but it also leads to a higher quality, code, better customer experience and so on.
Because as the developers take on that responsibility, learn how to address those issues and they quickly become less scary.
**Lane:** does that, so what you just said sounds awesome.
Should ops people be worried that, like what you're describing to me sounds like I need less ops people if they're building tools that now the developers are [00:13:00] using, should ops people be worried that that they're automating away their jobs or maybe that they're buying products that they're giving their devs access to that are auto automating away their jobs?
**Jonathan:** So I, I can understand the concern. I've never actually seen it be a problem, but I will say that it does change the way the ops people work. In, in the old days, the ops people would wait for a ticket, come in, says upgrade to version 1.2.3 or whatever. they would upgrade that. They would, you know what?
Using whatever playbook they have or maybe some automation or whatever, they would do that thing. And then they would report back. If there's a problem, maybe they would roll back and, tell the dev dev team, sorry, I wasn't able to, here's why. This depends on a different version of my sequel or whatever.
**Lane:** Yeah.
**Jonathan:** now the ops people are doing different types of work. They aren't doing. That, but in a lot of ways what they're doing is more complicated. there's more work to be done. There's a lot less manual toil but there's a lot more work in building automation platforms and so on. so I would,
I would only [00:14:00] be concerned if you're an so-called old school ops person.
you're an old network administrator. You, you might have a difficult time adjusting to this new, new approach, but if you're new in your career and you're learning this, there, there is not in our lifetimes do I believe there will be a shortage of people with good platform engineering operations type experience.
So if, if, if that's what you're thinking of going into, do not be concerned, you will have more work that you can possibly ever do in that field.
**Lane:** So it's like the field is, is changing, the field is valuable, but like the skills you need might need to be updated to stay relevant.
And I think that's
true for dev too, right?
That's true in
like any cutting edge field.
**Jonathan:** I think that, I, I'm gonna use a term I hate, but I'm gonna use it because it's a term that people understand and, and, and it's used by, by recruiters, DevOps, engineering, . that term. because collaboration, engineering doesn't make sense to me really.
but we'll use that term. So I'll use that term here. [00:15:00] DevOps engineering is one of the highest demand. most demanding. Careers I think you can take today. It, it's probably harder than backend engineering, than front-end engineering because there's, there, there's so many pieces of technology you need to learn which ones you learn depend on the company you're joining.
you join one company, you're learning Kubernetes. If you learn another company, you're learning, learning aws, you learn other comp. Another company you're learning, and then there's different observability platforms and there's different logging tools and, there's. There's so many pieces there, for e to pick any one type of of tech, and there's probably 15 alternatives, and you get to, you randomly pick one for each job you take.
**Lane:** Yeah
**Jonathan:** so much to learn. Hopefully that will standardize over the next decade or so. Maybe we will only have three to choose from for each one instead of 15. But there's a lot to learn and that makes it demanding. It also makes it high, highly paid, at least in most parts of the world.
**Lane:** Yeah.
the proliferation has actually been really crazy in terms of how many choices you have. If you [00:16:00] have a quote unquote standard web app, the number of choices you now have, like of where you could deploy.
**Jonathan:** Mm-hmm.
**Lane:** Is crazy huge, and just having someone who understands, 30% of them pretty well, is valuable because it allows you to make better choices as a company because there are choices you can make that will like, Heavily impact either in a positive or negative way, the productivity of your team, right?
If you choose to deploy your new your new web startup on-prem in a closet, like you're going to , you're probably going to be much less productive than someone doing something a little more modern, right? And, like the people you're competing with are, trying to be productive as well.
So it's it's really challenging to be behind in that way.
**Jonathan:** Yeah.
**Lane:** Okay, so what. What should a fledgling backend developer care about when it comes to ops and DevOps stuff? I get this question all the time. New backend developers coming to me. Do I need to learn DevOps? Do I need to learn docker? Like how much [00:17:00] networking experience do I need?
What are the most I guess the first question is, are there any ops skills that new backend developers need to know? And if there are, which are the most important?
**Jonathan:** I would say easily the most important is Docker. If you can learn to put your app in a Docker image, you'll be doing well. And it's not complicated. You can more or less find any, there's thousands of tutorials on how to build your first Docker image. Follow one of them. And if you've built an app in, I don't know, PHP or Python or anything, any, any language at all.
Put it in a Docker image and, and run it locally. That's a great starting point. If you, if you can do that you'll be well on your way. And the reason is because we, we just talked about all the complexity involved. If you're doing EC2 or Kubernetes or Docker, whatever, or, or, or, or Google.
almost all of them use Docker as, as a. A base, all. There are some exceptions if you use PMI or something like that, some of them have their own way to go. But even in, if you're using one of those, you'll probably, you'll very likely be using [00:18:00] Docker for local development because it makes an easy way to package your app for testing so you don't have to install all a Python dependencies and get the right versions for your operating system.
And, oh, oh crap, I'm using Mac Os. It doesn't work the way I expected to. Cause the other person who set it up is on Linux or, or whatever, Docker gives you a safety net around that. Start by learning the basics of docker. And I don't mean anything fancy. You don't even have to worry about multi-stage builds yet or anything like that.
Just put your app if you, if you have a to-do VC app that you did from a bootcamp or something, that's fine. Put it in a Docker container, get it, get it running. If you want to run it on EC two, or Kubernetes or something, that's fine for bonus points. But just start by getting your docker image of your app running.
**Lane:** That's awesome. So I chose Right. Uh, docker's the only course in Boots e at the moment. That really is related Any to any, in any way to something, directly correlated with With ops or DevOps, is there anything else? Like what, what comes after Docker or, or would you advise to just not worry too much about it?
Apart from Docker, if you're new,
**Jonathan:** I, I think the next thing I would recommend, and, and this would've been the first thing we recommended before Docker was [00:19:00] popular, is learn basics of Linux. You don't need to install Linux on your laptop if you're not that hardcore, but that would be a great way to do it. But at least get a, a Linux VM somewhere.
Or, or a. Either virtual machine locally or a rent one on from digital lotion or something. Start playing around with Linux. Learn how to install Apache. Learn how to maybe send email. Just learn the basics of, of Linux, how do you change directories and list files and, and do do grip or recursive grip, you know, these sorts of things.
Learn the basics of Linux because that's another common thread throughout. Virtually all e even on Na, Azure, you're gonna be using Linux. Even Windows administrators use, use Linux these days. That wasn't always true. So that, that's the other common thread that's also a lot less specific because I can't just point you to do this thing I'm just saying familiarize yourself with Linux.
So it, it's, it's both more nebulous and maybe in a sense, more applicable because it, it's used everywhere.
**Lane:** Yeah, it like if I were to give my own piece of advice on top of that advice, it would be like, [00:20:00] get comfortable navigating. Like the operating system in Linux, like all of the basic navigation type commands, right? I think we take that for granted, those of us who have been working for Linux or with Linux for a while, things just like Ls cd, right?
Like even some of the lower level tools to do specific stuff like gre getting familiar with a lot of that stuff is great. You don't have to memorize everything. That's also a trap. I've seen people.
**Jonathan:** Yep
**Lane:** into Google is a great way, like when you need to just figure out like a specific command.
And I've actually found that chat, e p t, this is one of those things it's really good at, is give me a Linux command that does X. It's pretty good at giving you the syntax. So what's more important in my opinion these days is to get familiar with what's, what's possible, what kinds of things should I be doing?
And like the quick and easy things you probably should memorize, like just being able to
navigate
**Jonathan:** a lot of caveat there in that is that Linux is, Linux distributions are not all created equal. And sometimes the command that works on one won't work on another, even for some relatively seeming things.[00:21:00] Or you'll find that you're not using bash, you're using Sh or you're using a busy box or something, some really trimmed down version of your cell that doesn't let you do anything you wanna do.
That's just to underscore the, the point that memorizing these things is not your best use of time. I remember I think of ls, one of the simplest command LS lists files is like the d i r command in old dos days, right? And there's dozens of flags you can give to it. probably memorized three of them.
And if I need anything else, I look them up.
**Lane:** Yep
**Jonathan:** For all I know, they change every six months anyway. And I just look, every time I look it up, it's a different one. I don't know, I just, I look it up. I don't know.
**Lane:** Yeah. Yeah, that, that makes perfect sense. A lot of, there's a lot of things in software development that like you do once every. months,
**Jonathan:** Mm-hmm
**Lane:** two years, right? Like I very rarely set up a new C I C D pipeline. Like I set it up and then I use it for a couple years , right? And so it's every time I do it, I usually do have to go consult the docs and figuring it out or, or figure it out.[00:22:00]
But I think the important thing is to like conceptually understand like things like C I C CD pipelines work from a high level. This is how you implement them and get them into your product. But memorizing syntax in a lot of domains in software engineering is, is, I would argue, not the best use of your time,
**Jonathan:** I would agree.
**Lane:** but it's a, it does seem to be a common question I get ah, I've, I've, I did this and then I like totally forgot how it works.
It's like, that's okay. So.
**Jonathan:** And let, let, let me also, this might be a good point to interject a little bit. If you're at an interview and they're asking you what's the correct LS flag for that, you probably don't wanna work at that company. They're asking, they don't understand tech engineering people who interview on trivia like this, that you could just look up on Google in five seconds.
Are are awa are wasting their own time. Even if they're otherwise a great company to work for, they're not gonna understand technology very well. if, if you have listeners thinking, oh, but I need to memorize all the answers for my interview, I, I would encourage those people to reconsider whether they want to interview at that company.
**Lane:** Yeah, I, I completely agree. If a company does not know how to [00:23:00] interview, at least to a certain level of competence, they also probably don't know how to engineer. To a certain level of competence that that can be a good signal. Okay, cool. So what. are some of the best pieces of advice that you would give to new backend developers when it comes to making an outsized impact on the productivity of their team.
So imagine like a new developer joining a team, maybe with two other developers on it, it's like small development team of three. Maybe they have a product manager, maybe they don't. What are the things that they should be most worried about? Almost from a, I don't know if like soft skill is the right.
Is the right way to say it, but it's like from this you read the Phoenix Project, what things could you, as a junior developer actually take away and, and use to make an impact on your team?
**Jonathan:** I think the most important thing that any developer can do and I'll talk more about the junior aspect in a moment, question everything. And I, and I don't mean the code, although that's valuable too. If somebody, if you see some code that's confusing or you don't understand it, sure, ask the questions, but [00:24:00] I'm talking more about the process. The, the biggest waste I see in teams isn't writing code. Writing code is relatively easy, and I, I don't say that to, to put anybody down who's having a difficult time learning to code. That's not the point. The point is that, relative to working with other people. Computers are easy because computers more or less logical.
aside. They, they, they do what we tell them to do once we learn how to tell them. But people aren't that logical. And you tell people something to do something and maybe they do, maybe they don't. Or maybe they misinterpret it or maybe they fight back or whatever. There's a thousand things that people can do.
So I question the processes. If you see a process you think. What the F is going on here? Ask, be, be be courteous about it. Don't insult the people doing it. Ask. That often the processes that make the least sense made sense in a former context that no longer exists. So it wasn't somebody's stupidity that put that weird process in place.
It did make sense in some context, in some, maybe six [00:25:00] months ago or two years ago or whatever. But ask and, and ch challenge those things and do it respectfully. And th this is where being a junior can be very helpful. You can play the idiot card very safely, . You can say, excuse me, why are we doing it this way?
I, I, I don't understand this. And, and they'll just think, oh, it's the junior asking the question rather than, this is some snooty guy who thinks he knows everything asking the question. You don't want to necessarily ask it in such a way that you. So I, I wouldn't encourage you, of course, to to just ask dumb questions in a way that people are gonna think, oh, it's just the junior asking questions. But be mindful that, you're new to the team, you're also new to the career potentially, so you have a little bit more leeway to ask questions than somebody who's been there a while.
Take advantage of that. Ask the questions challenge the status quo in a respectful way Hopefully the people on your team who have more experience will be receptive to, to your feedback and, and maybe consider changing some of these processes if, if they no longer make sense.
**Lane:** Yeah, that's fantastic [00:26:00] advice. I don't know if you've heard in school, and I want to add onto it just a little bit. heard this idea in school, like there's no dumb questions, feel comfortable asking any questions. And usually that mantra I think is repeated for the people who are like too shy to ask questions that are worried about, feeling dumb and like to those people yes.
Like you, you should not, if you genuinely have a question you shouldn't worry about. Feeling dumb because you don't know the answer, you should ask it.
But but
there are really dumb questions like they do exist after running a Discord server, that's all about like learnings, code and coding education.
There are a lot of dumb questions. And, and what I mean by that is it's never from a place of ignorance. , that makes a question dumb. Like it's not a dumb question because you don't know. It's a dumb question because of like the way you frame it or the amount of of work that you're expecting the other person to do.
So one piece of advice I would give on this topic is if you're new to a company and you see something and you're a little confused about why it's that way, like you definitely should spend a little bit of time with Google or with Chat G P T or whatever resources you have trying to figure it out on your own before you go.[00:27:00]
Rip someone away from what they're working on to ask them questions, right? Like you want to put in the work upfront and show that you put in the work upfront to understand something so that that goes towards being courteous in your question, asking. It's not like there's the courteous side of you don't want to be accusatory and like, why is this stupid thing here?
There's like that side of it, but there's also the courteous side of it. Yes, I did take the 10 seconds to Google it and see what this actually does and, and try to think about it on my own first. .
**Jonathan:** So I think there's two sides to this. There's a, there's a asker and there's the aki. And as an ask, e one being asked, one, one response I'll often give is where did you look for the answer before you came to me? And that does two things. For, for one thing, it implies that the answer ought to exist somewhere that they should have looked for it.
Second thing it does is if they actually answer that question, say I looked here and I couldn't find it. Now I know where to put that answer so that the next person doesn't have to ask me.
**Lane:** Yeah.
Yeah
**Jonathan:** that, that's really valuable. If you have an internal wiki, for example, at your company and you say, where did, where did you look?
Oh, I look on the Wiki. I couldn't find it. Okay here's the answer. Now, [00:28:00] I'll put it on the wiki. Next time the, the next new joiner will be able to find the answer in the right place.
**Lane:** Yeah.
it's a way to keep, keep updating your internal information systems which is like a really hard problem. . I've never worked at a company where I was like, wow, we have like really great. Internal documentation of like how to find stuff. Like I've never had that. If it exists out there that would be really exciting.
But I've yet to find, I've found like a billion tools that claim to solve the problem. I've never seen it work. I'm sure there's better and worse ways to do it.
**Jonathan:** Yep.
**Lane:** Chain
**Jonathan:** ways to do it.
**Lane:** Yeah. We'll see if there's any, anything better. , I guess worse implies an existence of better, but okay. Changing topics just a little bit.
So the, the way I came to get to know you was from two different podcasts, one's Adventures in DevOps, which is what been talking about up to this point. The other is Cup of Go and you and I are both Big Go fans. T tell me a little bit about why. I've noticed that Go is just extremely popular in kind of DevOps culture infrastructure.[00:29:00]
Why is go such a popular language for kind of the the infra and ops side of things?
**Jonathan:** I, I think the, the answer to that is fairly simple and that is that that's where Go was invented. Go was invented at Google to be a systems programming language. And some of the first popular tools written and go are things like Docker and Kubernetes and Helm and Terraform, a lot of these big infrastructure tools written and go, because Go is designed to be useful for those those tools.
That's if you are in that space, you're likely working with to tools written in, go. Even if you're not coding go directly, you're probably working with tools that were written in Go. And the natural next step, if you discover a bug and say Kubernetes and you wanna fix it, you gotta learn some go to do that.
It makes sense in that, in that regard. What I think is a little bit more surprising to change subject a bit is the recent go Developer Survey came out just a few weeks ago and there's a huge interest in go desktop applications. GO is no longer just a systems programming [00:30:00] language.
It's not just for backend ops nerds. There are people writing desktop applications and
**Lane:** you're
talking like native, like replacing almost like what you'd use Swift four on Mac Os.
**Jonathan:** Yeah, so there's a framework called Fine, F y n E. We're hoping to interview the maintainers of that on our Cuppa Go podcast soon.
**Lane:** Nice
**Jonathan:** but I, I think it's just fascinating that the go has traditionally been really for these systems things, but it's, it's really blossoming into a very rich ecosystem for all sorts of programming.
**Lane:** Yeah. Yeah. My experience with Go primarily has been like, backend application code. I've done some infrastructure stuff, but if you're interacting with Kubernetes or Helm or Docker, like you're not actually writing go unless, like you said, you're going into fix bugs in the.
themselves. They're just compiled binaries that you learn to use. But I think being a part of that ecosystem also, almost just encourages you to get familiar with the language and use it for more and more stuff.
**Jonathan:** I mean,
**Lane:** Um
**Jonathan:** Library is built, you know, the features that the early adopters of Go, were building these tools. So they asked for features that [00:31:00] made that easier and therefore people who wanted to build similar types of tools found that Go, had a lot of those things. And this sort of bled out and, yes, GO has been very great for, for backend services, writing arrest API or G R P C or anything like that.
It's, it's just because those tools exist, because they were needed by people building Kubernetes and, and so on and so forth.
**Lane:** Yeah. Yeah. Go Is, is one of the tools that you and I both use the most. We've talked a little bit about Docker and Kubernetes for kinda this backend and infrastructure work. If you had to choose just a couple, just, one or two technologies, could be programming language, could be infrastructure, piece of technology.
If you could choose, let's say three, what would be your top three pieces of technology that a, a junior go developer who's looking for the first job. Should learn to help in their career progression and job search.
**Jonathan:** Three pieces of technology for a Go developer to learn. We talking like libraries or, or broader than that? Not [00:32:00] even within the Go Ecosystem
**Lane:** Literally anything.
**Jonathan:** Okay
**Lane:** I, I'm just curious, like a junior developer comes to you asking for, let's say, career advice and, and they're like pretty proficient with with let's say Docker and, and go, they know how to build like a REST API and go, and they're wondering what else they can be learning on the side while they're continuing their job search to help them be more effective.
**Jonathan:** So one of the things I was gonna mention is rest, although you just mentioned that this person, this theoretical person, already knows rest. Although I might challenge that a little bit because I discover I have, I have discovered that most people who think the writing rest APIs don't even know what rest is.
So learning proper rest would be a good starting point. What the actual http verbs mean and what item potency means, and how to use cashing keys and, and All the nuances around that. If you can learn that, you'll, you'll be doing better than 95% of the people you encounter. On the other hand, I'm not a big fan of rest because it's so ambiguous and clunky.
So I would, that, that leads me to my next recommendation, which is to learn a tool like G P C.[00:33:00] Now REST and G R P C are often viewed as competitors. I don't think they really are. Re rest is really, oh, and this goes to why I don't like rest so much.
REST is really designed for document storage and retrieval.
It's designed for the worldwide web, if you have a huge encyclopedia that spans the entire globe and you wanna look up things on it, rest is good for that. is not so good for making remote function calls, which is what we often use it for. Or I should say abuse it for. So if you're trying to abuse rest to do function calls, calculate something or, manipulate something or whatever, something a, a proper R p c remote procedure call tool is a better choice.
And G R P C is a popular one, but it's not the only. You could also look at something like Jason, R P C. And, and there are many others. If you really want to get old school, you could try soap. Don't recommend that. But , the only reason I would ever use soap is if I'm interfacing with an API that mandates it.
**Lane:** In my career, understanding soap has only been useful in the sense that I can also stand and point and laugh and,
and yeah, . [00:34:00]
**Jonathan:** So learn rest and learn something like G R P C or a different rrp C if, if that's the one your employer uses. Th those would be two. Two tools I would recommend. Docker, of course, I already mentioned that one. What's another one or two?
**Lane:** I wanna ask about a programming language. What's your second favorite programming language?
**Jonathan:** That, that's a difficult question for me to answer. I'm really interested to learn er Lang, but I don't recommend most people to learn er Lang. I'm mostly interested in learning it cuz it's archaic and, and not not commonly used. often said to be the only true object-oriented programming language.
Cuz it, it uses a different paradigm than we think of as object-oriented these days. But,
**Lane:** also like
pretty heavily used in infra, right? Like rabbit mq I know
is an Ilan thing
**Jonathan:** And in fact, the, what got me interested in it is I'm a member of the a CouchDB project Apache Project, and CouchDB is written in er Lang. Yeah, it's, it's it is a nice language, but it's not popular lectures.
Much more
**Lane:** Yeah
**Jonathan:** is written on the same runtime or, or, or runs on the same runtime machine. Anyway. So really professionally, my [00:35:00] experience in programming languages is Pearl, and I did that for about 10 years and then go, course, I've dabbled in JavaScript. I, I don't like JavaScript or Pearl anymore.
Mostly for the same reasons. I don't like the dynamic typing and that these, you can it's the wild West, there's no safety whatsoever for the most part, in, in the things you do. It's all by convention, not by by enforcement.
So I don't really have a I, I can't point to a second language that I use professionally that I like.
The, the next language I use most, it would be JavaScript and I don't like it, so I, I don't enjoy it. However, it is good to know JavaScript because it is so ubiquitous and everything,
**Lane:** Yeah
**Jonathan:** doing even if you just have to look at some front end code, you need to know it. But it's also used in, in , sorts of funny places you wouldn't expect.
Plugins, web hooks, all sorts of things. Use JavaScript. GitHub actions uses JavaScript. So if you're using GitHub actions it would be useful to understand JavaScript. So as much as I, I hate to make that recommendation, that's probably one of my them is to learn some JavaScripts.
**Lane:** I think you're right there. So there's one JavaScript course [00:36:00] on Budd Dev and, and it's literally just because I want to teach students how to use the Fetch API
**Jonathan:** Mm-hmm
**Lane:** that they can understand how front end developers are going to interact with their backend services. It's I hate the language. It's, it's better now with some of the new syntax that you have at your disposal.
The problem is all of the old syntax is still available and people will use it and people will look up Stack overflow posts that tell them to use it.
**Jonathan:** Mm-hmm
**Lane:** Yeah, I'm on the same page.
**Jonathan:** Yep.
**Lane:** Cool. This has been fantastic. I have one last question for you. goes beyond specific technologies, but what is the one.
Piece of advice. It could be technical, it could be oriented towards education or career building.
What's the one piece of advice that you would give to someone who feels that they're ready to start their job search to go out and start looking for backend development jobs? What, what would you tell them to help them out?
I know that's generic and vague.
**Jonathan:** So my, my. My most common advice to people who are [00:37:00] in this state, they're like, I think I'm ready, or I'm almost ready. What do I need to do to get ready? I've given this advice to many people just as recently as, as yesterday, applying for jobs. You, you'll never be ready enough. If you wait till you're ready, you're gonna retire before you're ready, just start applying for jobs.
The worst that can happen is that they say no, and maybe they give you some feedback that helps you get ready for the next one. Know, you miss a hundred percent of the shots you don't take, right? So start taking some shots and maybe you, maybe you get a bunch of rejections, but that's fine. You can learn from that.
So start applying for jobs. Get your CV out there, get it in front of recruiters, get it in front of hiring managers, show it to friends, get some feedback. Show it to me if you want. I'm happy to review your cv. I just just made a video about somebody looking for their first go job. their CV and gave some suggestions and they got it.
They got at least one interview from it the same day. So that, that's encouraging. Yeah, I'll have that, I'll, I'll give you a link to that video so you can put it in the show notes when it's ready. And second to that start, assuming you're already doing this, but maybe you're [00:38:00] not, start writing some code whether it's in Go or anything else, whatever language you, you choose, start writing code.
Hobby projects are great. Put 'em on GitHub so that they can be seen. Put a link to your GitHub on your CV so that you can sh show that off to your potential. Hiring managers. but the most important thing is start applying and start that feedback. It's all about agile, right? It's the same thing with software development.
We want shorter feedback loops. thing about DevOps is, shorter feedback loops. Get the changes in front of customers sooner so we can get feedback. Get your CV in front of hiring managers sooner so you can get feedback.
**Lane:** Great advice, air on the side of assuming that you're ready, ,
**Jonathan:** Mm-hmm
**Lane:** get some feedback, iterate on it. I love it. Thanks so much for coming on the show, Jonathan. Where can listeners find you, find what you're working on and, and just follow you in general? I.
**Jonathan:** so probably the best place to follow me these days especially if you're doing backend development and you're interested in Go is at Boldly go.tech. It's my go themed website. I have a YouTube channel you can find there, and I also have a [00:39:00] daily mailing list. I send out Go related tips. I'm going through the Go Spec right now breaking it down into easy to digest chunks, one point per day. Boldly Go Tech. There's a link there to sign up for the daily mailing list. If you're more interested in the DevOps side of things, you can also find me at J Hall do io, where I talk about more DevOps related things.
But I think for this audience, boldly go Tech is probably where it's at.
**Lane:** Awesome. Thanks again, Jonathan. I'll talk to you soon.
**Jonathan:** Great. Cheers.
**Lane:** Bye.