#018 - Data Engineering for Gophers with Miriah Peterson

Miriah Peterson (00:00.138)
I say fuck it, you'll edit that out.
Lane (00:02.699)
Actually, I probably won't edit those out. I'll probably leave those in.
Miriah Peterson (00:04.358)
Oh, dang it. Okay, I better keep it clean or else my mom's gonna get mad.
Lane (00:10.544)
Oh, that's good, yeah. I don't think my mom watches these. I might get an angry phone call later, I don't know. Cool, Mariah Peterson, am I saying that right? I'm so excited to have you. Okay, cool, you're from my neck of the woods. We're both here in Utah. You're here in Utah today, right, I'm assuming.
Miriah Peterson (00:24.479)
You are, you definitely are.
Miriah Peterson (00:34.022)
Oh yeah, I'm at home, Spanish fork, using my fiber internet.
Lane (00:39.384)
Oh, Spanish fork. I'm an American fork. We've got all the forks of Utah covered.
Miriah Peterson (00:43.722)
There's only two.
Lane (00:46.528)
Yeah, yeah. Okay, cool. This is so exciting. Obviously, I've met you here locally at Go Meetups and I'm aware of the myriad things you do in the Go community, but I think we'll have a really interesting conversation. I'll try to keep it very kind of focused on community and Go and all the things at least that I know you for, but why don't you take just a second and introduce yourself.
Miriah Peterson (01:08.954)
Oh, sure. Yeah. So pretty simple. You already said my name. Um, I've been in software for five and a half years, formally, like formally employed. Uh, you know, we all, everybody, it feels like everybody's took a coding class in high school and it's like, oh, I can do this. And then, you know, like I had a couple of off jobs in college, but post college, five years. Um, I have.
been professionally coding in Go for all of those five years. I have run Go meetups. I have spoken at Go conferences. I currently do live courses with O'Reilly on Go, Go web services. I've done Go memory patterns. I'm going to be doing Go data tooling soon. And that's the next one that I have to write. So that'll be fun.
Uh, and I also organize a local go conference. Conferences are harder than meetups, but they're super fun. Um, yeah, I currently find myself kind of in the data space. I'm definitely a software engineer, not a data engineer, but I do work in the data stack. Um, so my stakeholders, instead of being, you know, customers or paying people, they tend to be.
data analysts or data scientists, machine learning engineers, which has its own fun bottle of problems. But I really like data problems. I would rather query in SQL than write an API call. So I guess.
Lane (02:49.656)
Yeah. So this is actually really interesting and I want to call attention to this because I think I've had a, I mean, just hearing your story a little bit, it's, it's very similar to mine. I don't know if that's just cause we're both from Utah and like to write go, but like most of my career is writing go. And I always call myself a backend engineer, but just a lot of the work tends to kind of be very data related, at least the companies around here. Um, what is the difference in your mind? Between.
a backend engineer and a data engineer.
Miriah Peterson (03:24.106)
That question keeps getting muddied. The more and more AI companies get funded, because the more AI companies get funded and the more money that goes into these data-centric tools, the less engineering is required for your data stack, right? Like they're definitely more focused on enabling the data analysts or the data scientists.
Lane (03:33.168)
Ha ha!
Miriah Peterson (03:52.386)
giving tools, it's the same thing you see in software, right? You can have somebody build their own website or you can just do it on Wix. Anybody can build a website, right? So it's the same kind of thing. So traditionally data engineers are the people that, and I've like, this is like the definition since the beginning of computers. Data engineers are the people that built datasets and managed your enterprise data warehouse.
Lane (03:59.589)
Yeah.
Miriah Peterson (04:21.546)
So when I say building, like they are literally planning out how entities relate to other entities so that queries can be run efficiently. Ever since big data, this concept of the enterprise data warehouse has been muddied. And so it's become a lot more, how can we build pipelines? But very much it is using pipelines to construct datasets.
Lane (04:41.832)
Mm-hmm.
Lane (04:49.606)
Okay.
Miriah Peterson (04:50.15)
So that is the traditional data engineer. It's all about constructing the data sets and how can you automate that construction of data sets? Whereas I see software more closer to building the services that you use for those processes. So, right? So when I say I'm a software engineer, but I like data, I would be building this, the software and systems used to manipulate those pipelines as opposed
worrying about how the data is interacted with in those pipelines. There's a lot of overlap, but my, my head space always goes to the system first and the data relationships second. So that's, that's kind of how I, why I still think like a software engineer. Right. And a lot of software engineers, I feel like always think about the system and sometimes forget about like they interact with databases all the time.
Lane (05:26.53)
Yeah.
Lane (05:36.968)
Right.
Miriah Peterson (05:49.818)
always interacting with data. Data's everywhere, but it's, where does the data sit in your mind? Is it the first thought, the second thought, the last thought, something you just threw away, those kinds of things.
Lane (06:01.1)
Yeah, that makes sense. So you're seeing yourself as a software engineer that kind of dabbles in the data side, and that's primarily because you're actually writing the software that does the data processing rather than like maybe configuring the software or using the software. Yeah, that makes a lot of sense. Now, the first, so when you first explained data engineer, like, I don't know, a few paragraphs back in the transcript,
Miriah Peterson (06:14.972)
Exactly.
Lane (06:27.268)
You said something that made me think DBA. Like it sound, like if I squint, it almost sounded like database administrator.
Miriah Peterson (06:33.178)
I mean, it would have been DBA, right? They would have very much overlapped in the 80s and 90s. But DBA is not the same thing as a data engineer now because it's no longer just interacting with the data warehouse, right? We're not just using Oracle databases at scale. It's very much about flow and automation. And that's not DBA, right?
And I don't want to discredit a DBA because DBAs are very specialized and a lot of time data engineers do not have the toolset that a DBA has. Like I could never be, I'm not a DBA. That's not my skillset. Can I manage a Postgres database? Yes. Could I manage a partitioned geo global with all of the, no, no. You know, like I'm not going to.
Lane (07:11.077)
Right.
Lane (07:25.6)
Yeah.
Miriah Peterson (07:28.766)
say I am DBA and most data engineers I interact with do not have that skillset. They understand how data interacts, but they're not interacting with it at that kind of gigantic database scale. Like databases are hard. And that's why we moved to things like Snowflake and BigQuery where we don't deal with databases, we just use SQL. It's like Snowflake's not a database. They store everything in like S3.
and then they just run queries against it. Like that's not a database.
Lane (08:01.636)
Right, we're kind of abstracting all of the persistent layer behind this nice SQL interface, right? And then as long as we know how to query it, then we can kind of get stuff done. So I wanna just dive into this a little bit because I don't think we've talked about this yet on the show, and I think this'll be really useful to some of the listeners. So when I picture a DBA, I kind of imagine how it was explained to me in college, which I think is like a snapshot of maybe what a DBA was in the 90s, which is like,
Miriah Peterson (08:07.315)
100%
Lane (08:31.152)
You've got one kind of monolithic database. Maybe it's an Oracle database, maybe it's MySQL. And it's gotten like huge and hairy and complex. Like you said, it's like probably the central system for some enterprise where you've got all your customers in there, you've got all your data in there, and your job is kind of to sit there and like run reports daily. Like, you know, different stakeholders in the business are coming to you and saying, like, I need to know XYZ about our users. Can you like come up with a SQL query and like generate a report for me?
Is that how you're picturing the DBA role?
Miriah Peterson (09:05.918)
I mean, that's definitely part of it. But like running reports can be done by any analyst at this point. I think a lot of what DBAs focus on will be what we classically would call operations. They're worried about the memory management of that DBA, of that database. Are the queries running in the most memory efficient manner? Can we optimize our queries? Are we dealing with query scheduling inside?
the database itself, worrying about stored procedures, making some like oftentimes they'll be redoing how the databases interact, making sure the relational model makes sense, sometimes breaking up models, doing different migrations. Sometimes it is down to like the hardware, like, oh, this server isn't big enough, I need to move it to a bigger server and all of the steps that are required in that hardware migration. That's 100% within the skill set of a DBA, I would say.
Lane (09:35.034)
Right.
Miriah Peterson (10:03.538)
is the operation side of it. And on the cloud, that is a skillset I would never have. So.
Lane (10:10.356)
Right, totally different. And so moving to the data engineering side, like you said, it's much less kind of all those very specific database skills, but you said it's more about flow. And is that because it's like you're working with different cloud systems and you're moving data from one system to another? What did you necessarily mean by that?
Miriah Peterson (10:32.418)
A lot of it has to do with the fact that we have multiple data sources now. So something we commonly, I don't know if you've dealt with the concept of sources and sinks when you talk about data flow or eventing, but when you transfer data, you have a source of something that creates data and then you have a sink, the place where the data is cached or stored.
And you often in backend systems have many sources and sinks that interact in different ways for different caching mechanisms. What you add a layer of complexity when you do data engineering is now not only do you have these internal sources that you're trying to put user into a central sink or to a series of managed things, usually an S3 or a data warehouse or they used to use things like Kadoop for this. You also have
Lane (11:23.751)
Yeah.
Miriah Peterson (11:25.662)
external sources, right? You're gonna want your billing information, right? So whether that's managed through a bank or through a Stripe, you're gonna have advertising information, Google Analytics, you're gonna have eventing information from your sentries or your segments or your rudder stacks. You wanna understand how customers interact with your data. You wanna understand marketing analytics. You wanna understand business. You wanna understand finance, right? You're not just trying to figure out
is the thing up and running on a live, or are we sending the API calls correctly, or what's in the API calls, right? It's not just client data and metrics, it is now also all of the business functioning data. Everything to make the business run tends to flow into this thing and then be incorporated with that data we were using for that product too. So you end up having a multi-layered, like you can get multi-layered reports.
But you have, again, third party sources, internal sources, sources from different departments. And then on top of that, you start layering permissions. Do you have protected identity of PII or PCI or HIPAA compliance or different kinds of data restrictions and permissions that you have to line on top of that and manage that affect your sinks? So it's like, can you store it in multiple places? It's.
It, it, yeah. So basically the multiple sources, where can they go and can everybody access them ends up being those flows that you have to be aware of and manage.
Lane (12:57.992)
We have to be careful, we're scaring everyone away. That sounded very complex. Hahaha.
Miriah Peterson (13:01.41)
Um, this is why people do not do data problems. Um, this is the kind of stuff that excites me. Like I love that thing, which is why I tend to go to these data problems. It's not for everybody, but it's, um, it's fun for me, but I, uh, but there's a definite need for people to do it. Right. Like we have a lot of data.
Lane (13:11.867)
Yeah.
Lane (13:17.158)
Yeah.
Lane (13:25.52)
Oh yeah.
Every company has tons of data. So I wanna kinda like play back what I just heard you say and try to like dumb it down, both for myself and also hopefully simplify it for the listeners. So, okay, data engineering from like a really high overview, you've got data sources, this is where data is coming from, right? So you mentioned third party. So for example, on Boot Dev, we use Stripe for billing.
Miriah Peterson (13:37.862)
I said a lot of words, so we might need a summary.
Miriah Peterson (13:51.543)
Mm-hmm.
Miriah Peterson (13:57.351)
Yes.
Lane (13:58.188)
I could be grabbing data from the Stripe API and that would be a source, right? We might also have internal sources of data. So again, taking the example of boot.dev, we've got students completing exercises and every time that happens, that's an event. And I log that. Would that be like an internal data source? Cool. And then I've got all that data coming in and now when you said sync, we're not talking about kitchen sinks. We're like, like S-Y-N-C, yeah? Yeah.
Miriah Peterson (14:13.396)
100%.
Miriah Peterson (14:23.075)
like a pit like a sinkhole literally like a sinkhole
Lane (14:27.1)
Oh, okay, and so that data needs to go somewhere. What, like, to give an example, like what's one example of a place that data could be making its way to?
Miriah Peterson (14:37.286)
I mean, if you're going to the big ones, people would throw them in a snowflake or a big quarry, a place that they could be accessed in quarry. You could throw them, if you're small, you can put them in a database. DuckDB is a great small SQLite style analytics database. You can throw all of these things in and then you can start to see how the data relates to each other.
Lane (14:54.639)
Yeah.
Miriah Peterson (15:02.43)
And it can give you a picture, right? Like with your thing, if you're talking about Stripe and then your usage, you could start seeing things like, okay, how many of these courses are completed by paid users versus free users? And you can start saying, Hey, maybe I want to grow this segment or wow, we've seen a lot of growth in our free users. Um, do we want to convert them to paid users? Maybe you don't want to convert them to paid users. Like there's different things you can see once you start relating those two.
Lane (15:15.206)
Yeah.
Lane (15:31.44)
Right, that makes a ton of sense. Okay, so all this data is kind of going into a database or I think you used the word data warehouse. Is there a difference?
Miriah Peterson (15:39.638)
Data warehouse or a data lake, yes. So database is a relational data store. A data warehouse, traditionally right back in the 90s was a columnar query data store. So basically it's a different way of scheduling your SQL queries. And then another common one is called the data lake. And this is basically just anywhere you can throw data. So things like S3, things like,
a cloud data store, it's, I mean, they're called high density file stores, HDFS. So it's basically just places you can put raw files where they can be accessed. And then you can put query layers on top of them.
Lane (16:17.288)
Mm-hmm.
Lane (16:25.796)
Yeah, not necessarily optimized for fast transactional queries, but like...
Miriah Peterson (16:28.434)
No, they're not optimized at all. It's like at that point, you're optimizing for how much you can store over how quick you can access it. Warehouses tend to do the, how make it easier to access and not worried about how much you can store. And then databases are the 100% fast access of small amounts of data.
Lane (16:49.948)
Got it. So for your typical, let's just say, software as a service company, SaaS company, say we use Postgres for our back end, the database for our application. Yeah. Would we typically want to shove all this kind of data lake type information in there, or do you usually keep that separate?
Miriah Peterson (16:55.598)
Mm-hmm.
Miriah Peterson (17:02.33)
your services itself, yes.
Miriah Peterson (17:14.826)
I would want to keep it separate. One, because stuff you use tends to have different access levels. I mean, this is a weird security style situation, but I know when you're building a web service, the last thing you want is some random developer querying in production and taking the database down.
Lane (17:27.016)
Hmm.
Lane (17:41.381)
Yeah.
Miriah Peterson (17:43.286)
But if you're doing analytics, you want people querying that production style data. You want the live data. You want the real data. I mean, you typically clean things out. Like you're not giving people access to emails or to addresses or to social security numbers. Like that stuff's gone, right? Well, we've, we've cleaned it up. So it's a little bit more anonymized, but, uh, they need access to what is live. So you wouldn't want that in the same database that your services rely on.
Lane (17:50.98)
Yeah.
Miriah Peterson (18:11.726)
So that's why you would turn to a data lake, right? You might say, okay, well, once a day, I'm going to run a job that copies, you know, the last day's data, puts it in a file and dumps it to my data lake so that the analysts can query it later and have the last day's analytics based on our SaaS products usage.
Lane (18:34.568)
Got it, and so as a backend developer that does data work or as a data engineer, you'd be writing the software that takes that data from the source, like you said, maybe cleans it up, anonymizes it, maybe removes emails, and then dumps it somewhere. Okay, very cool, and this is the stuff you love, I guess.
Miriah Peterson (18:48.638)
100%.
Miriah Peterson (18:54.986)
in a weird way. Unfortunately, yes, this is the stuff I love.
Lane (19:00.908)
I like it too, actually. I know I'm asking all of these questions, but this is what I've worked in roughly for the last decade, and I enjoy it as well. I really struggle building UIs. I really like writing functions that transform data. It's just a simpler world for me.
Miriah Peterson (19:21.026)
Yeah, I agree. I don't like making things pretty. I like making things run fast.
Lane (19:26.608)
Yes, run fast. I love that. Okay, now I wanna zoom out a little bit. So we've talked about, I mean, we've like table stakes defines some of this backend, this data stuff. Obviously you said you've been working in Go for about five years professionally. I wanna go back to the beginning because I did some digging before the episode started and I found out that you have a bachelor's degree in physics. A, like I guess Y and then B, like if, well, let's just start there.
Miriah Peterson (19:48.398)
Oh, I do.
Lane (19:55.705)
Why a bachelor's degree in physics?
Miriah Peterson (19:56.858)
I mean, it's not because of a masochist, a little bit. I a little bit wanted to torture myself. I really like physics. Like when I was going into college, trying to figure out how the world worked and why it worked that way was just by life school. Like I graduated with a, I started grad school and I was like, I was going to get my PhD in physics. Like that was my whole thing. And then...
You know, the story I tend to tell people, because it's a little bit less depressing, is I only went for one semester because during that first semester, they were doing the mandatory careers course. They're like, what are you going to do with your PhD after you've been in this program for seven to 10 years? And I was like, seven to 10. I thought it was five. And they're like, here are your options. You could be a professor, but none of the professors now are going to retire. So you'll never have a job as a professor.
You could go work in a private laboratory and run experiments for the government that are classified, or you can be a software engineer. Those are pretty much only careers for physicists. And I'm like, I'm not a software engineer for... They had, at the time, most professional data scientists at the big companies had PhDs in mathematics or physics. Because...
Lane (21:06.128)
They listed software engineer? That's, that's kind of crazy.
Lane (21:18.733)
Okay, yeah, that makes sense.
Miriah Peterson (21:22.082)
Building machine learning models is hard. Like the research for machine learning models is hard. Using machine learning models, training machine learning models is very different than their research for the machine learning model. So yeah, if you go to physics and you look at people's pedigrees, a lot of them have PhDs in math, statistics, or physics, because they all have an overlapping skill of advanced calculations.
Lane (21:33.319)
Yeah.
Lane (21:44.384)
Yeah. So it's interesting though that they said like software development or I'm guessing they didn't say web development.
Miriah Peterson (21:49.61)
They definitely didn't understand the landscape. These professors, they want you to be a professor even though they know there are no jobs as professors. I was groomed to, not groomed, groomed is the wrong word, encouraged in my undergrad to get a PhD. They wanted you to go to graduate school. They wanted you to get a PhD. You studied physics, you have the passion to get a PhD. And that to them is the only true option.
Lane (21:52.906)
Okay.
Lane (22:01.093)
Okay, good.
Miriah Peterson (22:19.378)
It's kind of a little bit religious, but for the people that fail, that are not selected by the divine, they can go work in software. And, um, the truth of it is within two years. So I left after one semester, got a job within three months because the market was such that they needed people who could speak intelligently. Like that was my skill at that point in time.
Lane (22:19.735)
Okay.
Miriah Peterson (22:50.17)
I went back to go see my undergraduate advisor within a year. And he said, can I ask how much you're making? I told him my salary. He said, that's how much I make. And I was like, well, it looks like I made the right career switch. Cause yeah, if my cap and he'd been teaching for 20 years, if the cap was a hundred thousand dollars for a university professor, I, that's not. That's quickly not because not going to be a livable salary. You like just.
Lane (23:00.092)
Ha ha ha!
Lane (23:18.599)
Right.
Miriah Peterson (23:19.574)
Honestly, you're not buying a house with $100,000 in the market in Utah right now.
Lane (23:21.048)
Yeah, that.
Lane (23:26.288)
Yeah, it sounds like the real golden ticket was not being picked by the divine.
Miriah Peterson (23:31.13)
Not being picked by the divine lets you afford a house and food, so yes.
Lane (23:37.668)
Yeah, this is cool. So you're the first person I've had on the podcast with a degree in physics, but a lot of my guests have had, yeah, like degrees in all sorts of things that aren't software development, right? Electrical engineering, math, like it's all over the place. And a lot of folks I've found are finding their way into software development, whether it's data engineering or backend development or web development, just, you know, we need smart people in the industry.
And that's basically the bar. Like, are you smart and are you willing to put in the work to learn all this stuff?
Miriah Peterson (24:14.162)
Oh, it's definitely not easy. I think, but a lot of the motivation to keep learning, right? Like, I don't know how well they sell this to people coming in. A lot of people will, again, I have a nephew who's attending a boot camp right now. And I'm really trying hard to make sure that the boot camp's not overselling expectations. I pretty much tell them you're not going to get a job. Like, just because that's the market right now, like you're not getting a job.
Lane (24:35.964)
Yeah.
Lane (24:43.112)
The market's rough. Yeah.
Miriah Peterson (24:44.738)
Um, but like the truth of it is when you walk out of that bootcamp or that four year college degree, you don't know anything, you do not know enough for that job, but can you prove through your interviews, you're willing to continue to learn for your entire career? Great. Now you're hireable. And I, if you have a degree in physics, that's not a skill that like, that's not something I have to defend. People know, Oh, clearly this person really likes to learn because they learn too much in their undergrad.
Like they spent too much time in the books.
Lane (25:16.652)
Yeah, I couldn't agree more. So my perception of this has been like, like if we rewind to like 2018, 2019, definitely 2020, we had, I mean, we know we had a tech bubble, like in general and hiring was out of control, but a lot of like, I don't know, tech influencers, just people online talking about how easy it is to get into the tech industry. And I always have kind of pushed back against that because like I...
Miriah Peterson (25:43.43)
It's the opposite of easy.
Lane (25:45.368)
Yeah, like I was hiring at the time and I would see how many people were applying for jobs that I had to turn away, right? So, and a lot of those people, you know, were self-taught or bootcamp graduates. So, you know, at boot dev, we always talk about this, but like, it's gonna take longer than you think it's going to, but if you keep making consistent progress, you can absolutely get.
Miriah Peterson (26:06.858)
100%. You have to keep making progress and like, great. So you start in tech support. Find a company that lets you start in tech support and work up. There are companies that do that. That is their preferred way of promoting people to software engineering. Like maybe they don't hire entry level, but they do promote to entry level. Like if that's the way you do it, that's an amazing route. Because then when you start the entry level job,
You have the domain knowledge to focus exclusively on learning software, best practices. Like it's totally fine. And the other thing I agree with is that you said is it's not hard to get a job in the tech industry once you have a job in the tech industry. It's that first job that somebody has to take a risk on you and that risk will either fail completely or pay off.
I got lucky somebody took a risk on me. You got lucky somebody took a risk on you. And like that you have to prove yourself that like that's what people don't say. It's like the, it's the entry level jobs that are hard to get. Senior jobs are easy. Like even though the market's hard, there's still a lot of senior level jobs. Like there's definitely less than there was, but there's still a lot.
Lane (27:25.284)
Yeah, tech is a newer field and we don't have this like, you know, if you go look at the trades, for example, there's like this very kind of structured path that you go from like, you know, I think you start as like a journeyman, right? And you work as an apprentice and you kind of work your way up and there's this way to get in. Like tech has moved so fast. Like we don't have any structure to this. Like it's exactly like you said, you're literally just out there trying to get someone to take a chance on you so you can get a few years of experience under your belt. And then once you have that,
Miriah Peterson (27:30.242)
Mm-hmm.
Miriah Peterson (27:36.396)
Yeah.
Lane (27:54.056)
People be like, oh, like somebody paid you for two years to write software, like you must at least be this good. Like, so I'll hire you, right? It gets so much easier.
Miriah Peterson (28:00.286)
Yes. You have two years of experience? Oh good. Now I can hire you. And we'll get like, it's, it's insane how it just, that it speaks for itself.
Lane (28:12.568)
Yeah, but like I was talking about, it was a few episodes back with a guy who streams on Twitch, his name's Trash, Trash Dev. He was talking about how, yes, yeah. Okay, perfect, yeah. It was talking about how like a lot of the people I've interviewed, and I should actually just ask you as well, had like really weird first jobs. Like Netflix wasn't his first job, right? Like he was doing like mainframe programming. I was writing Go that ran on Raspberry Pis for my first job.
Miriah Peterson (28:20.206)
Oh, from Netflix. I watch his streams.
Lane (28:42.088)
that we installed on bridges to read. It was just weird. It was just weird stuff. It wasn't this sexy fang company. What was your first job?
Miriah Peterson (28:52.681)
Um, my, well, I, the job I had in
Lane (28:55.952)
You don't have to tell us the name of the company if you don't want to, but just like, how was it? Yeah.
Miriah Peterson (28:58.738)
No, the first, my first post-college job at Nav was a fantastic job. And it was literally writing Go microservices. Like it was the on, that were deployed to Kubernetes on AWS. Like it was literally the ideal job. Um, and college, I did have a job working for the university doing QA and then it magically turned to web development, half three through my tenure yet there. Um, where I did QA for their cold fusion site.
Lane (29:07.899)
Oh, that's amazing.
Lane (29:12.068)
Way to disprove my point, alright.
Miriah Peterson (29:28.234)
Um, and then we switched to doing development on Drupal. We were migrating raw PHP sites to Drupal. Um, and I did not like any of, well, I, the QA was fine. I was fine doing QA. Like I'll click buttons and write a line of cold fusion. Like that's fine. Drupal migration. That was stupid. Like that, that's, that's the one I, uh, I quit to go. I, I made.
Lane (29:44.772)
Yeah.
Lane (29:49.404)
That's the one, that's the job I was referring to.
Miriah Peterson (29:56.574)
More money. I quit that job to go make more money. TA-ing physics.
Lane (30:01.068)
Oh wow. Yeah. My first software development job I was paid $15 an hour.
Miriah Peterson (30:06.634)
Okay, I didn't make that much in college, but I did make more as a physics TA than I did migrating Drupal sites.
Lane (30:14.6)
Wow, yeah, that's pretty crazy. But I mean, I was also in college at the time, and like it's just, yeah.
Miriah Peterson (30:18.818)
But you weren't working for the university, were you? That's a... A university's like to underpay people.
Lane (30:21.484)
No, this was a different company.
Lane (30:26.72)
Yeah, that's been my, that's been my, it's what I've gathered, I guess is the way I'll say it.
Miriah Peterson (30:31.618)
But then, I don't know, it was nice. I could do homework at work. So we'll just leave it at that. Now that's the one, the main benefit of being a TA was doing homework at work.
Lane (30:36.068)
Yeah, that's true. I couldn't do that. I actually was pretty busy all the time.
Lane (30:44.428)
Okay, yeah, that's cool. So after that job, you got this job doing Go, microservices. Did you get that job because you were interested in Go, or did that job get you into the Go community? Okay. And like now, in my mind, you're like the poster child for Go for Utah or Go for Zutah, like.
Miriah Peterson (30:56.31)
That job got me into go.
Miriah Peterson (31:06.062)
I am the poster child for go for Utah. That's 100% accurate. Um, what I am, I literally brought gophers to the last go meetup to hand out. So, uh, that is what I am. Uh, I, the story for that is I went to the first gopher con, somebody gave a talk about meetups and I was like, oh, I'll just start a women who go meetup in Utah. Why not? And like literally within a week I'd started that meetup. And so, because I don't have any chill. Um,
And so, yeah, I just started meetups and then I quickly took over the Go meetup. Um, and then I quickly took over a bunch of other meetups and then I started a Go conference. So, um, there's a great Go community in Utah. Uh, but it's still a lot, there's, there's a lot of experience, but there's a whole lot more people who are new to Go or want to experiment with Go. And, uh, I just really want them to know.
go the right way. Like I don't like Java go Java goes disgusting. I don't like, um, Ruby go, which is also Java go. Like there's a lot of bad ways to do go. And I saw a lot of bad ways to do go. And that's what I don't want. So that's kind of why I got involved in all these meetups and we're definitely, definitely a lot better. At least the people that show up to the meetups are doing a lot better.
Lane (32:20.378)
Yeah.
Lane (32:31.54)
I need to get back to the meetup again. I went to a bunch of Go meetups. It's been a few months, but I saw, I just pulled it up like a couple hours before we hopped on this call. I'll be there. Okay, so we're gonna talk about the community in just a second, but you said something that was really interesting to me and I wanna jump into it. You said RubyGo and JavaGo, and at my first Go job, it was RubyGo. So yeah, I mean, Utah also has a lot of Ruby on Rails shops.
Miriah Peterson (32:34.61)
I mean, I'm speaking at the next one, so come in September.
Miriah Peterson (32:55.419)
I'm sure it was.
Lane (33:00.17)
Or at least it did back then.
Miriah Peterson (33:01.734)
I think that had to do with the timing of the startups in Utah.
Lane (33:06.456)
Yeah, I think so too. Very much like Basecamp style, 37 signals, Ruby on Rails. So.
Miriah Peterson (33:13.515)
Oh yeah.
Lane (33:20.486)
What do you see the most when you see people coming in to go from either Java or Ruby, whichever one you have seen more of? What are some of the common mistakes?
Miriah Peterson (33:30.894)
Um, the biggest, uh, what I like to call is over abstracting. Um, when you come from a language that's heavily object oriented, um, you want to take those practices and to go because they've been trained into you, um, and goes not object oriented, essentially. Every time you add a layer of abstraction, which would be a layer of inheritance in your object oriented, right? The things they teach you to do to make your programs better.
Every time you add a layer of that in Go, you essentially decrease the performance of your code for something that you claim to be more readable, which in Go does not always make it more readable. Because Go does not have classes, they don't have the same kinds of inheritance patterns that you see in these typical things. They basically have structs, which are a type, basically a nested type.
where you can add multiple types. And then they have interfaces, which is a way of defining a contract of behavior. Those are the only two things. And people overuse interfaces and they overload interfaces and then they overuse structs, right? Just define one struct and use it everywhere. Like the compiler will inline the import for you. The more times you are changing types,
Lane (34:48.676)
Yeah.
Miriah Peterson (34:58.49)
A lot of people, what they like to do is they like to have packages that you're now titled modules. They will have a new struct type in each module for your data set. And they're like, this is inheritance. And it's like, no, every time you do that, what you're doing is you're rewriting the memory footprint of the same data that you're using everywhere. But if you use the original struct type, that doesn't have to be rewritten into a new memory format every time you call it.
You can keep the same memory footprint and the same allocation. You don't have to redo that and just add bulk that the garbage collector has to clean up. I mean, a lot of people don't notice it because of how fast Go is as a programming language, but it could be faster. It could be more efficient and it could like it could have fewer bugs because you're reading few less. There's less boilerplate. There's less copying of data.
Lane (35:39.76)
Yeah.
Miriah Peterson (35:54.538)
Like when you get down to the bits, like there's just too many bits floating around and you're overworking your garbage collector and not again, the garbage collectors flawless, like there's no, it's not like it's making bad programs that you won't notice when you're doing microservices at all, but it just can lead to things you don't see. And it could be better.
Lane (36:16.324)
It's, yeah, it's really interesting to hear you talk about the performance side because I mean, that makes a lot of sense, but it's also like something I wasn't even really thinking about when I was looking at these programs. To me, it was just like, wow, I can't read this stuff. This doesn't look like Go code to me.
Miriah Peterson (36:30.746)
I mean, the biggest problem 100% is readability, but goes a compiled language. I mean, it's people come into art readability and white space arguments. And I'm like, I don't like to make the argument because goes compiled. So who cares? Right? Ruby Python, they're not compiled languages. They're script. They, they run in a runtime and they run step by step. So it does matter how many lines of code and it does matter how it's formed, like those kinds of.
Go doesn't matter. So how many lines of code you have, how much boilerplate at the end of the day, doesn't matter to the compiler, but it does matter how many bits you're writing in the heap versus the stack. Now, does this matter to a junior engineer? No, just write go. Go's great for writing big things. It does matter though, maybe you forgot to close a row on your API request. And now you have...
You can't see it because of all the boilerplate. You're trying to figure out why do I have 12 different microservices for this? I keep running out of memory, so I keep spilling up new pods. Why is this? Well, you can't find it. You're not going to be able to find it because you have so much boilerplate. You just know that the memory keeps ticking up and maybe it's activity, maybe it's not. And it's definitely, yeah, that's definitely where my mind's been at.
Also, I keep having this conversation. I'm jealous of people who worked in the 90s because in the 90s, they didn't have gigabit RAMs. Like they didn't have this unlimited concept of memory that people I do now. So they had to think about algorithms and link trees and how to run memory efficiently. Like even on a Raspberry Pi, I just bought a Raspberry Pi with an eight gigabit RAM. Like that's, I'm never gonna kill that, but that's...
Lane (38:08.368)
Yeah.
Miriah Peterson (38:25.05)
What if my embedding was megabytes? Then I would care. And we need to, like, I'm not saying everybody needs to think that way, but it's a good thing to have in the back of your head. Am I running this the best way possible? How can I make it more efficient? Like I, if you want to build the best software, what can you do to make it the best? I'm not saying you need to take it to a hundred percent performance, but maybe 80%. Can you make it the 80% best performing software it can be?
Lane (38:28.005)
Right.
Miriah Peterson (38:53.75)
Great, well that's the difference between mid and senior sometimes. Like it'll help you, like it's just a way of thinking that helps you in your career to advance. And it's just something that's been on my mind a lot.
Lane (38:58.535)
Yeah.
Lane (39:06.256)
Yeah, no, that makes a lot of sense. I think, so I spent some time on tech Twitter. Yeah, the eyebrows raising. And something you'll hear a lot on tech Twitter because tech Twitter in, by my estimation, is heavily skewed towards like people that wanna work at like startups or start their own thing. And so a lot of the advice to developers is like, eh, we don't need performance. Like we're just trying to get our MVP off the ground, which like,
Miriah Peterson (39:12.467)
I'm sorry.
Lane (39:35.92)
That's good advice if you're starting a startup, or that's good advice if you work at a three-person company that's just building a crud app. But I love the fact that you're talking about performance because for most of us, for most of us to just get back-end jobs at medium to large companies, we do need to think about that because these companies do have lots of users or are moving lots of data.
Miriah Peterson (39:57.854)
100%. And I'm not saying, Oh, I need not working on the edge systems where, or, you know, you'll hear these stories. People who work at like something like Walmart, where you're dealing with thousands, hundreds of thousands of dollars in transactions and their edge optimizing their edge services can literally save them millions of dollars. I'm not talking about those millisecond optimizations that you get in those high performing companies. It's literally like, Oh, can I get the, it's from running from
you know, taking one second to run my API call to maybe milliseconds, not saving your, oh, going from five milliseconds to 10 milliseconds to save me $50 million. Like that's not the kind of, that, that is a special kind of optimization where I think people are specialized in doing that. But I think that's different than writing high quality code and writing high quality code is taking it from, oh, this takes a 20 seconds calls to now it only takes milliseconds.
Lane (40:43.729)
Right.
Miriah Peterson (40:55.294)
And you don't always see that in Go, and Go, it's always gonna be milliseconds, because again, Go is fast. But you can still make it, you know, maybe a 20% improvement without having to go to the extreme practices.
Lane (41:07.664)
Yeah, well, I mean, sometimes it's surprising when you do find that critical path that's causing something to be slow. Sometimes it's as trivial as just like, I'm doing some IO, I'm going to disk sequentially in a loop over and over and over again, right?
Miriah Peterson (41:14.186)
Yes.
Miriah Peterson (41:19.09)
Yes, that oftentimes is the case, is you're doing an IORite, which could be caching a file, writing to a database, and almost out logging too much. That's almost always the case, because that takes up the most. But that's again, how is that different than writing too much to your stack memory and having the garbage collector clean it up? I mean, besides the fact it writes
great, but it's the same process, right? Are you writing too much or could you be just having a best practice of not writing too much, which gets you away from a lot of this extra abstraction that people used to OOP put in a go. I'm not saying you shouldn't use interfaces, use interfaces, use structs, just they should be used the go way.
Lane (41:55.142)
Yeah.
Miriah Peterson (42:16.938)
which is the way the compiler expects them to be used.
Lane (42:20.228)
Right, a thing I often ran into, like you said, kind of Ruby Go, a lot of developers coming from Ruby starting to write their first lines of Go, was like way overusing like the, just the empty interface, right? Like, oh, I have this thing and man, it would be really convenient if I could just like use it everywhere. So I'm just gonna cast, I'm just gonna like.
Miriah Peterson (42:33.203)
Oh, I'm sure.
Lane (42:41.036)
Unmarshall some JSON is the empty interface, right? And then later when I care about the fields, like we can do some like custom unmarshalling or some crazy, like I saw that kind of stuff all the time and it drove me nuts. It's like, you know what the JSON like.
Miriah Peterson (42:53.99)
If you know what the type's going to be, especially with JSON, it's already using it. The library already uses the empty interface. Build the freak. And this is why are you, it's a basic principle. It's not good go. It is good API contracts. Like this is a design problem. This is much higher level than just writing code that I don't like. This is like, we have a contract. We know what we expect. Let's just define it.
Lane (43:12.069)
Yeah.
Miriah Peterson (43:23.478)
do what the compiler expects us to do, which is using hard typed variables.
Lane (43:28.708)
Right. Like define a struct, right? And like unmarshall into it. Yeah.
Miriah Peterson (43:32.406)
100%. That's what the compiler expects. And that was again, the big argument for generics in Go, which I know people don't use generics, use hard types. I think the only time you should use generics, the Go language is using them amazingly to optimize the compiler. I think that's great. I think they have library tools. If you're working on an open source project, you'll see it. If you're building microservices,
that have defined behaviors err on the sides of typed with contracts, and be done with it.
Lane (44:06.244)
Yeah. I, it's funny. I literally wrote an article, I think three days ago about this, where it was like, if you're, if you're building libraries, right? If you're building something that's going to be used in hundreds of applications, I think generics are super useful, right? But if you're writing application level code, you should be using them quite sparingly because when you're taking data from, like when you're unmarshalling an HTTP post and shoving some of that data into a database, it's all hard types.
Miriah Peterson (44:20.247)
Mm-hmm.
Lane (44:35.952)
Like everything you know is defined.
Miriah Peterson (44:36.522)
It's 100% API dependent, right? Like you have an API for your database, which is the database schema. You have an API for your request, which is the JSON payload you expect, right? Cause what do you do when you get a payload you don't expect, you say bad request. Like you throw back a whatever, 400. It's like, great. Like give you them the 400 saying, this does not match the contract that I specified in my API docs. This is not valid JSON I expect. Great.
Lane (44:52.42)
Yeah, 400. Yeah.
Miriah Peterson (45:06.23)
just use this API contract, which is again, if I think if something I wish I knew early on was the importance of just designing a good API with contracts, that's the only part of API design I think you really need. There's a lot of nuances to API design, especially when you're doing public APIs, but if you're just doing backend inter-service, get a contract and stick to your contract. And when you need to change your contract, make sure that you...
Lane (45:25.253)
Yeah.
Miriah Peterson (45:35.914)
Like that's between teams. That's when you show your communication skills and prove that soft skills matter to backend developers.
Lane (45:44.392)
Right, that's when software engineering actually, unfortunately, gets hard. That's when you have to communicate with humans. Cool. Okay, I've got some hot take type questions lined up that I really wanna get your opinion on. So the first one, this might be easy. What's your favorite part of Go? What would you be most sad if it changed?
Miriah Peterson (45:48.298)
when you have to use those soft skills and talk to other teams. Yes.
Miriah Peterson (46:10.79)
Oh, if Vimgo quit working, I really like, I do go in Vim and I really like a lot of the stuff that I can do with Vimgo. I like, I mean, Copilot's taken away a lot of the stuff because Copilot like generates everything for me. So, but I guess I like the third party tooling and go. I like the fact that I can go use a Qi API framework and have...
good third party open source support for that. I think Go has a great set of tooling outside the standard library. And I don't want the standard library adding too much and taking away the freedom that non-Google paid developers have for building tooling in the ecosystem. Whether that be Vim Go that I love, or the Goji framework, or...
Lane (46:41.113)
Yeah.
Lane (46:57.724)
That makes sense.
Miriah Peterson (47:03.654)
I really spew dot dumps a great one. DBX is when I use all the time. SQLX is what I mean. SQLX is, I use it all the time. Like those are, SQLX is, lets you specify struct tags on your structs. So you can unmarshall to struct. So it's tooling on top of the SQL interface that just allows you more dynamic. If you like actually,
Lane (47:09.678)
Okay.
I've used SQL C, I don't think I've tried SQL X before, is it similar?
Lane (47:21.245)
Oh, OK.
Miriah Peterson (47:32.514)
querying the database. SQL C is fantastic. SQL X, SQL C is, I did a whole thing on it for my O'Reilly course. I like SQL C. It just, it's the reverse solve to the problem, right? Can you generate your API with SQL or do you need to write where SQL C lets you generate the API with functions where you add your own SQL?
Lane (47:49.304)
Yeah.
Lane (47:59.172)
Got it. I'll definitely need to check it out. Cause I'm always interested in the different ways Go developers are interacting with databases because it's not like a mature space yet where like everyone's doing the same thing. There's lots of.
Miriah Peterson (48:08.906)
No, so I was for Postgres. I see a lot of people doing SQLX or PGX. Those are the two popular Postgres third party libraries.
Lane (48:19.644)
Cool, I'll definitely check those out as well. I've been using SQL Sealout recently just because I've been on a SQL kick. But yeah, it's fun. Cool, okay, so we got your favorite part, third party support. What's your least favorite part? What would you change if you had godlike powers to just reach into the language and change some?
Miriah Peterson (48:26.514)
It's great. It's great.
Miriah Peterson (48:43.038)
Um, what would I change about Go? Um, I don't know if I would change anything. Like I don't know, cause everything I would want to change about Go, I just go do in a different language, honestly. Like for a long time I would push. I'm like, I wish Go had better math libraries so we could do machine learning and Go and now I'm like.
I'll just go do machine learning in rest because they have better C++ bindings. Like, I don't know. I think Go does a really good, has a really good tool set for web services and for distributed system tool, like that cloud data, like the Kubernetes and the Docker and all those things that are built to Go. I think Go is really optimal for that. I don't want Go expanding.
Lane (49:15.96)
Yeah.
Miriah Peterson (49:39.926)
too much to things it doesn't make sense for. Um, I know there's a push for, there's a tiny go repo that's now supported by the go team for go on IOTA. I, the tiny goes fine, but I would use rust. Like I think rust has, is a much better, because you don't have to take the garbage compiler, the garbage collector with you, right? And then people are like, well, like sometimes I'll do like for friend and people like, oh, you can use. I'm like, uh,
Lane (49:42.83)
Hmm.
Lane (49:59.792)
Right, you know, it's take the runtime and the, yeah.
Miriah Peterson (50:10.242)
GoJSON was a thing, or it was like JS Go. It's like, just don't use Go for frontend. Like just don't. Like, so yeah, that's the thing. I don't want them to add things outside. Like the other languages already shine in. I don't think we should compete with other languages. I think we should just be the best language in the space we're in.
Lane (50:17.561)
Yeah, yeah.
Lane (50:29.72)
I agree. I think Go, like you said, back end web services, absolutely fantastic language, my go-to. I also think it's arguably the best language for most CLI applications.
Miriah Peterson (50:41.118)
Oh, over Python? Python's really popular. I think goes better for CLI. It's more lightweight. I agree.
Lane (50:47.633)
Yeah. And like, to be clear, not necessarily for scripting, like not necessarily for like, just writing like five lines of scripts. Yeah. I mean, like compiled CLI tools that like you can install, right? Like that's what I like go for. You don't have to specify Python versions and things like that when you want to distribute it to users.
Miriah Peterson (50:50.642)
Not scripting is different. Scripting is different. Yeah.
Miriah Peterson (51:03.627)
Yes.
Miriah Peterson (51:08.633)
You don't have to install with Python. You can just literally download the binary and have it in your path. And it's done. The end.
Lane (51:12.722)
Right.
Lane (51:16.024)
Yeah, those are by far my two favorite things. So you said you'd like use another language and it's hilarious. This is my next question on my hot take question list is what are some instances or maybe like what's the best example of a time where you've been doing something and you've been like, eh, maybe Go wasn't the right choice for this thing I'm trying to do. Was it the embedded systems with Rust or was it something else?
Miriah Peterson (51:39.37)
Okay, I haven't done it. There's a lot of things I think go would be, but I don't do those. I pretty much only do go. Um, I've never, I did machine learning and go, and then I quit doing machine learning. So like maybe that I, maybe I'm too like hardcore.
Lane (51:56.584)
So it wasn't that you solved the problem in another language, you just opted not to solve the problem and solve a different problem. Yeah.
Miriah Peterson (52:00.818)
at all. And so, and a lot of this is just a ridiculous branding, I think for me, right? Like I would stream on Twitch. I'm a Go streamer. I speak about Go. So it's like, maybe it's a Mariah problem. Where when I see a weak spot, I just don't pursue the weak spot. I just go back to safety. But yeah, I think great personal branding.
Lane (52:16.357)
Ha ha!
Lane (52:25.817)
great personal branding. Yeah.
Miriah Peterson (52:29.698)
So yeah, that's mostly if I ever do data analysts and analytics, I'll go do a Python pandas. I've done some of that in notebooks, but I don't do that much data analytics. So.
Lane (52:40.718)
Okay, yeah.
Lane (52:46.304)
Yeah, probably because you can't use Go to do it, or at least it would be not as fun. Yeah, yeah. Okay, last hot take. What's your most unpopular engineering opinion? So just like any engineering opinion.
Miriah Peterson (52:50.579)
I mean, not the way I want to, no. Not as dynamically.
Miriah Peterson (53:04.21)
Uh, my most unpopular, see, I don't have unpopular opinions. Everybody just does what I say. So right now, this used to be more unpopular than it is, it's gaining traction, but for a long, I will say, I said it first, I don't think we should use Python for data engineering. I think we should be building.
Lane (53:11.792)
You're just mainstream?
Miriah Peterson (53:29.25)
data systems and I don't think a lot of people they'll use Python as config scripts. And I'm like, no, JSON YAML. We have, just look at the engineering space. We have proved that if you're writing configs, it's JSON or YAML. Like all of the tools, Kubernetes, every cloud native, every cloud tool is JSON or YAML, like your configs are JSON and YAML. Don't be using Python for configs. Don't be like.
So if you're not doing that, then you're using Python to write scripts. Or you're using Python, which a lot of the scripts should be written. Like they're bash scripts, like they're cron jobs. Like a lot of you could do bash. And then if you're building systems, don't do Python. Like just don't do Python. Don't build services in Python. Don't they're like, oh, we'll put this model behind an API. Okay, fine. That's the extent of you, you trained the model in Python. Great.
Lane (54:15.067)
Yeah.
Miriah Peterson (54:27.158)
You threw an API around it. Great. That's the extent of the Python because you have to use Python to interact with the model. That's it. That's not, that's not data engineering. That's deploying a model to production. The other hot.
Lane (54:39.596)
In my past, we generated the model with Python and there's actually really good support to read the model in Go. Yeah.
Miriah Peterson (54:46.354)
If you're using ONIX, yeah, you can 100%. Like I'm not saying don't do that. If you can inference in another language, it's faster than Python. Great. Um, but yeah, that's a, that's my thing. Uh, another one, do not deploy notebooks to production. You'll see a lot of people. We can make our data scientists more productive if we deploy their notebooks to productions. Like, no, do you understand the compute model of a Jupiter notebook?
You're literally deploying thousands of containers in one service. Like that's how it works. It's a kernel model. Don't you have one Linux kernel for a reason. You don't need a thousand Linux kernels to be deployed to run one script.
Lane (55:30.29)
You're angering every data scientist. Good thing none of them listened to this.
Miriah Peterson (55:32.866)
No, I am angering people that are trying to save money by enabling data scientists. Data scientists don't want to deploy anything to production. They don't. So just give them engineering resources. That's it. That's what I'm saying. If you want something in production, don't save money by making the data scientists do it. Save money on your freaking infrastructure costs by having an engineer do it.
Lane (55:41.828)
Yeah, that's, that's true. Yeah.
Lane (55:58.072)
I like those takes and I tend to agree. Like I, yeah, they've definitely become popular because yeah, I look at it as like Python's great for data science, but not for data engineering. I think Go is really good for data engineering.
Miriah Peterson (56:01.907)
See? They're too popular.
Miriah Peterson (56:13.506)
I mean, Rust is taking, gaining huge ground in data engineering right now, mostly because it's not, it's not Google sponsored. Like it has its own, it has its own Rust foundation, right? It doesn't have a company backing it, which I think is, it's, let's, people aren't paying attention to that. Um, I know what you're saying, but, but when you have a field that's so heavily influenced by academics.
Lane (56:30.66)
was good until the whole Rust Foundation fiasco, I think. Oh, okay, I'll pretend that didn't happen.
Miriah Peterson (56:43.222)
Data science and machine learning is very heavily influenced by academics. They don't want companies involved. I think that's one of the reasons why Python has had so much traction there is because it's.
Lane (56:43.259)
Yeah.
Lane (56:53.84)
Which is actually interesting, because I mean I love the fact that Python's like taken over in academia, because before it was Matlab, which was like the worst. It was completely proprietary, like, oh no Mariah, that was your unpopular opinion. That was the big one.
Miriah Peterson (57:02.631)
I love MATLAB.
Miriah Peterson (57:08.802)
Ivy, I'm a physicist. We lived in MATLAB. When I went to do my PhD and they didn't use MATLAB, and they're like, do your differential equations in Mathematica, I'm like, again, you guys have no clue what computing is. Mathematica will kill your memory. Use MATLAB. It's made for computers.
Lane (57:11.853)
Yeah, I know. I know.
Lane (57:27.076)
I can't compare to Mathematica, I've never done that, but uh...
Miriah Peterson (57:29.378)
Don't, don't, but Matlab, you're right. It's very proprietary, but it depends on the calculations you're doing. I have never seen numeric calculations support like I do in Matlab, but you don't necessarily need that when you're doing machine learning, right? Like you're not numerically computing differential equations, you're analyzing data. So it's a very different, I'm not saying build machine learning models in Matlab, don't do that. I'm not saying...
Lane (57:32.817)
Yeah.
Lane (57:48.334)
Yeah.
Miriah Peterson (57:58.818)
do linear algebra in MATLAB. I just, yeah.
Lane (58:01.58)
Yeah, that makes sense. There's good. I finally coaxed a perhaps truly unpopular opinion out of you, at least for those of us that didn't come from the traditional sciences.
Miriah Peterson (58:11.014)
I still, I still have my university. I don't know when they're going to kick me off of my university alias. They clearly don't police that. I haven't been in college for five, six years. Yeah. So I still have university licenses for MATLAB. If I, if I wanted to, I haven't ethic, I haven't downloaded them. I am ethically responsible as a non-student of six years. Um, but you know, I still, I get the emails to my alias, come download the new version of MATLAB. And I'm like.
Lane (58:21.264)
You mean like your email address?
Lane (58:27.238)
Oh, nice.
Lane (58:36.753)
But you have it, yeah.
Miriah Peterson (58:41.086)
I'll use Python. Like I don't need, I don't need order of magnitude accuracy.
Lane (58:44.578)
Yeah.
Lane (58:48.152)
Yeah, none of that makes sense. Cool, those were great. All right, the last thing I have for you is regarding the tech community. So I wanna ask you about, should people who are just getting into the field, so they're like starting to look for that first job in backend engineering, should they be interested in like podcasting, blogging, speaking, meetups, and like to what extent, and which ones are the most important?
Miriah Peterson (59:14.366)
I think yes. I mean, the model hasn't changed from forever. You have to prove that you know what you know. And you have to, I know we, software engineers have a horrible reputation of being introverts. The truth is we're all introverts. And so when you get a whole bunch of introverts together,
we all magically are extroverts. They're like, oh, I'm like, you never know how introverted you are till you get a group of introverts together. And then you're like, am I an extrovert? Like, I'm that social? Cause like, I run meetups, like I host events. And then I turn around and say, oh, I hate people. I don't want to go to the store today. You know, those kinds of things. Like, am I an introvert? Yeah, I don't like.
Lane (59:50.736)
Right, you're the most extroverted of this group of extreme introverts.
Miriah Peterson (01:00:08.886)
but I do like certain things that excite me and meetups excite me. 100%. I don't know podcast, I don't know if, it depends on your interest. If you enjoy AV stuff and creating content, yeah, create a podcast, I don't care. Podcast your journey. Like that, we would love that. Just do live vlogs, do Instagram daily updates of your journey to try and find a job. I think...
Creating content is a valuable way to show your skills and to advertise yourself. If you best advertise yourself audio visually, like I do, that's why I would stream my software on Twitch because that's where I'm the most comfortable. I am not as comfortable writing blog posts. If you expose, if you express yourself best with words, talk about what you hacked on this weekend in a blog post. One of my most popular blog posts is the scripts I run.
to set up my Mac OS. And this is literally setting up Brew. What do I install from Brew? Setting up Vim, what do I install from Vim? Just like different steps for installation. And that is probably my most liked medium post. And it's just like, that's what people wanna know. They wanna know what new software you installed and if you liked it. Like, do you like Arch browser? Great, why? Like, that's all we wanna know. And 100%
Lane (01:01:29.242)
Right.
Miriah Peterson (01:01:37.454)
Um, I used to pre pandemic and a little bit during the pandemic, it got really hard during that pandemic, but pre pandemic, I would go to a bootcamp every three months and I would talk to their cohorts and I'd say, and all I did was talk about going to meetups. I like, there were probably at 10th, at least 30 to 40 local meetups in Utah at the time, and I said, if you want a job, you go to these meetups and it's not to say, Hey, I'm looking for a job.
It's because that way you meet the people who are hiring. The people that go to these jobs are hiring managers. They, we used to get a lot more recruiters than we do now, but they, they want to refer you, your friends want to refer you to jobs and the only way to make friends is to go to meetups. And then it's so natural and easy to socialize with people who have the same interests as you, like you can go to a meetup and be like, Whoa, you.
Lane (01:02:08.167)
Yeah.
Miriah Peterson (01:02:34.142)
Like you'll talk about weird things. You'll be like, oh, you also use a Linux laptop instead of a Mac or oh, you like Macs or, oh, I've never thought about building a video game and go. I love it. That was one of our talks was somebody wrote a video game and go a Game Boy Advance game that you could run on emulators. And it was so cool. And all of the nerds that play video games now want to do that. Or talk about your like, like there, there are so many nerds with so many interests. I've had a talk. Oh, somebody who's like.
Yeah, I wrote a Go library to edit my images for me. So they would do SVG edits on image, editing the SVG library. Great, so you like visual input. Like there's so many facets and interests. And once you make those people with similar interests, you'll never have to look for a job. Like, after my first job, I got my second job from a meetup. I got my third job because I host a conference.
Lane (01:03:33.063)
Yeah
Miriah Peterson (01:03:33.114)
And the people recognized my conference. I got my most recent job because of meetups, because I go to so many meetups and people know who I am, like. And I'm not saying you have to run them. I love when people who don't have experience speak, um, because it's new. Like I love when people share what they do. I do not care how professional it is. I just want to see your demo.
Lane (01:03:52.741)
Yeah.
Miriah Peterson (01:03:58.154)
Like that's all I want to see. I want to see you run that code you worked on so hard so I can clap and applaud for you. But like, if you want to get a job, you have to find your community. I don't care if your community's online, but the best communities are local in person. That is my unbiased opinion.
Lane (01:04:15.708)
Yeah, I couldn't agree more. Online community is like a good placeholder. If you have nothing else, you have online, but like.
Miriah Peterson (01:04:23.118)
I've talked about tech Twitter. I have met people on tech Twitter and they are good friends of mine. We don't interact via tech Twitter exclusively, but you had Bill Kennedy on your podcast. I met him on tech Twitter and we interact via tech Twitter. And he came to my conference because of our Twitter friendship, right? Like, I'm not saying don't use online communities, but he came to my conference. He came to that local meetups. I'm saying leverage it.
in your local community because at the end of the day, that's where you're getting your jobs. I don't care if you work remote. The jobs you want are local. The people you want to meet are local. Jobs that are most convenient for you will be local jobs. Otherwise you'll be traveling a lot.
Lane (01:05:07.928)
Yeah. I always say at least for your first job, especially for your first job, it's easiest to go local because you can make those very human connections to overcome that gap of like, you know, we're taking a chance on you and it's harder to take a chance on someone that's across the world. Yeah.
Miriah Peterson (01:05:24.694)
It's easier to ask for help. I've had jobs where I've said, hey, I'm blocked on Slack because we didn't have in person. It's fully remote. Hey, I'm blocked. DM, hey, I'm blocked. And radio silence for two days. And I couldn't do anything. Like I got into the point where I literally could not move forward without somebody checking a box. That wouldn't happen in person.
Lane (01:05:50.52)
Right. Yeah. You'd like spin around in your chair and get it figured out.
Miriah Peterson (01:05:54.514)
And so, yeah, I think there is value. I work remote. I'm not saying don't work remote, but I do think that the local community is your best support, even for getting remote jobs.
Lane (01:06:10.584)
Yeah, that makes sense.
Miriah Peterson (01:06:12.074)
Like you could work for Google remote and come to your local community and learn something you would never learn at Google and then bring it to work and make your work better.
Lane (01:06:23.076)
Yeah. Do you see any issues? Are there any issues with the conferences you run? Things you want people to be aware of? Or is there anything that you would change about meetups and conferences?
Miriah Peterson (01:06:34.718)
I need a drink. I'm talking to him.
Lane (01:06:36.997)
Yeah.
Miriah Peterson (01:06:42.355)
Um.
Miriah Peterson (01:06:45.702)
Yeah, I wrote a blog post about this couple of years ago called Local Communities Are Dead. 2021, we didn't wait. As soon as buildings led us back in, we started having meetups again. We had ability to social distance, people wore masks, we did hybrid meetups, but people didn't attend. They didn't even attend virtually.
And they quit attending virtually. And so now meetups that had 30 people, 15 in person, 15 remote now only have 15 in person, like people do not attend virtual meetups. And it's sad. Pre-COVID, I would run a meetup and we would get 40 to 50 people every month. And they were always like, they weren't the same people every time. And the conversations that you have and the people that you meet.
And you can bounce ideas off each other and people say, Hey, I'm trying to build XYZ and Kubernetes, have you ever seen that? And I'll be like, no, tell me about your problem. I'd love to learn about your problem. Like I met so many more people. There were you people found jobs easier. We would stop. And like now I say, Hey, is anybody hiring? We have one person hiring because there's only 15 people in the room. When I go to the Slack.
Lane (01:08:08.924)
Right.
Miriah Peterson (01:08:12.246)
the Slack that I managed for Ford Utah, the nonprofit one, will get 10 posts a week. So people are hiring. They're just not showing up to say, Hey, I'm hiring. And that's really destructive for local growth, right? Like if you want to help junior developers get careers, we need to have senior people go to meetups to mentor these people. I'm not saying you have to formally mentor them.
Lane (01:08:22.322)
Yeah.
Miriah Peterson (01:08:40.854)
but you can answer their questions. They'll have questions or you'll learn skills. A lot of people will have, oh, I need to learn. I were trying to migrate to the cloud. I need to learn about the cloud. We'll come to a meetup about the cloud. Like, or you'll come to a meetup about go and we'll talk about the cloud the whole time. Like we'll have these conversations after the talk that are super beneficial. And the less people that come to meetups,
Lane (01:08:43.249)
Right.
Miriah Peterson (01:09:09.398)
the less skilled the local community is. So I think Utah has the potential to have the same high level caliber skill reputation that San Francisco has. I know we have the people with the experience. We have people that worked at Bell Labs who live here.
Lane (01:09:24.305)
Right.
Miriah Peterson (01:09:25.666)
But they're never going to be able to share that knowledge if we don't have a local community to share it. Again, I don't care if it's a local online community, but we have to have that local interaction. And that's what I think post pandemic people aren't coming back to that. People would come to a meetup every month and they haven't been to a meetup for three years because they got out of the routine and because they don't work in the office anymore.
Lane (01:09:50.576)
Right. Sounds like the biggest issue is just the people aren't, people aren't going and they need to go. Just go to meetups. Yeah, okay.
Miriah Peterson (01:09:54.402)
People don't come back. And every time I have a conference, like conferences people make time for it. And they say, this was so nice. I haven't been to anything in three years. I really miss this. And I'm like, I have meetups every month. You don't have to miss this.
Lane (01:10:10.42)
Yeah. Go to meetups. I love this advice, especially if you're new, go to meetups.
Miriah Peterson (01:10:16.211)
Especially if you're new. I've every job I've gotten is because of a meetup. It's not because I'm special. It's because I go to meetups and I shake people's hands. You don't have to shake hands. You just have to say hi. I am.
Lane (01:10:30.984)
Right. If you don't want to shake hands, you don't actually have to. I love that. Thank you so much for coming on. You mentioned you stream on Twitch. You do a bunch of other things. Go ahead and plug everything so people can find you.
Miriah Peterson (01:10:33.588)
now.
Miriah Peterson (01:10:38.82)
I do.
Miriah Peterson (01:10:42.978)
Um, so I am taking a little bit of a break from streaming to focus on my O'Reilly content. I will be back eventually, but you can watch past streams on my YouTube. Um, they're all there. Um, you can follow me on LinkedIn or Twitter. Um, but like the best thing honestly would just be to join the Forge Slack. Um, it's at ForgeUtah.tech. It's a website. Click the link.
come hang out with us. It's not just for people in Utah, it's for everybody. But like we have amazing, like we have conversation about every topic, machine learning go, Kubernetes, data engineering, a lot of soft skill stuff. That's where I talk to all my Raspberry Pi friends. I only have two Raspberry Pis, but I bought the second one because somebody posted that they were in stock on the Forge Slack. So...
Lane (01:11:38.024)
They're hard to get. Yeah. They're always out of stock.
Miriah Peterson (01:11:40.322)
So yeah, I spend a lot more time on LinkedIn just because that's where the data community is right now is on LinkedIn. Um, so yeah, uh, but I'm on everything. I am literally on, no, I'm not on master. I don't do that. Yeah, just please do. Yeah. And you can follow me on Twitch from when I start streaming again. I just, I, uh, I just needed a mental break from that.
Lane (01:11:56.688)
Okay, well, fantastic. I'll link all that stuff down in the show notes and in the description, yeah.
Lane (01:12:09.948)
Totally get it. Thank you so much for coming on. We'll talk to you later.
Miriah Peterson (01:12:14.07)
Hey, thank you so much for having me.
Lane (01:12:20.625)
Bing.