The One Where We Geek Out on How to Learn with Daniela Baron

Feb 27, 2024

Ask episode

Chapters

Transcript

Episode notes

About our guest:

Daniela Baron is Staff Engineer at FundThrough. She has over 20 years of experience delivering software solutions for a variety of product, project and SaaS based companies with many languages and frameworks including Ruby on Rails, JavaScript (Node.js, React, Ember, Angular), Go, Python, and Java/Spring/Hibernate. Specialties include analyzing complex business requirements, writing maintainable code, implementing best practices such as linting and code coverage, engineering documentation, test automation, continuous integration/continuous deployment, and mentoring. Passionate about continuing education.

Find our guest on:

Find us on:

All of our social channels are on bento.me/geekingout
All of Adriana's social channels are on bento.me/adrianamvillela

Show Links:

Transcript:

ADRIANA: Hey, y'all, welcome to Geeking Out, the podcast about all geeky aspects of software delivery, DevOps, Observability, reliability, and everything in between. I'm your host Adriana Villela, coming to you from Toronto, Canada. And geeking out with me today, I have Danielle Baron. Welcome, Daniela.

DANIELA: Hi, thanks for having me.

ADRIANA: Super excited to have you on. So where are you calling from, Daniela?

DANIELA: Also Toronto, Canada.

ADRIANA: Yay, Toronto. Okay, I'm going to start with some lightning round questions. First off, are you a lefty or a righty?

DANIELA: Right handed.

ADRIANA: All right, do you prefer iPhone or Android?

DANIELA: I've actually used both. And I prefer iPhone mostly because Apple seems to send security patches for a lot longer than I've gotten on the Android phones in the past. So if you're not getting security patches, your phone is basically a very expensive paperweight. So that's why stick with iPhone.

ADRIANA: Yeah, fair enough. Awesome. Next question. Mac, Linux or Windows? What's your preference?

DANIELA: Yeah, that's another one that I've used all of them, and I'd say I'm happiest when I'm using a Mac. It has all the Unix utilities, a nice customizable terminal, but things just work for the most part. Like if I need to do video conferencing or watch YouTube videos, I don't need to fuss with it. So I feel like it has the best of all worlds.

ADRIANA: Yeah, I totally agree. I used to have a dedicated Linux machine and then I realized that I needed to either dual boot Windows because it didn't have all the things that I needed, or I had to do a Windows VM, which in itself was like its own special nightmare. So I totally agree. Mac was like, oh, the answer to all my problems. Cool. Okay, favorite programming language?

DANIELA: I'd have to say Ruby. Yeah, definitely optimizes for developer productivity and developer happiness. Yeah, I'm just in a really good mood when I use it.

ADRIANA: I feel you. There's something to be said for programming the pleasure of programming. And there are some languages that bring the best out of you, and there are others that just make you angry. I found Java kind of made me angry whenever I would code in it because it's like, so verbose. And so I found my happy place with Python. So I'm glad you found your happy place with Ruby. Cool. Okay, next one. Dev or Ops?

DANIELA: So for my career I've done mostly dev and I'm very happy doing that. But I have done a couple projects that were, I guess in the DevOps space and that was really cool to see that aspect of it. But mostly I've done dev.

ADRIANA: Which one do you like better?

DANIELA: I'd say if I could only do one, I'd stick to Dev because there's something very satisfying about building software, like working with the product team, figuring out what to build, actually building it and shipping it. There's just something very satisfying about that.

ADRIANA: Yeah, totally. I totally feel you. Okay, next question. JSON or YAML?

DANIELA: Ideally, I like to work in things that don't require too much configuration so you don't have to read too much of either of them.

ADRIANA: Fair enough.

DANIELA: Yeah, either one, really. I guess with YAML, when it gets really deeply nested, sometimes I get lost in all the white space. Which level am I at? Like if I hit the enter key and I want to go back, how many levels back do I need to go? I mean, editor support can help with that a little bit. Yeah, YAML is okay as long as it doesn't get too long and too nested. I find then it gets a little hard to read.

ADRIANA: Yeah, fair enough. Fair enough. Okay, next question. There's two more left. Do you prefer to consume content through video or text?

DANIELA: It really depends on what I'm trying to do. If I'm in the middle of a problem at work, like I'm getting a stack trace or I can't install something, I'm getting a weird error, I just want a text-based solution. I don't have time at that point to watch a video that's going to explain to me the root cause of the problem. I just need a quick fix. But if I'm learning, like if I've set aside...okay, I have an hour, I want to sit down and learn a new topic. I actually find video is better for that.

ADRIANA: Interesting. I like that. Cool. Okay, final question. What is your superpower?

DANIELA: Oh my. I guess I'm strong on the written communication skills. Whenever I figure out a problem, I like to write either a blog post or if it's something very specific to work that I'm doing for my employer, I'll write up some internal documentation and include that on my next PR. Basically, then next time that problem comes up, if I've forgotten or I'm not around, then other people can fix that. So yeah, I'd say definitely good written documentation skills.

ADRIANA: Yeah, and I can totally vouch for that because you write some really great blog posts and they're fun to read. They're super informative. So yeah, I definitely appreciate that. And I think having very strong communication skills is something that isn't the first thing that comes to mind when we talk about folks in tech. And yet it's such a crucial skill, right? Because yes, we communicate through code, but we must also communicate through whatever the official workplace language is so that we can understand each other and so that we can build better software together.

DANIELA: Definitely, yeah.

ADRIANA: Cool. Okay, well, now that we're done the lightning round questions, it's time to get into the meaty bits. So one of the things that you and I talked about before getting on here was something that's so key to developers, which is learning new skills. So I wanted to just get your thoughts around that.

DANIELA: Yeah, definitely. Throughout my career, I've always had to learn new things. My educational background is computer science from university, which, at least the program I took was very theoretical, which meant that when I got into the real world, I didn't actually know anything, practically speaking. So yeah, I've always had to be learning. So early in my career, I used a combination of just try to get things working and then look it up. If it's not working, you get an error. Look it up on StackOverflow or other free online content like blog posts and tutorials, and you can definitely make some progress like that. But I always had a sense of that.

I was just reacting to each problem as it came up and I didn't have a sense of big picture understanding. And I felt like, well, if I understood the kind of bigger picture of how this framework or language or whatever works, maybe I could plan things out more smoothly so I wouldn't be running into these little problems here and there. Yeah. Then I've done some formal education. This is like in-classroom kind of courses where there'll be a workshop, like a two-day or sometimes it's a whole week, and if you're lucky, your employer will actually pay for you to go and they'll send a few people from the same team to go learn together. And it's nice to learn with your team and to have a complete change of scenery so you're not at your desk trying to learn while you're also trying to put out fires or something. You actually have a whole day or a whole week to focus. So that's really nice.

There are some drawbacks, so there's not much flexibility. Like, if someone needs to leave early to pick up their kid or has an appointment or something like that. Like these courses that they're in person, they tend to be like, let's say from nine to five. And if you have to leave for something, that's too bad, you're just going to miss out on the content. The other thing I found with some of these kind of in-classroom, in-person sort of courses, the pacing may not be appropriate for everyone. So sometimes what will happen is there'll be a section that maybe you already know it, it's kind of introductory, and you've already self-taught on that and you kind of wish the instructor would speed up through that, but they can't because there's other people in the class. They might not know that and it wouldn't be fair to them. On the other hand, sometimes there's some material that's really tricky and you might want to pause. I've felt like that in classes where I wish I could just pause the instructor and go explore a little bit on my own or maybe try it out and then come back.

And you can't do that because the instructor has an agenda. They need to cover it because that's what everyone's paid for. So yeah, that's some pros and cons of that. I've also done MOOCs. So for those in the audience who may not have heard this term, it stands for massive open online course. And it's a kind of online learning platform that offers either free or low-cost courses, typically from universities. So it's a lot of kind of university topics and it's accessible to a global audience. So in theory, there's no limit to the number of participants you could be learning with people from all around the world.

Yeah, it's really cool. My experience with these has been the quality of the material is really high. It is like university quality material. Usually there's like a series of video lectures that are released each week, but you do it from home, so it's more convenient. Like, you don't need to commute and be at a class at a particular time. You can watch the videos whenever you want, but there's always a drawback, so there's no accountability. No one's taking attendance or cares. Whether you're actually watching the video lectures or not, it's totally up to you.

So you need a lot of internal motivation to get through the material. The other thing to watch out for is some of them do have assignments that need to be handed in each week. So although you could watch the videos whenever you want, if you don't keep up with it, it just tends to pile up. So you do need to set aside some regular time where you're going to do the lectures and do the assignments. And I actually found the workload was surprisingly high, like 6 to 10 hours a week that you need to succeed at these.

ADRIANA: And that includes the assignments too?

DANIELA: Yeah, like watching the videos, understanding the material, and completing the assignments. So I would say for anyone who's considering these, maybe evaluate what a typical week looks like in your life and see if you think you have six spare hours. And if not, I would urge caution before signing up because it might just create more stress in your life.

ADRIANA: Are these like paid things as well? Like, these are paid courses?

DANIELA: Some of them are. So when I took...I took some at Coursera and it was free. I think the way they have it right now is it's free if you're just going to watch it. But if you want someone to grade your assignments and you want to get some kind of certificate of completion or something like that, then there's a paid version. I don't have the prices offhand, but it is significantly less than what you'd pay for like a four year degree program at a university, something like that. So it is still a good choice for some people, but you definitely need the time.

ADRIANA: Yeah. See, this is why, honestly, hats off to people who do school part time. Get some other degree while they're working. Because the thought of doing that, just like, I'm so over school right now, I do not want to touch that. It's been 20 plus years since I finished school, and the thought of trying to juggle that just does not tickle my fancy. I'd much rather sit off in the corner and be like, oh, this is a cool topic that I want to learn about. Let me just read up on it for me. Anyway, I know everyone's got their own style, but yeah, I think that would turn me off from that kind of thing. It's a little too structured for my taste.

DANIELA: Yeah, very structured. And the time commitment is pretty big. So actually that leads me to the next kind of learning, which actually you might like better. So it's these online screencasts, so it's sites like Tuts+, Pluralsight. There's some individual instructors that offer these like Wes Bos and Erik Kennedy have these kind of longer video courses, but they're usually completely self-paced. And what they do is the video sections are split up into very short sections and they tend to be pretty practical and hands-on. Sometimes videos are split up as short as just ten minutes. So if you're the kind of person that doesn't have a lot of time, but maybe you could squeeze in 10-15 minutes a few times a week.

The online screencast might be a really good choice for you. So you can watch a video and then try out some hands-on exercises, like follow along with the instructor. Because it's a video format, you can pause it, you can go explore other areas, like if there's something you don't understand and you realize, oh, I want to do a little bit more research here or try this out and then I'll come back and finish this video. It's totally up to you. It's self-paced, so the flexibility is like maximum flexibility on these. But again, you need a lot of internal motivation because there's no assignments to hand in, no one's checking up on you. These do tend to be paid services, like Pluralsight, for example. I think they have either a monthly or an annual subscription. So you might look after a year and say, oh well, I only use this for like half an hour, maybe I shouldn't renew my subscription.

ADRIANA: Yeah, totally.

DANIELA: But that's pretty much the only accountability there is. If you care about the money.

ADRIANA: The incentive of like, "I'm paying for this, I should get the most out of it."

DANIELA: Yeah, but that's definitely one of my favorite ways to learn. I found it very effective for learning all kinds of Javascript libraries and CSS frameworks and things like that. Another way to learn that I've used is with books, like programming books or technical books. This has some of the same qualities of the online screencast in terms of it's totally self-paced, ultimate flexibility. But some people prefer to learn in reading rather than watching videos content. And I find books do tend to go more in-depth than the videos. So this might be good for some people. Just a hot tip, definitely invest in a bookstand.

I got one from Amazon for like $20 and it allows you to prop up the book right next to your monitor at a natural angle so that way you can keep your head and your back more straight when you're reading rather than being kind of hunched over your desk. Like if you have the book laid flat on your desk and that's going to make such a difference in terms of the ergonomics. So yeah, that's books. And finally, after some 20 years of experimenting with different kinds of learning, what I found works, I think the ultimate for me, is kind of using a combination. So if I'm starting something that's brand-new to me and that I need to learn, I like to take kind of an intro level screencast course just so I can understand the nomenclature. Like each kind of tool that you're going to use has different terminology. And if you start trying to Google and you don't even understand the terms, none of it's going to make sense to you.

So I like to take an intro level course just so I understand the very basics, and then I like to actually use it on the job. And there is where I'm going to encounter problems that are more complicated and couldn't have been covered through an intro level course. Then I use a mix of looking up online like StackOverflow blog posts, AI, LLMs, newer things, ChatGPT or whatever, and then I can understand a little bit better the answers to those, or I even know what questions to ask because of the basic course I took. And then if I find I'm still using that at work a lot, I might circle back and then either get a book or take a more advanced level course to get a deeper understanding. What I found for me is if I take a really in-depth course right from the beginning, before I've even tried, I just won't appreciate the nuances because I haven't encountered those problems yet. So I think doing kind of an iteration of some simple introductory material and then some hands-on, try to solve real problems with it and then come back for more learning. If you feel like you still want more in-depth, that's kind of sweet spot for me with learning.

ADRIANA: That's awesome. Yeah, that's really great advice and I definitely appreciate you going through all the different options for learning things because I think ultimately learning is such a personal thing, but knowing what options you have out there as a learner so that you can get started, because sometimes it can be very overwhelming, right?

You want to learn the thing but you don't know how, and then you have a very particular learning style. So knowing what's out there, that's going to suit your learning style and then playing around with it as well, because it might not be, as you said, one thing that is the answer to all your problems, right? It could be a combination of things, I think is super important. I wanted to go back to a point that you mentioned earlier, which I thought was very interesting where you talked about reactive learning. And I think in our field there is a lot of reactive learning because either it's because you're thrust into a project on X and all of a sudden you're like, oh, I know nothing about X, I must learn this. Or like you are doing something that you know how to do, but then you start refining your code and digging a little bit deeper and you want to make it a bit prettier and then all of a sudden you're like, "Oh, I actually don't have the skills to do this. I must learn." And I think that the reactive learning can be kind of exhilarating sometimes, but also very stressful. I was wondering if you could share your thoughts around that. How do you deal with reactive learning, especially when you're under the gun, you've got a deadline and you got to figure out this thing.

DANIELA: Yeah. One thing, it helps if you're working in an environment where you have psychological safety, meaning if you can say to your manager something like, look, I haven't done this before, but I'm happy to learn. So I might make a mistake or it's going to take me a little longer than someone who has five years experience in doing this thing, and I'll document as I'm learning. So it will help the next people that have to do this. So, yeah, it definitely helps if you're in an environment where you have the safety to do that because otherwise it is very stressful.

ADRIANA: Yeah, I completely agree. I mean, there's nothing worse than working for a manager that's breathing down your neck and then you're feeling this extra pressure to learn, and then all of a sudden something that could have been fun and exciting turns into this complete nightmare scenario and almost seizes up your learning. And that doesn't do anyone any favors. So, yeah, I completely agree. The psychological safety is so important, and it's a recurring theme in tech. I mean, we have to have psychological safety within our teams, right? So that we can be our best selves when we're at work, right? So that we can be as productive as possible, so that we can learn as well as possible and so that we're happy because ultimately we're at work for a big chunk of the day. So it had better be like a relatively happy place, I would hope, right?

DANIELA: Yeah, I agree.

ADRIANA: Cool. Then the other thing that you brought up, which I was getting, like, flashbacks, the 9-5 courses, which, as you said, it's a great way to take yourself out of the day to day and attend these short little courses with your coworkers. But as you said, everyone's kind of at a different pace. And then when you hit the point when the instructor is talking about something that hasn't sunk in yet, and you're like, can I just hit the pause and rewind button? And they often don't have time for you. And I found that it even brings me right back to my university days being in lectures where I'm like, oh, my God, I am so lost. And then you're asking the professor questions, and after a while this happened to me. After a while I had this one professor, he's like, I'm not taking any more questions. I have to move on. And I'm like, no, I'm lost. Help. It can be so devastating. What do you do in those types of situations when you're trying to keep up, but sometimes the material, like you hit a snag in the material and the comprehension.

DANIELA: Yeah. So I haven't done any of those courses like that recently, and that's because of exactly the problem you're describing. So what would happen to me is I would just ask, okay, are we going to get this material? Are we going to get access to the slides or whatever and just hope that I can have time to review it later? There's not a whole lot you can do if the instructor is clearly in a hurry to cover more material. What I learned from experiences with that kind of training is that it's just not the best use of money for me. And those courses can be expensive because once I hit a point where I don't understand it, the rest of the material builds on that. So I won't understand the following either. And that's really why screencasts and books are my preferred. Probably in the last five to eight years or so, I've just been using mostly screencasts and a little bit of books because I find I get way more out of that, like just the ability to pause the instructor anytime I need to.

And it will take me a long time to get through. There could be a 1 hour video course, but it could take me weeks to get through it because I'm just doing a little bit at a time and I'm actually hands-on trying the exercises. And if I get an error, then I'll go look that up and understand, okay, what is it I did wrong? Or if there's a certain API they're using, I'll wonder, oh, what are the other flags I can pass to this? What's the other behavior? So I'll do more exploration that there would be no time for in a formal course, like an in classroom kind of course, and then I'll take the time to organize my notes about it. I might publish my notes to GitHub so I can always find them, whatever computer I'm on. Yeah, basically that's why I find the self-paced learning more effective for me because a) I have a high degree of internal motivation, so some people might need the in classroom setting to like, otherwise they'll just never get it done. But that's not the case for me. And just the ability to pause the content is super valuable.

ADRIANA: Yeah, I totally agree. My mind tends to wander. And so if it wanders at the wrong time where the instructor is talking about something crucial and it's a live course, you are screwed. The other thing too, about the live courses is I always find like, they're great for intro materials, and so sometimes you'll come out of it thinking, oh, I get this. And then you go to apply this at work and you're like, oh my God, this was like the simplest use case ever. And of course the use case at work is seldom ever the simplest use case. It's probably like the most difficult, weird ass use case ever. And so it almost feels like it doesn't get into enough depth so that you have the high level understanding.

But do you really understand it? Because it doesn't give you necessarily the tools you need to get into those more complex use cases. And then the other thing that you mentioned that I thought was really interesting, which I started doing myself, is the idea of publishing your own notes to GitHub. Because I used to keep a bunch of notes in the text editor on the Mac or whatever notepad on Windows, and my notes were always so freaking messy. And I'm like, man, it would be so nice if I could put these in Markdown and make them searchable. And then I'm like, "Wait...GitHub! What?" So creating Gists or GitHub repos of notes for me when I realized, "Oh, I can do that!" was super useful.

DANIELA: Yeah, definitely. It helps you to organize. And Markdown is a very lightweight format, so you don't have to fuss with the WYSIWYG editor and all the bugs that can sometimes be in that markdown is just so simple that it really gets out of your way and just lets you focus on the content that you want to type up. And yeah, I like publishing them. Sometimes I get stars on them from people I don't know or whatever. So I think they definitely get indexed and show up in search results. So maybe if my notes can help out some other people too, then that's great.

ADRIANA: Yeah, totally. That's always been my philosophy too. Whenever I learn something, I'm like, I can't be the only person who has struggled with this because I don't know about you, but I always tell people, the thing I hate the most about technical documentation is how it feels like they started out explaining the thing and then partway through the author is like, "This is too much work, I can't deal with it. You figure it out." It's like the thing in the math books. We'll leave the proof, proving the proof up to the reader. And it's like, "No, show me. I don't know how."

DANIELA: Yeah, there's definitely value in seeing an example as well. Sometimes with the official docs, they're just showing you one line or they're explaining all the options that you can pass to method call. But if you see it in a working example with explanations of like, okay, this option is changing the behavior because of this. And here's the output from this that can be a lot more helpful to people. So I'll write my notes kind of in that format.

ADRIANA: Yeah, I completely agree. And one of my biggest pet peeves with documentation, just building on what you were saying around these sites will show you little snippets of configs. And for me, one of the things that annoys me, one site that always gets me is the HashiCorp site. So, HashiCorp people, if you are listening: pro tip on fixing your docs, include a full example of your stuff. Because having, like I was saying one time I was going through the docs, I thought it was like some configurations for a Nomad job, but it turned out that it was some configuration that applied to the actual Nomad agent configuration. And I'm like, could you have been a little bit clearer? So I think a full-fledged example would have been super helpful. It's the same sort of thing for me. Whenever I write blog posts, I like to have the full example because I always think of like, what if it was me reading this and I'm learning a thing from scratch and I have no idea what's going on? Give me the example. Give me links to the things that you're talking about. That might not be super obvious that you obviously knew about, but me, as a beginner, I have no freaking clue what's going on.

DANIELA: Yeah.

ADRIANA: Cool. Actually, speaking of Nomad, because I wanted to get your thoughts not on Nomad itself, but you and I both worked at a place where Nomad was the orchestrator, the container orchestrator of choice. And we both found ourselves at this workplace in a position of like, well, I've never used this before, so I was wondering if you could talk about what your process was around learning how to use this tool that you'd never touched before, may not have heard of, or maybe heard of in passing, to be able to ultimately do your job well, sure, yeah.

DANIELA: Well, just because I've been doing this job for a long time. In the old days, developers didn't even have access to deploy, especially to production. This used to be really tightly controlled by gatekeepers, like an operations team or change management teams, if anyone remembers things like that. And I wouldn't want to go back to those days for sure. But it is ideal if deployments can be made easy, so that not everyone needs to invest time to become an expert in it. Ideally it should just work with like, oh, you just get merged, your branch to the mainline and it should just deploy. But it is good to have some understanding of how it works. So yeah, I had an experience in one role I was at.

We were going through a platform migration. I was a developer working on a Rails application at this job, and we had a MySQL database, a background task runner, some other background services, and a number of cron jobs. And the way deployments were done, it was with a mix of like Zen and some homegrown tooling. There was a JIRA-based change management approach that required manual approvals. And then there was Jenkins. And it took a long time to get a build together. Like a developer had to spend time doing it, and you could only do it on certain days of the week. And the idea was to change everything, to have all the services running on a private cloud built with OpenStack and using HashiCorp tooling.

That's what this company had decided to go with, including Terraform, Consul, Vault, and Nomad. And the other goal was to have everything, all the deployments be automated with GitHub Actions. So we were already using GitHub. So it was kind of a natural fit to use GitHub Actions rather than go some third-party CI. So originally the task of doing this platform migration had been assigned to another developer on the team. But shortly after this project started, it turned out actually he was leaving. So my manager asked me if I wanted to take this over. Now, I had not previously done anything like this.

I worked with build systems and deployment system, but I'd never set it all up from scratch and kind of defined how it should work. So I was a little nervous, but also kind of excited for the opportunity to learn something new. And that psychological safety I was talking about earlier was really high at this workplace. So I felt really comfortable saying like, yeah, I'd love to learn this. I don't know it now, but I will. What I did to start with, because we were using Nomad, I did take there was this introductory kind of video course on Pluralsight, so I took that it wasn't really so much hands-on, it was more just explaining the concept. So I was kind of able just to write down the definitions of everything at this point, since I hadn't worked with it, I didn't really understand, but at least the words like jobs and scheduling and resources and services and tasks, these kind of terms that are going to come up as soon as you start trying to figure out nomad stuff, at least they sort of became part of my then. So I had to learn about the concepts of Nomad.

Like, you configure things with HCL, which is a HashiCorp configuration language. It's kind of their own language, but it looks close enough to a mix of YAML and JSON that I was like, okay, it's a little different, but not too different. Yeah, I see what's going on here. And I had to learn about the jobspec file and how you, that's what HashiCorp uses to configure a job that needs to be scheduled, where scheduling means run a task. Like I have a Rails server that I want to run, so that has to be in a task. And I had to learn about lifecycle methods because it's like, well, before you run the Rails server, there might be database migrations. So how do you run those before. Oh, they have lifecycle hooks.

Yes, please run the database migrations before you run the Rails servers. And I had to learn about how you can nest groups and tasks inside the jobs. And we had decided to use Docker. So I had to containerize our applications and then learn how to use the Docker driver and how to configure that, how to tell it, which command to run and how you can also specify resources like cpu and memory usage. So how do you do that? How do you specify health checks? One thing with Nomad is to get resiliency, like auto-restarting failed jobs or doing rolling updates. You can do that. They provide a number of stanzas to do this. And the stanzas are like sections or pieces of configuration that you can define in the job.

They have a bunch of them, like update, restart, check, restart, reschedule, migrate. So I had to read up on all of those. And they do have pretty good docs, like at least defining all those terms.

ADRIANA: Yeah, totally.

DANIELA: And then a process I would run into is I would put what I thought was a fine jobspec together and then I would read up on the Nomad CLI. So, oh, you install it on your laptop and then you do like Nomad job, run or run job. I can't remember the exact syntax right now. And then it submits that job and then you can check on the Nomad, there's a web UI and you can check. And I would frequently get errors. And this is where things got a little dicey. Sometimes I would Google those error messages. This was before the days of LLM.

So yeah, you just had to Google or DuckDuckGo the error messages and sometimes nothing would turn up. So another technique I guess for learning or troubleshooting is that if the project's open source and Nomad is, it's written in Go and it's on GitHub. So you can go to the GitHub source and search that error message in their code, find out where from their code it's coming from. And then if, you know, I had used go a little bit before, so I know just enough that I can kind of trace through the code and see, oh, okay, maybe this is the problem, then come back to my jobspec, try something else. So yeah, it was very iterative. I also had to learn how to use Vault. That's another HashiCorp product, and Vault and Nomad talk to each other. So that Vault is for secrets management.

And what we needed to do, since we had decided to store our secrets in Vault, you need to generate those as environment variables in our case for the Rails application, like what's the database host and password and other services that we needed like Braintree, API key and all those things were in Vault. So this was another kind of tricky part of Nomad is there's a template stanza, and you can use that to extract things from vault and then generate an Env file and make that available to the container that Nomad is going to be running as your task. And then all those things become available as environment variables to your application. So I had to learn how to do that and learn about the Nomad CLI. Some more learning I had to do was about GitHub Actions. Fortunately, that's pretty well documented as well because once you know how to say, run a nomad task from your laptop, you're like, okay, well, I don't want to have to do this each time there's new code. So I had to automate the process of, okay, so if a PR just got merged and all the tests are passing, then what we want to do is build a Docker container and tag it with the latest Git commit SHA and then make that available through variables to Nomad so Nomad will know, oh, this is the container that I need to pull and run. So putting all those pieces together, one thing that helped me with the GitHub Actions is I actually did a little experiment on my own and built a CI/CD pipeline for my blog, which is a static site built with Gatsby and has some Rails service as a backend.

It's not nearly as complex as what I had to do at work, but I found it really helpful to kind of experiment in a low risk way, like just on my own as a side project. And then I actually ended up writing a blog post about how to do that. And then I was able to take some of those things that I had learned about working with GitHub Actions and build our real CI CD pipeline, like for big project for my employer. So yeah, that was really good project. It was kind of the most DevOps I'd done up to that point in my career. And just seeing how everything works under the hood, I set it up with as much automation as possible. I forgot to mention, another kind of automation you would want is sometimes developers want to just deploy a branch to like, we had other environments beside production. We have dev environment, staging. So I set it up that you could make an empty commit on your branch with a special keyword like deploy dev or deploy staging.

And with GitHub Actions there is a way you can read the head commit message and say okay, if it's not the mainline, like this is a feature branch, you can get the branch name and you can check that get commit message and say oh, okay, I'm going to deploy this to dev or deploy this to staging. And you use that together with something called environments, which is another feature that GitHub provides. And if you do that, you actually get slack integration for free. So it will post a message to a dedicated Slack channel saying oh, deployment to dev starting or to production. And then if it succeeds or it fails, so you get status information like that without having to monitor nomad directly yourself.

ADRIANA: That's awesome.

DANIELA: Yeah, so that was the project. A lot of learning, a lot of automation. It was nice because being a developer, I was kind of making it for myself. I knew how tedious the existing deployment process was and I was like, okay, I don't want to do any manual work. I want this to just work and be automated.

ADRIANA: Yeah, and I think that's so good because you're basically taking advantage of your knowledge as a developer and saying, okay, well, if I could make this the most optimized thing possible, this is what I would do, which honestly, that's kind of what made me fall in love with DevOps because I'm like, oh my God, why does all this crap have to be manual, right? These are the things I would like to do to make my life easier. So very cool. Awesome. Well, we are coming up on time. I can't believe how quickly the time has passed. There's just so much to talk about in this space of learning and I could be talking and talking and talking about this stuff forever. Before we part ways, is there any piece of advice that you would like to give to our audience as far as picking up a new skill, especially in tech?

DANIELA: Yeah, definitely. Try to always be learning and there's so many different ways to do it. As we covered earlier, what I would...advice I would have for people is, just try different ways. If you don't like something, let's say you took one of these MOOCs and that didn't work for you. That's fine. You still learn something. You learn that that style doesn't work for you and try something else. Just keep trying different ways and you're going to find a certain style of learning that works best for you. So keep experimenting and definitely keep learning.

ADRIANA: That's awesome. I really like that advice. I think it's really important for us to be better learners is to understand what works for us as learners. So awesome. Thank you so much, Daniela, for geeking out with me today. Now, y'all don't forget to subscribe and be sure to check the show notes for additional resources and to connect with us and our guests on social media. Until next time...

DANIELA: Peace out and geek out.

ADRIANA: Geeking Out is hosted and produced by me, Adriana Villela. I also compose and perform the theme music on my trusty clarinet. Geeking Out is also produced by my daughter, Hannah Maxwell, who incidentally, designed all of the cool graphics. Be sure to follow us on all the socials by going to bento.me/geekingout.