The Relicans

Cover image for Programming Upstream and Chasing Coding Dreams with JT Kaufman
Mandy Moore
Mandy Moore

Posted on

Programming Upstream and Chasing Coding Dreams with JT Kaufman

Senior Software Engineer at Red Hat JT Kaufman talks with host, Kirk Haines about why she loves working in Python, how portfolio building landed her a job while she’s still in school for software development, and why if she could wave a magic wand, she’d go back and do more work with a study group to get rid of the isolation and the lack of structure that can be an issue when learning on your own.

Should you find a burning need to share your thoughts or rants about the show, please spray them at devrel@newrelic.com. While you’re going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you’d like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @PolyglotShow.

play pause Polyglot

Jonan Scheffler: Hello and welcome to Polyglot, proudly brought to you by New Relic's developer relations team, The Relicans. Polyglot is about software design. It's about looking beyond languages to the patterns and methods that we as developers use to do our best work. You can join us every week to hear from developers who have stories to share about what has worked for them and may have some opinions about how best to write quality software. We may not always agree, but we are certainly going to have fun, and we will always do our best to level up together. You can find the show notes for this episode and all of The Relicans podcasts on developer.newrelic.com/podcasts. Thank you so much for joining us. Enjoy the show.

Kirk Haines: Hi. Welcome to the Polyglot podcast. I am Kirk Haines, your host. And today, we have with us, JT Kaufman. JT, would you mind just giving everybody a little bit of an introduction to yourself?

JT Kaufman: Sure. Thanks, Kirk. I'm happy to be here. My name is JT. I'm a senior software engineer at Red Hat in North Carolina, and I work building mostly back-end security products, which is really interesting.

Kirk: Back-end security products, huh. Since we're talking about Polyglot and languages and that sort of thing, what platforms or languages do you primarily use for that sort of thing?

JT: In my current work, I do a lot of work with Python. I do a lot of work with SQL, Docker. We do get to play around with some Red Hat products, which I guess is the advantage of working somewhere that has a million product lines, but yeah, those are my primary tools. And we also work with a number of security APIs and third-party tools. That's kind of where I am currently. I actually got my start with Ruby, though, and I was able to walk into Python work just on that basis. So I've been a little bit all over the place. I began working with Ruby. I moved over to C# for a while. I had to use Java throughout college. And then, currently, for the past few years, I found my way to Python and SQL work, which is where I'm the happiest lately.

Kirk: Interesting. I haven't done a lot myself with Python. I've managed to dabble in a lot of different languages and environments and things like that over my career, but somehow I've almost completely managed to avoid Python. I'm actually just curious from your point of view; having worked with Ruby and now working with Python, what is it that you like about Python? Because I'm curious.

JT: So I probably shouldn't say this because it's the true answer, but it was definitely informed by expedience. So I was really into Ruby my first couple of years doing this type of work. And I kept being open to Ruby work but having a hard time finding it in my area, actually. I don't know what that is. It seems like Ruby is not going anywhere. And I know a lot of peers in my area definitely do work with it, but for whatever reason, it didn't work out for me. And I had a friend basically say, "You should try Python." We have a bunch of networking companies; we have some AI, some machine learning in the area of North Carolina where I live. And so a friend recommended it, and I joked that it was like my methadone to deal with wanting to write Ruby and not getting to write Ruby.

Kirk: [Chuckles]

JT: These are definitely nits, but there are a couple of things I like a little bit better about Ruby than Python, just a very random selection of things. But they have a lot in common. They both were written around the same time. They both were written with the goal of being fun to write and making things really easy and elegant for the developer. And I know some people don't really like that abstraction. I know some people want control; they want to see everything that's happening. But I've always felt like when people say about high-level languages like Ruby or Python, when people say stuff like, "Oh, that's too much magic." I always feel like who doesn't like magic? [Chuckles] I love magic. Give me the magic. I'll get a lot done. And that's my happy place, I guess.

But back to your main question, they do have a lot in common. They both have a lot of very convenient, sensible methods to make the developer’s life easy. They both have really mature ecosystems. They've been around a long time. And I feel like as an earlier developer, they definitely both gave me confidence. When I would get a task, I would know that there's some sensible way to do it in the Rails ecosystem. And similar is true for Django, which is the big web framework for Python. So knowing there's a sensible way to do anything I want to do, I feel like it is a bit of a confidence boost as a developer and definitely keeps me from reinventing the wheel too much.

Kirk: Yeah, that makes sense. I think the thing with magic is that when people say they don't like magic, what it really means is that it makes them feel trepidation when something is happening, and they don't really quite understand why it's happening or when you're trying to debug something, and you can't figure out what's going wrong because of some of that magic that's doing things for you. But if you don't have the background to see inside it, then it gets frustrating. I personally have uttered that complaint about certain frameworks Rails at times when I've been trying to debug something, and I didn't understand the error that I was getting. So I understand that argument about magic, but at the same time, like you said, magic a lot of times is what makes productivity because it's just doing things for you. I know you mentioned Django, and you mentioned Rails. Are you primarily doing front-end type work, or are you doing back-end work or both? What kind of things are you doing with Python?

JT: I do lean a little more back end at this point, so a lot of API work. A lot of our products that we build out are APIs that get consumed all over Red Hat. A lot of them have to do with stuff like security advisories for different products and the state of patches to make them more secure. So a lot of what we're responsible for is the Python infrastructure that serves other apps as APIs. So Django is something you can use for that. There's also a great one on the Django REST framework that we use pretty heavily. And then there's a more minimal one called Flask that we also use for some tasks. So we do have bigger projects where we need a full-fledged web framework. We also have one-off jobs, automation scripts, and things like that, typically all also Python. So it's a good variety, but yeah, I do tend to be a little more on the back end.

And it's funny; one thing you said earlier about magic and not being able to see into the internals, I definitely agree with that. One thing I like about the Django world is that Django does have some of those magic things where you could be frustrated by not having visibility, but they usually have workarounds if you need that fined tune level of control. So one example of that is with Django, you use an ORM to map classes to the database, and it has its own language. It has its own methods that you typically work with. But if you need to write something really just outside of those constraints in SQL, it gives you a backdoor to write raw queries. I find that I like magic as long as there are sensible options provided that you can get around it when you want to. I guess that's what I've liked about the Django world.

Kirk: Active Record in Rails does the same thing. If you want to write direct SQL, it's no problem. It's right there at your fingertips to write. There are times I've found when that's an absolute must in order to really get the best performance out of a problem, although most of the time, the ORMs just figure it out and do it pretty well. Kind of rolling back to what you said at the beginning, you said you started out your career while doing Java in college. So did you do any learning, any software, anything like that before you went into college, or did you go into college for software engineering? You went through your college program, and then you came out, and you're like, okay, now what kind of a job can I get with what I learned? How did that progression go for you?

JT: I have a very roundabout story about how I got into tech. So I was a pretty smart kid. I did write a little bit of code as a teenager, but I didn't have any concept that it was a job. My parents wanted me to be a lawyer even though I would have been a terrible lawyer; it just wasn't something my family was aware of. So I graduated high school early in 2007, and I was planning to go into college for graphic design, but then the economy went really bad. And my older sister, who had gone to college for an art discipline, talked me out of it. She said, "No, it's way too tough right now. Go for something sensible." So I originally went to school for business for the first couple of years. I hit a little bit of a fork in the road where I wasn't sure it was the right thing to do, but I didn't know what I wanted to do with my career yet. And I just felt like I needed to pause and figure out more before I kept going with my schooling and student loans and all that. So I took a couple of years out just to work in the workforce, and I tried a few different things. I worked mostly office jobs, and at some point, I found my way into doing Department of Defense contracting work. I actually used to have a security clearance and all that, even though I never used it for anything cool. The only thing I used it for was getting lost in Fort Meade trying to find the Christmas party for the most part. [Chuckles]

But anyway, working in the DoD world, I got exposed to technologists, and they also paid for me to get a couple of tech certifications. Around that time, I started doing stuff like Code Academy on my phone just to learn by myself. I started reading software engineering books. I started taking courses through Coursera and that kind of thing. And I found out I really liked it. It was so much more interesting than what I was doing. So I took some time I started building a portfolio. I started going back to school for software engineering, and I'm actually still in the tail end of that. I have about two software engineering classes left, and then my degree is done. So I'm still actually in the midst of that. It's been a very long path, but yeah. Anyway, so the portfolio building luckily got me a job while I was still in school. And so, for the past four years, I've been in the field full-time. And last year, at my previous job before Red Hat, I was actually promoted to dev lead. That was kind of a cool moment, just considering that I did have such a roundabout path getting into tech. I have worked really hard, though, and I just love the material. It's been a really cool journey, not to be too cheesy.

Kirk: I actually have, I guess, a follow-up question on this because one of the things that gets debated a lot is when people are looking at the software field at getting into the kind of stuff that we do, there's always some decision-making that goes into it. I have a daughter who is actually in this position right now.

JT: Oh, yeah?

Kirk: It's this thing of okay, so you can go to college, you can get a four or five-year degree whatever it takes in software engineering or computer science or something like that and then enter the workplace. There are the options of going to a code school of some sorts and doing some super intensive six, seven, eight months, and then trying to get a job. And then there's the sort of in-between route, which is kind of where you came from where you get some experience with other things with a variety of things, and you start doing some self-teaching may be combined. Like you said, you got a couple of certifications in some things, but you have this sort of self-taught pathway that develops a body of work that you can then use to represent yourself as you go and get a job. And I don't think that there is any one right answer to the way to go; it's trade-offs. If you could go wave a magic wand and rewrite your history, would you still pursue it the way you did it, or would you change something about it?

JT: So that's a great question. I do know that a lot of people have a hard time conceptualizing either self-teaching or going to a bootcamp or whatever, and I understand that. I think that some people look at it like this is a really tough field to be in; there aren't shortcuts. And I agree with that. I’ve had to work really hard to make up for not having the degree in the first couple of years I was in the field. But at the same time, I think some people are just making the best decisions with the resources they have. And at the time I was doing that, I didn't have the resources to go back to school; working in tech has given me those resources. I do tend to respect however people get in here if they can hold their own and contribute to the field. For me specifically, there's something I found out about way after the fact, like, I was already almost done with my degree, so it was too late for me. But I found out that there's an open-source software degree, which especially being a Red Hat-er now, the idea of an open-source software degree is so up my alley; it's like catnip. There's an open-source software degree; it's hosted on GitHub. And basically, it's a curriculum that seems really well thought out. They do everything from compiler design to the hands-on programming courses with Java or what have you and just seems really well thought out. And if I could go back, I think what I would do is I have seen self-teaching be a challenge in terms of structure, but what I've had success with is our industry is notorious for using LeetCode code challenges for interviews. In the past, I've had groups get together to do stuff like that to learn algorithms together. And I found a lot of luck with the group structure. So if I could wave a magic wand, I think I would go back and do the open-source degree with a study group to get rid of the isolation or the lack of structure that can be an issue learning on your own.

Kirk: I was going to ask you since you're still in the process of getting your degree, what you found was the most valuable thing about that university structure, but I think you just answered it, that it's the ability to work in a group and to have that group support while you're trying to tackle things that might be difficult or hard to motivate yourself for individually. Is that what I was hearing from you?

JT: Yeah. It's a little bit of that. I think even more, though, it's hard to overstate what an insecure experience it is to be a new developer. So when you get lost, you just don't even know which way is up. So I think the group camaraderie and seeing that other people are in the same boat and maybe getting a pointer when you're stuck. I think self-learning can be extremely lonely when you're in that really first vulnerable phase. And it's so hard to even get yourself unstuck on the early things that you stumble on. So I think the group probably is more helpful on that level.

Kirk: Oh, that's interesting. Yeah.

JT: I do know people that have issues with structure. I love code, so I haven't had that much of an issue with like wanting to do what I'm supposed to be doing in terms of studying. [Chuckles] But it probably does help there too.

Kirk: Interesting. That makes a lot of sense.

JT: So how did you get into tech?

Kirk: How did I get into tech? Well, that is an interesting question. Basically, when I was 11, I took a summer class that the local college was offering on computers, and the local college had just gotten a microcomputer; the word was micro, but it was actually the size of a refrigerator.

JT: [Chuckles]

Kirk: And so I learned some basic programming. It was a VAX/VMS system. And I learned some basic programming that summer on this VAX/VMS system. And then after that, my parents, who were both teachers, said, "Hey, why don't we spend the outrageous sum of money to buy a computer for Kirk?" Relatively speaking, I didn't have an appreciation for it. And when you look at what teacher's salaries are, and you look at the fact that back then, an Apple II Plus still cost $2,000, that was an outrageous sum of money. And so I got an Apple computer, and I lived and breathed that thing during middle school and high school. And so then I went off to college, and college was an adventure in the not-good sort of way. I studied computer science, but I also studied English education and occupational therapy and deaf education, and a whole bunch of things. And in that timeframe, I got a job doing IT support and that sort of thing for an office at the university. And I had started using Linux very, very early pre 1.0 like 1991.

JT: Nice.

Kirk: So I'd done that for a few years, and then I discovered that one; I really didn't like being poor. And two, I had the skills to go out and get a real job. And so I went out, and I got a full-time job in Denver, and lo and behold, that turned into a full-time systems administrator job that turned into a full-time software developer job, and away I went. I actually had the title of senior software engineer at my third job, just self-taught, and then it just cascaded from there. I've done a zillion different things over the years. And it was all self-taught, and it was all self-taught because I was really bad at college but really good at sitting in front of a computer and figuring things out.

JT: It's been really funny going back. Some of the college assignments are pretty terrible. I kind of think if I would've gone to school before working in the field, I don't think I would have thought it was for me like building calculator apps over and over again [Laughter] payroll apps. They've got a laundry list of boring assignments. They're really trying to talk people out of finishing that degree in computer science. [Chuckles]

Kirk: And I do have to say that my experience as a computer science student that there were valuable things from it. There was some stuff that I would not probably have learned on my own or wouldn't have learned as readily on my own. I learned C, and I learned a lot of things about low-level data representation and things like that, that would have been harder to learn on my own, but which even now, years later, when you're dealing with Ruby or Python or whatever, most of the time, you don't have to think about those low-level things but sometimes knowing them really helps. And those are things that are hard to acquire in a self-teaching situation unless you make it a point to specifically acquire those skills.

JT: Yeah, definitely. Well, that's cool. I always like hearing people getting here. So you said you had an interest in education in college at one point. I bet that's a good affinity to have in DevRel.

Kirk: Yeah. I was going to be an English teacher, and then once I discovered -- I always liked languages; I speak several languages. And when I learned American sign language, I decided rather than being an English teacher; I want to be a deaf-ed teacher. And so I've always had that affinity for education for learning, and yeah, so it's started to come full circle now. Coming back into DevREL marries all of the years and years of experience with engineering with that desire to teach, and so it's a nice combination in that respect. And that actually leads me to a question for you. Right now, you're doing security work. You're working a lot with Python. Your bio says that you work a lot with Vue. And I wonder, and nobody knows where they're going and where they end up going is often a surprise compared to where they thought they were going to go, but if you had to guess, where is your career going? Where would you like it to go? What do you aspire to from where you're at right now?

Kirk: That's actually a great question and something I've been workshopping in my own life recently. So I'm in the tail end of the software engineering degree. And I'm very blessed that Red Hat pays for my education. So they don't know I'm here, by the way. I'm not being nice to them because this is like a plug Red Hat thing; they're just cool. [Chuckles]

Kirk: Oh yeah.

JT: But anyways, so since I can go back again, I started thinking, oh, what if I got a Master's? And the funny thing about being in this field is I don't think I realized how much image management there is. There was a long time where I just thought like, oh God, am I good enough to string lines of code together to even be paid to do this work? [Laughter] That was my immediate priority. And I never realized that you have to be careful not to specialize in something that might be in a downward trend or spread yourself too thin, so you'd seem shallow or go too deep and have difficulty finding jobs because you don't have a broad skillset. There are so many different tight ropes to walk to be in this field successfully beyond just being able to string working code together. So. I've been at a point now where I've done the generalist thing my first three years in the field. I worked really heavily with Vue, like you said. I was kind of an early person to get into that. And actually, I launched two new products building out all in Vue for them, so I'm pretty good at that. But I've since settled down a little bit more into back-end, and I've been wondering if I should add not like another code specialty but another subject area specialty: Should I learn about AI? Should I get more into cloud stuff? And the final one I'm kind of contemplating is I'm pretty good with databases. So I could also go farther down that path maybe get into data engineering, I guess, would be the outcome of that. And it's really hard to pick for the same reasons, yeah, just the same lot of image management. What's the right call? Is the field going to get saturated? Am I going to enjoy it? Am I going to be too typecasted into one type of role if I get this additional specialty? So they're kind of tough questions. I didn't know that that would continue to need so much attention the more senior I got. I thought it was like you just do good work, and you would get plugged in to where you need to be. There's actually a lot of mental overhead, I think, in figuring out what your right spot is. I'm still working on that. [Chuckles]

Kirk: Yeah, and there is. And it's one of those things where you only really know in hindsight whether you made the right decision or not, which makes it trickier. Databases, this is something that popped out at me when you mentioned you're good at databases, and your bio says that you've done a fair amount of stuff with SQL development. What databases do you use? Do you have a particular affinity for one platform or another? I'm just curious.

JT: Yeah, so I do really love Postgres. That’s my favorite by far. I feel like it has sensible defaults on everything. I joke that I do not have good juju with Oracle, and I think that's why I don't like MySQL as much. [Laughs] I think upstream way upstream Oracle owns that. But I've also been getting a little into Mongo recently, which has been interesting. I really liked their Mongo Atlas hosting platform for pet projects. That's something I use quite a lot, and I write a little bit on Node, so that works really nicely with Node. But yeah, Postgres is my main one, and I think that liking databases so much probably informs maybe my one controversial tech opinion, which is that I'm a little bit of a no-ORM person. I like writing just straight SQL when there's not a reason not to. You have to be able to really trust your team, though, if you're going to be doing that because there's so much pressure on the skill set of people to write reasonable SQL, and it can go sideways really fast.

Kirk: SQL is one of those things where it's a language just like any others that we deal with, and easy things are easy, but the hard things are sometimes really, really hard, and people can go in the weeds really easily. So one of the things that I've run into and touched on it when we were talking about ORMs is that sometimes when you're dealing with a certain problem in an application, no matter how good the ORM is, it is just going to do something when it pulls the data that is not optimal. And in some cases, it's really highly detrimental to the performance of the application. And I know I've got a few examples of that in my own head. But I'm wondering if there's anything that you can think of where you ran into it. And you're just like, oh yeah, this may be easy with the ORM, but the performance is just not -- I can't do this with the ORM and have the application perform the way I want it to.

JT: I have had a few situations like that. I feel like I might not remember the exact circumstances off the top of my head, but I have had a few circumstances where I go to figure out what exactly the ORM is executing. And then, I'll usually take that to the database, and I'll use EXPLAIN to see what the execution is. I have, from time to time, found some weird things that needed to be reworked. But like you said; usually, that's where I pull out the raw to deal with it, to just kind of sidestep it. But I will say I feel like it's probably not that surprising that the ORM is set up to deal with the broad use cases, and then very occasionally, there's something you're doing that goes against the grain and makes the heuristics not make the best decision. I will say, left to my own devices, the no-ORM way can be very risky though because I've seen some people write some SQL that not to be too technical and boring, but people doing stuff like Cross Joins, which basically you should almost never ever do in your life. It joins every record in the table with every record in the other table. There's really no good reason to ever do one. I've walked into situations where people didn't have an ORM reigning them in, and I've seen some really weird stuff. So it takes a high level of trust in the SQL knowledge of the people involved to be willing to walk away from the ORM even if, on occasion, it does do something a little weird that you have to work against.

Kirk: Oh yeah. And actually, the thing that you were talking about where you're mostly doing API work, I don't know if you ever played with this, but one of the things that I found that is really useful in Postgres, if you're writing direct SQL anyway and you're doing API work anyway, and your upstream consumer is JavaScript of some flavor, and it is expecting JSON formatted data anyway, do you ever write your SQL, write your queries in such a way that you have Postgres just return your structured JavaScript directly rather than doing that in the API layer?

JT: So I haven't, but I actually like that idea. I think it's mostly just because a lot of the stuff I work on right now we're heavily invested in the Django ORM, so it would be working against the grain to do that. But yeah, that is something I would be open to doing. Postgres is nice in that it offers some formats like BSON. So I actually like that idea. I do like simplifying it that way because when you don't use an ORM, getting things into the right format again can actually be sort of a pain point. I do actually like that concept.

Kirk: You should explore it because I found that at least for certain problems where you might otherwise be spending a lot of time at your API level, processing the data the database is giving you in order to generate some JSON package that you're going to send upstream, you can make huge performance gains just by asking the database to just do all that work for you upfront. It's pretty neat. And so yeah, if you haven't played with it, I would recommend definitely taking a look at that and playing with that.

JT: It's funny. I have an app in my history where I think that actually would have been a really good step. I didn't work with it long enough that I think I would've gotten to implement that, but there's something I'm thinking of in my past where that probably would have been actually a beautiful solution.

Kirk: I have one other question. Some software developers go to work; they do their work. When they're done doing their work, they go home, and they're done. They have other things to do with their time. And some people have projects on the side and do other things and explore other things. Their leisure time is sometimes still wrapped up behind a keyboard. And so I'm just curious which general camp you fall into, and then I'll follow up based upon your answer.

JT: I definitely respect people who switch off because they don't want to burn out because that is really a problem in our field. But I definitely fall into the camp that I have a million side projects going on all the time. I do a lot of volunteering as a code mentor, and one thing that came up recently at a place I volunteer for is they need a solution a little bit like a Codepen or a Repl.it but for SQL. And there are solutions like that available, but they have a couple of drawbacks, which are typically that you have to rebuild the schema and then rebuild your seed data every time you change anything. There's no persistence, really, and it makes it a little rough to use it. You have to keep rerunning code over and over. And so I wanted to come up with one that -- I'm actually in the middle of building it right now. It persists in your database. And so I had to come up with a scheme to map database names to UUIDs so that people wouldn't have collisions if two users wanted to name a database customers, kind of like fun challenges like that. But I have that going. I keep joking that I'm going to build a dating platform for programmers called date.now [Laughter] and then you would open a pull request if you want to go on a date with somebody...

Kirk: [Laughs] That would actually be kind of hilarious.

JT: [Laughs] It would be, but then you get together with somebody, and one of you likes Java, and the other doesn't, and it just all falls apart. [chuckles] So probably best that I don't build that one. [Laughter] So I have that. I do hackathons. I did a Major League hackathon event earlier in the year where we made an app that would text you the outlook of the coronavirus numbers in your state, and it would give you a heat map, and you could subscribe to different states where your relatives were. That was a really fun project. I always do Hacktoberfest every year. I always get the Hacktoberfest stickers because I'm a huge sticker person and then the code mentoring, and then there are other side projects I won't bore you with. But I was kind of looking at it as I don't do actually a lot of open source in my free time just because when I'm doing stuff for fun, I want to have complete creative control. I don't want it to feel like work. I want to be flighty and just whatever whim hits me. I want it to be a very fun activity so that I don't get sick of coding. So I have a few ground rules that I think let me spend so much of my free time doing side stuff, but I do a lot of stuff in my free time, and that's not the only way to be successful. I know people who are better coders than me that don't do a lick of work in their free time, but I like it. And it felt important to me earlier in my career to build my confidence. So it's something I'm glad I did I think.

Kirk: You mentioned code mentoring several times. What is the context of that? What kind of code mentoring do you do? I have a couple of high school students that I meet with on a regular basis over Zoom to mentor them and basically teaching a class in coding, more or less to supplement what they can get from the high school here. And so I was curious what kind of thing you do.

JT: I actually have worked with a couple of different orgs; one of them is called Code the Dream. For them, I would meet with students after the instruction, and I would help them work through code assignments and do a little troubleshooting, and also sometimes do demos for them. Code the Dream focuses on getting underrepresented populations into tech. It's a free program that lasts for several months, and it has a structured curriculum, and then it has structured groups afterward with teachers and with other students to give a boost to self-learning, give it a little more structure. And it's actually a really cool program. After they're done with the curriculum, they work as interns building non-profit websites to solidify their skills and get real-world experience. So I've worked with them. That's been a great experience. And then, I also worked with B Corporation, which is a cool business category; they have to give back to the community. There was a B Corporation near where I am that runs an intensive program to train people in full-stack JavaScript. So I worked with them a little bit more on the career side at that point. So I would help people with their resumes. I would help them get to learn the local employers what people are looking for when they're interviewing junior candidates and just more general advice for that one. But both experiences have been really great. I think it's really important to do. I felt on my own when I was learning to code because I didn't really know a lot of people in the field. And so I've wanted to go back and be what I wish I would have had when I was just starting out.

Kirk: That's really cool. Yeah. That makes a lot of sense. I find that the mentoring thing is a nice way to just give back a little bit on all of the experiences and opportunities that I've had, and I'm always interested when other people are doing mentoring, just how they're approaching that. So that's really neat that you're doing that. So do you have anything else that you want to mention or talk about? Anything that you want to circle back on?

JT: I want to say I definitely enjoyed talking with you. The one thing I mentioned earlier, the open-source software degree that is something you can find on GitHub. If you look for OSSU, I think it's Open Source Software University or something along those lines. If there is anyone interested in that, yeah, I do think that would be my go-to way, and that's what I tell people considering getting into code. I usually would start them down that path and say, "Find a study group that's learning similar things." But that's how you can find that resource if anyone is interested.

Kirk: Oh, that's fabulous. And hopefully, some people will listen to this and take a look at that because that's fabulous. The other thing that I would just throw out along those same lines is that there are some code schools that also have their curriculums available for their open-sourced. I know the Turing school does, and I know there's some others that do. And so there are those resources available. And if anybody is listening to this and just thinking I might be interested in doing that or learning that, definitely look up some of these resources because it is available, and it is accessible.

JT: Very cool. I didn't know that. That's really great to know.

Kirk: Yeah, the Turing school, I know they have a front end and a back end curriculum, and they're both open-source, so you can go see the entire curriculum. Thank you very much for joining me and just having this chat. It was very interesting. I learned a few things out of it. And for everybody that's out there, thank you so much for listening to Polyglot. I hope you all have a really great week, and I hope you have a great week too, JT. Thank you.

JT: Thanks. Great talking to you.

Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. Right now, we're running a hackathon in partnership with dev.to called Hack the Planet, where we're giving away $20,000 in cash prizes along with many other fabulous gifts simply for participating. We would love to have you join us. You'll also find news there shortly of FutureStack, our upcoming conference here at New Relic. The call for papers for FutureStack is still open until February 19th. I encourage you to stop by and submit a proposal. We would love to have you join us. We'll see you next week.

Discussion (0)