Backend Banter

Lane:
Mariah Peterson, am I saying that right? I'm so excited

Miriah Peterson:
You

Lane:
to have

Miriah Peterson:
are,

Lane:
you.

Miriah Peterson:
you definitely are.

Lane:
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:
Oh yeah, I'm at home, Spanish fork, using my fiber internet.

Lane:
Oh, Spanish fork. I'm an American fork. We've got all the forks of Utah covered.

Miriah Peterson:
There's only two.

Lane:
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:
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:
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:
That question keeps getting muddied. The more and more AI companies get funded, because the more

Lane:
Ha ha!

Miriah Peterson:
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. 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

Lane:
Yeah.

Miriah Peterson:
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. 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?

Lane:
Mm-hmm.

Miriah Peterson:
But very much it is using pipelines to construct datasets.

Lane:
Okay.

Miriah Peterson:
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,

Lane:
Yeah.

Miriah Peterson:
but my, my head space always goes to the system first and the data relationships second. So that's,

Lane:
Right.

Miriah Peterson:
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. 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

Lane:
Yeah,

Miriah Peterson:
of things.

Lane:
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

Miriah Peterson:
Exactly.

Lane:
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, You said something that made me think DBA. Like it sound, like if I squint, it almost sounded like

Miriah Peterson:
I mean,

Lane:
database

Miriah Peterson:
it would

Lane:
administrator.

Miriah Peterson:
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

Lane:
Right.

Miriah Peterson:
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.

Lane:
Yeah.

Miriah Peterson:
You know, like I'm not going to. 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:
Right, we're kind of abstracting all of the persistent layer behind this nice SQL interface, right? And then

Miriah Peterson:
100%

Lane:
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, 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:
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

Lane:
Right.

Miriah Peterson:
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. is the operation side of it. And on the cloud, that is a skillset I would never have. So.

Lane:
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:
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.

Lane:
Yeah.

Miriah Peterson:
You also have 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:
We have to be careful, we're scaring everyone away. That sounded very complex.

Miriah Peterson:
Um, this is why

Lane:
Hahaha.

Miriah Peterson:
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.

Lane:
Yeah.

Miriah Peterson:
It's not for everybody, but it's,

Lane:
Yeah.

Miriah Peterson:
um, it's fun for me, but I, uh, but there's a definite need for people to do it. Right. Like we

Lane:
Oh yeah.

Miriah Peterson:
have a lot of data.

Lane:
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

Miriah Peterson:
I said

Lane:
hopefully

Miriah Peterson:
a lot

Lane:
simplify

Miriah Peterson:
of words, so

Lane:
it

Miriah Peterson:
we might

Lane:
for the

Miriah Peterson:
need

Lane:
listeners.

Miriah Peterson:
a summary.

Lane:
So, okay, data engineering from like a really high overview, you've got data sources, this is where data is coming from, right?

Miriah Peterson:
Mm-hmm.

Lane:
So you mentioned third party. So for example, on Boot Dev, we use Stripe for billing.

Miriah Peterson:
Yes.

Lane:
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?

Miriah Peterson:
100%.

Lane:
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,

Miriah Peterson:
like a pit

Lane:
yeah?

Miriah Peterson:
like a sinkhole literally

Lane:
Yeah.

Miriah Peterson:
like a sinkhole

Lane:
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:
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

Lane:
Yeah.

Miriah Peterson:
all of these things in and then you can start to see how the data relates to each other. 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

Lane:
Yeah.

Miriah Peterson:
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:
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.

Miriah Peterson:
Data

Lane:
Is there

Miriah Peterson:
warehouse

Lane:
a difference?

Miriah Peterson:
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

Lane:
Mm-hmm.

Miriah Peterson:
just places you can put raw files where they can be accessed. And then you can put query layers on top of them.

Lane:
Yeah, not necessarily optimized for fast transactional

Miriah Peterson:
No, they're

Lane:
queries,

Miriah Peterson:
not optimized

Lane:
but like...

Miriah Peterson:
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:
Got it. So for your typical, let's just say, software as a service company, SaaS company,

Miriah Peterson:
Mm-hmm.

Lane:
say we use Postgres for our back end, the database for our application.

Miriah Peterson:
your services itself, yes.

Lane:
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:
I would want to keep it separate. One, because stuff you use tends to have different access levels. I mean, this is a weird

Lane:
Hmm.

Miriah Peterson:
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:
Yeah.

Miriah Peterson:
But if you're doing analytics, you want people querying that production style data. You want the live data. You want the real data.

Lane:
Yeah.

Miriah Peterson:
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. 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:
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,

Miriah Peterson:
100%.

Lane:
and then dumps it somewhere. Okay, very cool, and this is the stuff you love, I guess.

Miriah Peterson:
in a weird way. Unfortunately, yes, this is the stuff I love.

Lane:
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:
Yeah, I agree. I don't like making things pretty. I like making things run fast.

Lane:
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.

Miriah Peterson:
Oh, I do.

Lane:
A, like I guess Y and then B, like if, well, let's just start there. Why a bachelor's degree in physics?

Miriah Peterson:
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

Lane:
They listed

Miriah Peterson:
for...

Lane:
software engineer? That's, that's kind of crazy.

Miriah Peterson:
They had, at the time, most professional data scientists at the big companies had PhDs in mathematics or physics.

Lane:
Okay, yeah,

Miriah Peterson:
Because...

Lane:
that makes sense.

Miriah Peterson:
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.

Lane:
Yeah.

Miriah Peterson:
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:
Yeah. So it's interesting though that they said like software development or I'm guessing they didn't say

Miriah Peterson:
They

Lane:
web

Miriah Peterson:
definitely

Lane:
development.

Miriah Peterson:
didn't understand the landscape. These professors,

Lane:
Okay.

Miriah Peterson:
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,

Lane:
Okay, good.

Miriah Peterson:
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. It's kind

Lane:
Okay.

Miriah Peterson:
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. 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,

Lane:
Ha ha

Miriah Peterson:
well, it looks

Lane:
ha!

Miriah Peterson:
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

Lane:
Right.

Miriah Peterson:
just. Honestly,

Lane:
Yeah,

Miriah Peterson:
you're

Lane:
that.

Miriah Peterson:
not buying a house with $100,000 in the market in Utah right now.

Lane:
Yeah, it sounds like the real golden ticket was not being picked by the divine.

Miriah Peterson:
Not being picked by the divine lets you afford a house and food, so yes.

Lane:
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:
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.

Lane:
Yeah.

Miriah Peterson:
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:
The market's rough. Yeah.

Miriah Peterson:
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:
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

Miriah Peterson:
It's the

Lane:
like

Miriah Peterson:
opposite of easy.

Lane:
I... 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

Miriah Peterson:
100%.

Lane:
get.

Miriah Peterson:
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:
Yeah, tech is a newer field and we don't have this like, you know, if you go look at the trades, for example,

Miriah Peterson:
Mm-hmm.

Lane:
there's like this very kind of structured path that you go from like, you know, I think you start as like a journeyman,

Miriah Peterson:
Yeah.

Lane:
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, 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?

Miriah Peterson:
Yes.

Lane:
It gets so

Miriah Peterson:
You have

Lane:
much

Miriah Peterson:
two

Lane:
easier.

Miriah Peterson:
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:
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,

Miriah Peterson:
Oh, from Netflix.

Lane:
yes, yeah.

Miriah Peterson:
I watch his streams.

Lane:
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. 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:
Um, my, well, I, the job

Lane:
You don't

Miriah Peterson:
I had

Lane:
have to

Miriah Peterson:
in

Lane:
tell us the name of the company if you don't want to, but just like,

Miriah Peterson:
No, the first,

Lane:
how was it? Yeah.

Miriah Peterson:
my first post-college job at Nav was a fantastic job. And it was literally writing Go microservices. Like it was the on,

Lane:
Oh, that's amazing.

Miriah Peterson:
that were deployed to Kubernetes on AWS. Like it was literally the ideal job.

Lane:
Way to disprove my point, alright.

Miriah Peterson:
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. 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

Lane:
Yeah.

Miriah Peterson:
cold fusion. Like that's fine. Drupal migration. That was stupid.

Lane:
That's

Miriah Peterson:
Like

Lane:
the one, that's the

Miriah Peterson:
that,

Lane:
job I was referring

Miriah Peterson:
that's,

Lane:
to.

Miriah Peterson:
that's the one I, uh, I quit to go. I, I made. More money. I quit that job to go make more money. TA-ing physics.

Lane:
Oh wow. Yeah. My first software development job I was paid $15 an hour.

Miriah Peterson:
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:
Wow, yeah, that's pretty crazy. But I mean, I was also in college at the time, and like it's

Miriah Peterson:
But

Lane:
just,

Miriah Peterson:
you weren't

Lane:
yeah.

Miriah Peterson:
working for the university, were you?

Lane:
No,

Miriah Peterson:
That's

Lane:
this

Miriah Peterson:
a...

Lane:
was a different company.

Miriah Peterson:
A university's like to underpay people.

Lane:
Yeah, that's been my, that's been my, it's what I've gathered, I guess is the way

Miriah Peterson:
But

Lane:
I'll

Miriah Peterson:
then,

Lane:
say it.

Miriah Peterson:
I don't know, it was nice. I could do homework at work. So we'll just leave it at

Lane:
Yeah,

Miriah Peterson:
that.

Lane:
that's true. I couldn't do that. I actually was pretty

Miriah Peterson:
Now

Lane:
busy

Miriah Peterson:
that's the

Lane:
all the

Miriah Peterson:
one,

Lane:
time.

Miriah Peterson:
the main benefit of being a TA was doing homework at work.

Lane:
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.

Miriah Peterson:
That job got me into go.

Lane:
And like now, in my mind, you're like the poster child for Go for Utah or Go for Zutah, like.

Miriah Peterson:
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

Lane:
Yeah.

Miriah Peterson:
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:
I need to get back to the meetup again. I went to a bunch of Go meetups. It's

Miriah Peterson:
I mean,

Lane:
been

Miriah Peterson:
I'm speaking

Lane:
a few

Miriah Peterson:
at the

Lane:
months,

Miriah Peterson:
next

Lane:
but

Miriah Peterson:
one, so come in

Lane:
I

Miriah Peterson:
September.

Lane:
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.

Miriah Peterson:
I'm sure

Lane:
So

Miriah Peterson:
it was.

Lane:
yeah, I mean, Utah also has a lot of Ruby on Rails shops. Or at least it did back then.

Miriah Peterson:
I think that had to do with the timing of the startups in Utah.

Lane:
Yeah, I think so too. Very much like Basecamp style, 37 signals, Ruby on Rails.

Miriah Peterson:
Oh yeah.

Lane:
So. 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:
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

Lane:
Yeah.

Miriah Peterson:
the compiler will inline the import for you. The more times you are changing types, 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

Lane:
Yeah.

Miriah Peterson:
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. 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

Lane:
It's,

Miriah Peterson:
it could be better.

Lane:
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

Miriah Peterson:
I mean,

Lane:
to

Miriah Peterson:
the

Lane:
me.

Miriah Peterson:
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

Lane:
Yeah.

Miriah Peterson:
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... What if my embedding was megabytes? Then I would

Lane:
Right.

Miriah Peterson:
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? Great, well that's the difference between mid and senior sometimes. Like it'll help you,

Lane:
Yeah.

Miriah Peterson:
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:
Yeah, no, that makes a lot of sense. I think, so I spent some time on tech Twitter.

Miriah Peterson:
I'm sorry.

Lane:
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, 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:
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

Lane:
Right.

Miriah Peterson:
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. 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:
Yeah, well, I mean, sometimes it's surprising when you do find that critical path that's causing something to be slow. Sometimes

Miriah Peterson:
Yes.

Lane:
it's as trivial as just like, I'm doing some IO, I'm going to disk sequentially

Miriah Peterson:
Yes,

Lane:
in a loop over and over and

Miriah Peterson:
that

Lane:
over again,

Miriah Peterson:
oftentimes

Lane:
right?

Miriah Peterson:
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

Lane:
Yeah.

Miriah Peterson:
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. which is the way the compiler expects them to be used.

Lane:
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,

Miriah Peterson:
Oh,

Lane:
right?

Miriah Peterson:
I'm sure.

Lane:
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. 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:
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

Lane:
Yeah.

Miriah Peterson:
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. do what the compiler expects us to do, which is using hard typed variables.

Lane:
Right. Like define a struct, right? And like unmarshall into it. Yeah.

Miriah Peterson:
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

Lane:
Yeah.

Miriah Peterson:
done with it.

Lane:
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,

Miriah Peterson:
Mm-hmm.

Lane:
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. Like everything

Miriah Peterson:
It's

Lane:
you

Miriah Peterson:
100%

Lane:
know is defined.

Miriah Peterson:
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

Lane:
Yeah,

Miriah Peterson:
back

Lane:
400.

Miriah Peterson:
a whatever,

Lane:
Yeah.

Miriah Peterson:
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. 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

Lane:
Yeah.

Miriah Peterson:
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... Like that's between teams. That's when you show your communication skills and prove that soft skills matter to backend developers.

Lane:
Right, that's when software engineering actually, unfortunately, gets hard. That's when you have to communicate with humans.

Miriah Peterson:
when you have to use those soft skills and talk to other teams. Yes.

Lane:
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:
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

Lane:
Yeah.

Miriah Peterson:
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

Lane:
That

Miriah Peterson:
that

Lane:
makes

Miriah Peterson:
be

Lane:
sense.

Miriah Peterson:
Vim Go that I love, or the Goji framework, or... I really spew dot dumps a great one. DBX is when I use all the time. SQLX is what I mean. SQLX is,

Lane:
Okay.

Miriah Peterson:
I use it all the time.

Lane:
I've

Miriah Peterson:
Like

Lane:
used

Miriah Peterson:
those

Lane:
SQL C, I don't think I've tried SQL X before,

Miriah Peterson:
are,

Lane:
is it similar?

Miriah Peterson:
SQLX is, lets you specify struct tags on your structs.

Lane:
Oh, OK.

Miriah Peterson:
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, 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

Lane:
Yeah.

Miriah Peterson:
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:
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.

Miriah Peterson:
No,

Lane:
There's lots of.

Miriah Peterson:
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:
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.

Miriah Peterson:
It's

Lane:
But

Miriah Peterson:
great. It's

Lane:
yeah,

Miriah Peterson:
great.

Lane:
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:
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,

Lane:
Yeah.

Miriah Peterson:
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. too much to things it doesn't make sense for.

Lane:
Hmm.

Miriah Peterson:
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

Lane:
Right,

Miriah Peterson:
garbage

Lane:
you know, it's

Miriah Peterson:
collector

Lane:
take the runtime

Miriah Peterson:
with you,

Lane:
and the, yeah.

Miriah Peterson:
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, GoJSON was a thing, or it was like JS Go. It's like, just don't use Go for frontend. Like just don't.

Lane:
Yeah,

Miriah Peterson:
Like, so

Lane:
yeah.

Miriah Peterson:
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:
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:
Oh, over Python? Python's really popular. I think goes better for CLI. It's more lightweight. I agree.

Lane:
Yeah. And like, to be clear, not necessarily for scripting, like not necessarily for like,

Miriah Peterson:
Not

Lane:
just writing like

Miriah Peterson:
scripting

Lane:
five lines

Miriah Peterson:
is

Lane:
of

Miriah Peterson:
different.

Lane:
scripts. Yeah.

Miriah Peterson:
Scripting is different. Yeah.

Lane:
I mean, like compiled CLI tools that like you can install, right? Like that's what I like go for. You

Miriah Peterson:
Yes.

Lane:
don't have to specify Python versions and things like that when you want to distribute it to users.

Miriah Peterson:
You don't have to install with Python. You can just literally download the binary and have it

Lane:
Right.

Miriah Peterson:
in your path. And it's done. The end.

Lane:
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:
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:
So it wasn't that you solved the problem in another language, you just opted not to solve the problem and solve

Miriah Peterson:
at

Lane:
a different

Miriah Peterson:
all.

Lane:
problem. Yeah.

Miriah Peterson:
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.

Lane:
Ha ha!

Miriah Peterson:
Where when I see a weak spot, I just don't pursue the weak spot. I just go back to safety. But yeah,

Lane:
great

Miriah Peterson:
I think

Lane:
personal branding. Yeah.

Miriah Peterson:
great personal branding. So yeah, that's mostly if I ever do data analysts and analytics, I'll go do a Python pandas.

Lane:
Okay, yeah.

Miriah Peterson:
I've done some of that in notebooks, but I don't do that much data analytics. So.

Lane:
Yeah, probably because you can't use Go to do it, or at least it would be not as fun.

Miriah Peterson:
I mean, not the way I want to, no. Not as

Lane:
Yeah,

Miriah Peterson:
dynamically.

Lane:
yeah. Okay, last hot take. What's your most unpopular engineering opinion? So just like any engineering opinion.

Miriah Peterson:
Uh, my most unpopular, see, I don't have unpopular opinions. Everybody just does

Lane:
You're

Miriah Peterson:
what

Lane:
just

Miriah Peterson:
I say.

Lane:
mainstream?

Miriah Peterson:
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. 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

Lane:
Yeah.

Miriah Peterson:
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. 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

Lane:
In my

Miriah Peterson:
hot.

Lane:
past, we generated the model with Python and there's actually really good support to read the model in Go. Yeah.

Miriah Peterson:
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:
You're angering every data scientist.

Miriah Peterson:
No, I am angering

Lane:
Good thing none of

Miriah Peterson:
people

Lane:
them listened

Miriah Peterson:
that

Lane:
to this.

Miriah Peterson:
are trying to save money by enabling data scientists. Data scientists don't want to deploy anything to production. They

Lane:
Yeah,

Miriah Peterson:
don't.

Lane:
that's, that's true. Yeah.

Miriah Peterson:
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:
I like those takes and I tend to agree. Like I,

Miriah Peterson:
See? They're too popular.

Lane:
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:
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,

Lane:
was good until the whole Rust Foundation fiasco, I think.

Miriah Peterson:
let's, people aren't paying attention to that. Um,

Lane:
Oh, okay, I'll pretend

Miriah Peterson:
I know what

Lane:
that

Miriah Peterson:
you're

Lane:
didn't

Miriah Peterson:
saying,

Lane:
happen.

Miriah Peterson:
but, but when you have a field that's so heavily influenced by academics. Data

Lane:
Yeah.

Miriah Peterson:
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

Lane:
Which is

Miriah Peterson:
it's.

Lane:
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

Miriah Peterson:
I love

Lane:
proprietary,

Miriah Peterson:
MATLAB.

Lane:
like, oh no Mariah, that was your unpopular opinion. That was the big one.

Miriah Peterson:
Ivy, I'm a physicist. We lived in MATLAB.

Lane:
Yeah,

Miriah Peterson:
When

Lane:
I

Miriah Peterson:
I

Lane:
know.

Miriah Peterson:
went to do

Lane:
I

Miriah Peterson:
my

Lane:
know.

Miriah Peterson:
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:
I can't compare to Mathematica, I've never done that,

Miriah Peterson:
Don't,

Lane:
but uh...

Miriah Peterson:
don't, but Matlab,

Lane:
Yeah.

Miriah Peterson:
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

Lane:
Yeah.

Miriah Peterson:
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... do linear algebra in MATLAB. I just,

Lane:
Yeah, that makes

Miriah Peterson:
yeah.

Lane:
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

Miriah Peterson:
I

Lane:
the

Miriah Peterson:
still,

Lane:
traditional sciences.

Miriah Peterson:
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

Lane:
You

Miriah Peterson:
five,

Lane:
mean like your

Miriah Peterson:
six

Lane:
email

Miriah Peterson:
years.

Lane:
address?

Miriah Peterson:
Yeah. So I still have university licenses for MATLAB. If I, if I wanted

Lane:
Oh,

Miriah Peterson:
to, I haven't

Lane:
nice.

Miriah Peterson:
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

Lane:
But you have

Miriah Peterson:
to my

Lane:
it,

Miriah Peterson:
alias,

Lane:
yeah.

Miriah Peterson:
come download the new version of MATLAB. And I'm like. I'll use Python. Like I don't need, I don't

Lane:
Yeah.

Miriah Peterson:
need order of magnitude accuracy.

Lane:
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:
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,

Lane:
Right, you're the most extroverted of this group of extreme introverts.

Miriah Peterson:
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. 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

Lane:
Right.

Miriah Peterson:
liked it. Like, do you like Arch browser? Great, why? Like, that's all we wanna know. And 100% 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

Lane:
Yeah.

Miriah Peterson:
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. 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:
Yeah

Miriah Peterson:
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

Lane:
Yeah.

Miriah Peterson:
I love when people share what they do. I do not care how professional it is. I just want to see your demo. 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:
Yeah, I couldn't agree more. Online community is like a good placeholder. If you have nothing else, you have online,

Miriah Peterson:
I've

Lane:
but like.

Miriah Peterson:
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

Lane:
Yeah.

Miriah Peterson:
a lot.

Lane:
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

Miriah Peterson:
It's easier

Lane:
someone

Miriah Peterson:
to ask for

Lane:
that's

Miriah Peterson:
help.

Lane:
across the world. Yeah.

Miriah Peterson:
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:
Right. Yeah. You'd like spin around in your chair and get it figured out.

Miriah Peterson:
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:
Yeah,

Miriah Peterson:
Like

Lane:
that

Miriah Peterson:
you could work for

Lane:
makes

Miriah Peterson:
Google

Lane:
sense.

Miriah Peterson:
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:
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:
I need a drink. I'm talking to him.

Lane:
Yeah.

Miriah Peterson:
Um. 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.

Lane:
Right.

Miriah Peterson:
When I go to the Slack. 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

Lane:
Yeah.

Miriah Peterson:
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. but you can answer their questions. They'll have questions

Lane:
Right.

Miriah Peterson:
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, 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:
Right.

Miriah Peterson:
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:
Right. Sounds like the biggest issue is just the people aren't, people aren't

Miriah Peterson:
People

Lane:
going and

Miriah Peterson:
don't

Lane:
they need

Miriah Peterson:
come

Lane:
to go.

Miriah Peterson:
back.

Lane:
Just go to meetups. Yeah,

Miriah Peterson:
And

Lane:
okay.

Miriah Peterson:
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:
Yeah. Go to meetups. I love this advice, especially if you're new, go to meetups.

Miriah Peterson:
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:
Right. If you don't want to shake hands, you don't actually have to. I

Miriah Peterson:
now.

Lane:
love that. Thank you so much for coming on. You mentioned you stream on Twitch. You do

Miriah Peterson:
I

Lane:
a bunch of other things.

Miriah Peterson:
do.

Lane:
Go ahead and plug everything so people can find you.

Miriah Peterson:
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:
They're hard to get. Yeah. They're

Miriah Peterson:
So yeah,

Lane:
always out of stock.

Miriah Peterson:
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.

Lane:
Okay, well, fantastic. I'll link all that stuff down in the

Miriah Peterson:
Yeah,

Lane:
show

Miriah Peterson:
just

Lane:
notes and

Miriah Peterson:
please

Lane:
in the description,

Miriah Peterson:
do. Yeah. And you

Lane:
yeah.

Miriah Peterson:
can follow me on Twitch from when I start streaming again. I just, I, uh, I just needed a mental break from that.

Lane:
Totally get it. Thank you so much for coming on. We'll talk to you later.

Miriah Peterson:
Hey, thank you so much for having me.

Lane:
Bing.