Finding Tech Jobs in Canada vs USA & The Ultimate Programming Language

All right. Hello everyone. Thank you for tuning in. Once again to the V City Podcast. My name is Peter Peter Oum and I'll be your host today. It's quite interesting because today we have a full house, we have Sam Emmanuel and Jason joining us today. And if you're watching this on youtube, you can see all of us. And if you're on uh Spotify, Apple, whatever the case may be, you probably uh can't see us, but it's a full, it's a full, it's a full virtual room today.

Um Today we're going to talk about a couple of topics and I'll, I'll run through a few of them for listeners to have an idea as to what we're going to talk about and then we'll introduce our guests for the day. So today we'll talk a little bit about the tech sector in the United States versus Canada. And then we'll move on to discussing the merits of learning certain programming languages or scripted uh scripting languages.

And they will move into talking a little bit more about at the end of the conversation, we'll talk a little bit about, let me see my notes here api S and front end versus back end for a career path. What is the difference, et cetera? So that's something that you need to keep in mind. Hopefully you're going to enjoy these topics. Uh But before we get started, I want to introduce our guest speakers. Before, before you guys talk, I just want to say a few things.

The first is, thank you for joining us today, Sam Jason Emmanuel. You all, we all come from different aspects of the tech sector, right? I'm pri primarily in it and cloud engineering um similar with, with Jason actually who's more so in infrastructure as code right now, but he has a very good understanding of containers and working with cloud computing, uh whether it's GCP or AWS or Azure. Um And then Emmanuel was on was on the last podcast.

He, he talked a little bit about his journey to Apple and uh Sam works at Intuit as well as in Canada. And Jason is working at a crown company in Canada as well. So with that said, I'm gonna pass it on to Sam to tell us a little bit about yourself, your, your journey, who you are just so that listeners can kind of connect with you. Maybe they haven't listened to any other podcasts. This is the first they've gotten into. So just uh let us know a little bit about you, Sam.

Absolutely. Um First of all, I'm excited to be here. This is my mostly I'm up to like number three or number four. So I, I, I'm a, I'm a vet, I'm a vet for the, so it's definitely sign me back. OK. So a little bit about myself, I'm a software engineer into it. I'd say I'm like a full stack developer. So I do a lot of like full stack work at, at work my free time. I like to dabble in I OS.

We got an opportunity to play around with some, a little bit of infrastructure stuff, but I wouldn't like I talked about in one of our pods. It's not my favorite thing to do, but you know, you gotta wear different hats to accomplish different things. But um yeah, that's a little bit about me. I'm a huge football fan. So if there's any like Niners listeners, anything like that, shoot me, shoot me a little message. We'll talk football.

When you said football first, I was thinking you were actually talking uh American football, American football. Is that good? Good? All right, Jason, you're up. Yep. So, hey, guys. So I'm a cloud engineer at a crown organization for my spare time. I enjoy snowboarding, skiing, playing soccer. My favorite thing is the mountains. I do a lot of infrastructure as code at work as well as a lot of cloud engineering.

So basically helping teams that are not tech oriented or that don't like cloud move to the cloud and basically giving them, giving them the infrastructure to do their work. That's about it. Thank you. Thank you very much. And, uh, Emmanuel, you're up next. I have one. Well, first of all, is it really, football seems a lot like handball. I'm just saying they don't use the foot so they only use their foot to like, kick, like, once in a while.

So, like the real football and then they coined the name soccer just like, you know, kick, uh kick. So, you know, it's like I could have that name. Football. I don't know, but I think it's more or less like handball, a touch of the foot sometimes. But I'll just say, uh but yeah, I mean Manuel, I'm a software engineer at Apple. I'm a football fan, football fanatic, not the American football. Let's be specific. I call that American football, don't just coin as football. Ok. I'm an I OS engineer.

Uh once in a while I venture into the space of web development for fun. Yeah, I know. I don't really like the space that much but sometimes I do uh primarily I OS development. Um Yeah, so that's just what I do and what I do for fun. Too. Awesome. Thank you very much. Yeah, I, for me just a brief introduction, my name is Peter.

I work as a senior consultant at Agile and my job typically is to work with Fortune 500 companies to ensure that their cybersecurity is up to date or at least implementing new cybersecurity software specifically in the Microsoft Space. So uh everything from everything, every cybersecurity product in the Microsoft stack or in Azure is what I focus on.

Um So with that said, let's move into the next uh topic here, Sam, you wanted to talk a little bit about the tech sector face off uh us versus Canada. How about you take it from here? And by the way, I want to apologize to listeners, I might sound a little bit nasally. Um That's because I'm slightly under the weather. So the way I talk is a little different today, I'm a little bit, you know, feeling down. So my, my, my co-stars here today are gonna really, really carry the show. All right.

So I'm over to you. All right, man. I, I've been thinking about this topic um outside obviously the, the scope of, of our podcast, but it's one of the very, make sure to tell them where you are though because it, it gives context, right? OK. So I'm in Canada.

So that's, that's my background and III I want to talk about this just as a um I don't wanna get too philosophical on you, but the first thing you have to realize is OK, Canada versus United States, you gotta think about it from an economy standpoint. Obviously, the United States is, I don't know the exact number, but it is multitude of times larger than Canada's economy. What that means is the tech sector in Canada is a lot smaller in comparison to the United States.

So I think we're doing a disservice if we're doing a 1 to 1 comparison, right? But then with that in mind, what is OK as someone who works in Canada, what what benefits do I see with? Say if I moved to the United States and vice versa from a tech perspective, I don't want to bring in like quality of life and all. Because when you start to do that, it's a convoluted conversation. Now you're talking about different things from a tech perspective.

What is, how do we sort of pitch each other or pitch two of the countries side by side? What, what is the defining factor? So I'd say for me, the biggest thing is opportunity, there is not a plethora of opportunities in Canada now don't get it twisted. There is a lot of opportunities, there are a lot of big tech companies in Canada. But again, you can't really compare it with the United States, like the United States is the hub of the technology for the world.

So what that means is there's different places for different technologists to thrive. I think very often when people think of tech companies, they just think software engineers or engineering, but there is a large array of technologists that make software happen and bring it to life.

And I just feel like from an opportunity standpoint, you can't go wrong with the States because regardless, I mean, like the, the tech industry in California alone is like double the size of Canada not to talk about even places like Seattle where you've got Amazon, you've got Microsoft or even like Atlanta or New York. So there's these massive technology hubs that exist all around the United States and in Canada's um defense, there's a lot more of these hubs springing up.

So obviously, Toronto is one of them, but Calgary is, is another place they sort a to, you know, get up there. Obviously, you've got Vancouver and a little bit of Victoria, I I say Vancouver and Victoria together, I'm a little bit biased because I went to university there. But uh Emmanuel just was like what? It's a little bit, it's not too bad in comparison to like the region, right? It, I'd say Victoria and Vancouver are the hub for like western Canada and alongside alongside Calgary.

But after opportunity, you gotta look at the big, big question compensation. I think everyone can agree. This is where the biggest difference lies between the United States and Canada. I'll tell you this on average, somebody of my exact same skill set is probably making north of 40 $50,000 more than I do, but not just that they're also making this in American dollars. So the value is the value scale is so the, the, the disparity is so crazy.

Um But every now and then I think to myself, man, if I would just move to the, to the US, maybe California, I don't mind paying California tax because California tax is less than Canadian tax on average. So you, you start to do some of the math and like, I mean, does it make sense? Does it not make sense? You know, stuff like that? But then the third point that I'll, I'll end it off with is I think the, the industry in Canada is a little bit more stable from a layoff perspective.

I think a lot of the bigger companies who do run um, operations out of Canada tend to have a more, um, not lackluster but more of a, how do you conservative approach with hiring? So you're not gonna see the tens of thousands of employees that you have like, like Amazon hire, like in the States, right? You're not more likely than not, not gonna see that in Toronto.

You know, you're not gonna see the larger companies just hire a ton of people and then when layoff season comes along, then there's a ton of people to go. Right. So I think the Canadian uh tech industry is a little bit more stable from a layoff perspective, not to say the layoffs don't happen. They most certainly do.

But again, if you were to take it as a percentage in comparison to the size of the company, I think Canada is doing a better job or Canadian companies are doing a better job of retaining their, their talent. I think you did this topic a, just like a really good justice you've, you've covered pretty much everything that I thought about and I'm not even, there are a few points that I could probably touch upon for you. But let's go to Jason to kind of get your perspective before we talk.

Yeah. It's just very hard to compensate whatever. Sam just said, like everything you've said, Sam is completely correct. I was just, I was just nodding my head like, yeah, yeah, but then like at least, and I'm, I'm happy you didn't go towards the all the quality of living and like uh the quality of living or my family is here or like all that thing because it can really get convoluted. What I want to add though is regarding the layoffs, companies that are based in Canada, right?

They have a lot more patients in Canada. Like their headquarters are in Canada, there's probably going to be less layoffs. It will be more stable, especially Ottawa, right? Ottawa is a government city. They don't like to live off people, right? And if you also compare all other provinces because nobody talked here about Quebec, for example, right? I preferably preferably prefer Quebec just because it's a small hub. Nobody if you don't speak French, you can't really get a job there.

So I mean, it's almost, you know, safe, I can say this is safe, right? But again, the tech sector in that region, I mean over there it's unity, right? It's games, right? So it's, it's whereas in the states um uni or unity is there too, right? But all I'm saying is that Canada has like a different also economic like economic structure, right? Our tech is based on our, we create tech to improve our lives, right? So companies here are pri primarily residential.

Well, in Canada, in Canada, the big economy factor is residential, right? And agriculture, right? And tech companies will technically based or if you're trying to see demand and how you can add value to the world using tech and the world with Canada using tech, right? You'll probably create software for residential and agriculture, right? Because those are the big sectors. Whereas in the States, I mean, there's a plethora of industries that require tech, then they're more open to it.

They are also more risk and in Canada we're very risk adverse, right? There's no like, oh YOLO, right? Or I'm just going to put my money into this company and YOLO, right? Or like I'm just going to like, you know, put all my money and then live like live on the couch, right? Like, you know the California mindset, right? Oh I put my buddies and then I'm sleeping on the grind mentality of the Yeah, exactly. It's not like that in Canada.

And so you also see that where places where there are more risk. People are more open to risk. You're typically gonna see more economic growth. That's, that's what I want to highlight. And don't forget the publishing of Canada is like 3 million, 38 million I forgot and 35 and the publishing of California is like 37. Right? So we're pretty much just about like, there's, there's almost, I'm Canadian as you can see from over here and you're working in Canada, right?

I am working and living in Canada and the economy of, I mean, if you want to compare apples to apples, right? California versus Canada, they have like similar population, right? The economy is for tech, the tech opportunities in California is just way bigger than the whole entire. So, so let me ask you a quick question that I should have asked Sam if you were to choose, which would you choose? Just Canada or the US, like the job you're doing right now, right?

It's complicated the job you're doing right now or in Canada or in US, bro, I'm getting underpaid so much. If I go to the U SI can at least make at least 70 K more or something like that. So is that the US then is that your answer? Like we're not, if we're trying to get to the quality of living part, you know, quality of living of living just based on everything you've said, right? Where would you rather work? I'd rather work in the US but live in Canada. How about that?

I see what you see, Sam already put in the chat, the US. OK, cool. All right. Now for the time for Emmanuel, I think Emmanuel, you're very interesting because you actually are the person who has experience in both in the tech sector. So please take it away. Just tell us what to do, teach us. Well, I think, you know, Sam and Jason covered this topic, but I'll cover you from Manila dimension.

If we are to have truthful, honest, intellectual conversation about us versus Canada, I think we need to look at what you're optimizing for right at the bat. Um Because when you're in that position, you need to, you need to really think about like what you optimize for. For example, II, I lived, I lived in Canada before and I worked in Canada before I moved to us where I'm based in California now.

And I've seen folks while I was in Canada that lived in the US and worked in the US, but decided to move down to Canada and work in Canada. And I've chatted with them about this topic. So it really depends what you're optimizing for and what do I mean, if you're optimizing for compensation? Well, you better be in the US pretty much, you will not get paid.

You would, the chances of you getting paid for the same job in Canada US is very hard to find you probably get paid more in the US from a compensation perspective. Why? Because it's just more competitive over there. But even when you're talking about what you're optimizing for, I would say the government and the the external factors of like, you know, government legislature and stuff plays a huge aspect. So for example, what do I mean?

Right, let's say you, you, you optimize it for compensation and stuff. But you also have to keep in mind immigration, right? Immigration is slightly, I would say maybe slightly harder in the US long term versus Canada with Canada has like more streamlined path. So you have to really think about these things, right? In terms of, you know, opportunities for you to, you know, either focus or a diverse experience in your career.

You know, you probably head down the line of, you know, America right at the back, right? It no more population, more stuff to do. Uh the tech space is large, um It intersects like a lot more areas, right? What did you think about that? But, you know, then II I would say like from the folks that I've even chatted with a huge thing is family, right? And I'm, I'm kind of in this position now where I'm thinking, hm, where do I want to start my family? Where do I want to raise my kids now?

Now that I'm in the US? Hm. And I'll be honest about it, like, you know, I'm thinking Canada, you know, do I wait? Ok. Well, I'm optimizing for compensation, short term and career experience so that I can get to a certain level. I have a breath of experience in the industry, you know, network and stuff. I meet people. But when I'm thinking about family, I'm thinking about kind of like the Canadian society more as a place where I want to raise my kids. It's just a preference.

Are, are you, are you referring to like the suburban vibe? I I refer to the suburban vibe. I'm also referring to the things beyond. So for example, the social factor, OK, legislature and stuff. Um I feel like I think go on what I was thinking was so this is my perspective and obviously I'm gonna say the US. But when people think about Canada versus the US, the thing about the United States is that you're right, Jason, you talk about culture, the United States has 50 States, right?

And they all operate differently. They are state. If you want a specific flavor, you go to that state.

If you want, if you want the Canadian snow, there's like 10 states that have that, that the mountain ranges, the the culture of, you know, snowboarding and skiing, you know, up north, if you're looking for the more family vibe where it's more country like, you know, like there's, there's, there's North Carolina, South Carolina, like in my head, I'm thinking like whatever I need to get in Canada, one of these 50 states will have and Washington, right,

one of these 50 states will have will give me that while still being in the US, right? So you're still optimizing for compensation, while optimizing for legislation, um school Children, family, all that stuff. Uh because all these states operate so differently from each other, they have their own laws, their own style. Um If you're, if you're looking for the beach and water, there's like a couple of states that can grant you that.

And if you really still want to feel like if you want to feel like you're in BC, just go to Seattle, it's, you know, it's like, so I feel like you get, you know, when you do in math class, we have the Venn diagram and you have subsets, right, whatever it is you're looking for in Canada, I think you can find that and more in the United States just because of the vast diverse, you can disagree with me.

I mean, that's my perspective, but at the end of the day, I think that that's possible if you really do your research on the, on the different states, I don't know what you guys think about that. Yes. Let me chime in here quickly. True. In Canada, there are provinces, right? So if you're thinking about it from the state level, maybe in Canada, you're looking at it from provincial level. I'm thinking about it from a federal level, right? Because through every state will be different.

True in Canada, every province is slightly different actually. Right? But when you go one step above and think about the implication on the federal, on the States and the province, I, you know, I think you might as, as someone who has lived in Canada, when you're, when you're optimizing for family or for setting conditions that are not compensation or completely career focused, you might scrutiny with Canada. That's not to say there are not room for improvements there uh in Canada.

But yeah, for example, child care uh uh and how the government federal level impacts that. So you might, you know, there are different factors there but you know, in terms of just pure compensation, career growth, access to some of these employers, this massive employers, I think you might skew towards the US. Um Jason, it looks like you have something you want to talk about. Not just that. Well, I want to talk also about bringing tech, right? Like Canada is a growing tech sector.

USA seems like a very established tech sector, right? If you look at some provinces, some provinces uh goals, right? Even go to the Quebec site, whatever or the Toronto site, there's a lot of programs by the by the government to, hey, if you create your business that's in tech, right? We can help, we can help compensate you, right? We can we can support you. There's a lot of those, when you go to the government, when you go to the individual government's websites for every other province.

I know Quebec has one. Right. I know Toronto has a big one. Right. I didn't check for, I didn't check for Saskatchewan or Manitoba. There's not a lot over there but there's that too. Right. It's a growing sector. So we want more people from the States, people from the Europe. Europe, people from everywhere, immigrants to come to Canada, right? And build that tech foundation, not just that they didn't, cannot create the internet. Is that, is that true or am I am noise? History?

Oh my God, my bad, my bad, my bad. I think the end at the end of the day, happiness, right? Like where do you feel happy? Where do you feel fulfilled?

So if, if, if, if for whatever reasons, you know, at the end of the day, you feel like you, yes, you're earning money in the US but you don't feel fulfilled, you don't feel safe or you don't feel comfortable or you don't have family with you, but Canada is going to provide all those things, you know, at the end of the day, it's gonna be individual. But what's important for me in this podcast is for us to bring and we've already done that so we can move to the next topic.

But it's for us to educate those who are listening and probably considering both options and say, hey, this, this is our experience um from Canada and the US and hopefully that can help them. Anyone who's listening perhaps make a more informed decision. So does anyone have any thoughts on, on, on this topic for benefits as well? Um Benefits, tech Canada versus tech USA type of work on average benefits, right? Like which ones which country typically has better benefits in tech for work?

Emmanuel and Sam question? Are you talking about like, again, this, I feel like this is a quality of life question, but I feel when you talk about benefits, you're talking about like for example, like days off that type of stuff or I don't know, like I know certain like Canadian companies or companies that operate in Canada will provide um subsidies for like childcare or, you know, little things like that, that, that add up.

But honestly, I feel like that's more of a company to company type uh policy but, but it's also a country thing where as a tech company, if I'm like, if my hub is in Toronto and I see that again, these companies are very, very competitive even with their benefits uh packages. Like if I'm company A and company B CD and E provide four weeks of paid vacation and mine is like two weeks, I'm probably gonna have to readjust that, right?

So I think it's all down to again, the societal makeup, I feel like in the States it's more like let's get to this money type. You know, I feel like the quality of life conversation is a little bit less important and I think this is consistent with anything else, even outside of tech, just any industry like the United States is, is a, is the home of capitalism. So the aim is to make money first and then everything else is secondary.

I think Canada is a little Canada likes to say it's a capitalist economy, not really, it's more like a social. I'm not again, I don't want to get philosophical but I feel like it's more social uh capitalists if, if that's even a thing. Uh So I think that affects even, for example, the benefits that companies provide for.

Like I, I know certain companies that if they operate in the States and Canada, their benefit packages are clearly different because you have to cater for each local that you're in. Fair enough. Yeah. Thank you, Sam. I think um you have, you brought some good points there. I want us to move to the next topic though. Um And the next topic is talking about programming languages and there's two, there's 222 main things.

I wanted us to talk a little bit about SQL versus KQL or SQL versus no SQL and then to talk about what are the benefits of learning languages like Golan or javascript? Um And especially now that we have A I on the rise. So we're gonna pass that to you first, Sam, what are your thoughts on the different programming languages out there? The best one to, to, to, to start learning if you haven't learned any? And what does it look like for the future? Ok. So off the bat, there's two important things.

One as a software engineer, one of your abilities is your ability to learn a programming language. So if you meet somebody who's a software engineer and they only know one programming language, there's probably something there where maybe they've just done that for such a long time or, you know, and that's fair. But I think part of your value in this job market is your ability to acclimate to different um environments.

Like you move to a different company and they don't use Java, they use Python like uh and as you sort of go up in your career, it is important that you have the ability to pick up new programming languages. Now. No one is saying that you have to be a pro at all of them, like the number of programming languages. I know probably north of like four or five. But does that mean I know all of them at the same uh level? Probably not, not even, probably, definitely not. Right.

Again, it depends on what you do most of your day. Like what, what do you use most of your day? But the second point is it is also important to have at least one programming language that you're very strong with. So it's a double edged sword on one hand, you don't want to be so tied to one that you don't have the ability to understand other programming languages. And I think that's even impossible. Like if you're able to learn one flick, you're able to learn a multitude of them.

Honestly, I think it starts to come down to like preferences. Like I hate anything in the C family. Like C C++ C#. I think they all look awful. The syntax in my opinion is just not nice. But that's just me though. I love Swift, even though it technically is off, it's an offshoot of uh objective C but I like the newer programming languages because they, they solve for, you know, just ease of use, they're much easier to learn. So from that perspective, I think it's easier to pick.

There's so many you can pick, you can pick Swift. I think a lot of people start off with javascript. I argue that javascript is arguably the simplest to learn, in my opinion, javascript or if you really want to focus on like object oriented programming stuff like Java is really good. No, for Python, when like Python is just too much sugar to teach people with like, you know, there's so many, there's so many stuff happening. What do you mean by sugar, please? So much?

So like Syntactical sugar, we, if you ever looked at Python, some of the stuff you can do with like dictionaries and lists make no sense. Like just looking at it at face value makes no sense. And I'm, I'm worrisome of that because if you're teaching somebody programming languages, I'd argue that it makes sense to teach people fundamentals. So when you have these programming languages that are, that have so much like syn tactical sugar because they're trying to make it easier and quicker to use.

Now, people don't get a sense of the real underlying logic that's happening. And part of learning programming languages is learning to logically think I'd say that's the most important thing because all the languages that, that's all that they are, they're just commands that honestly you can Google and like, if you forget it, it doesn't mean much, but it's the OK, what should I do in terms of what um like what uh data structures that should I use here?

What makes sense from this perspective and what from that perspective, uh what's my consideration for like run time or space complexity? Like those things matter more than the actual programming languages themselves. But the differences with the programming languages is they all implement those things differently. Well, not all of them, but there's, you know, variance between each programming language and various and like computational uh performance and all that good stuff.

But to tie a bow on my point, I think it's important to have at least one programming language that you are definitely strong with because when you go to like interview for companies, it'd be crazy if you didn't have one that actually let me share it. Uh Let me share a little, a little story. Before I end, I had an interview at this time, I was doing like full stag, but I was also doing I OS but this is before like I started working full time.

I was um I was, I spent like the last month or so working on like a javascript uh project. But I was interviewing for an I OS role. I got into the interview. Nervous as heck again, this is like my, I was, I was a interview for an internship. Nervous and I legitimately forgot swift syntax that I've been working with for months. Do you know why? Because the last month I had literally just been doing javascript, javascript, javascript, javascript, javascript.

Like I started to get confused like, oh my God, dude does Swift have lets or is it constant or what am I? I could do? Not. But they were, they were, they were cool enough to let me take a step back and you know, gather myself. But the point I'm trying to get at is have one programming language that you're very good at. You're very strong at.

But then the moment you have that I feel like inevitably you're going to have the ability to learn other programming languages very well said you should learn C why do you CC is like the God of like, like if you're a beginner and you never quit your life, you should learn C it was the first, was the first programming language they taught in, at UIC, right? Yeah. But my thing we see is it has no value, in my opinion, it has no value in the current job market.

Like, how many jobs, honestly, how many jobs have you seen them post and they're like requirement. C just tell me off the top of your head. How many? OK. OK. But the goal is we're not trying to get the job. OK? There's two aspects of this, there is getting the job. There's also learning a language that can help you with the fundamentals upwards, right? I think C is a perfect language. Like I learned my first language was javascript.

OK. I learned at 16 and I completely forget and I got to computer science again and I learned, I learned, what's it called? Was it C# C# was the first language on C# second language, right? And then going from C# to C was almost like a brain. Like what's going on here, right? Like there's a memory, there's, there's make files, it's just, I think that and there's, it's, you have to have structure and see, right?

I think with C if a beginner were to tell me if somebody that had no experience whatsoever were to come and say, hey, hey, I know C and I know a bit of javascript but I know a really good c and the job posting is just for internship, like, you know, uh, nothing. Right. I'd hire a person with C because, well, at least he has the fundamentals to learn other things like C# go, right. And I, all that jumbo. But like you said, like language is a language is just a language, right?

Adapt it to your, no. And Java, I don't want to touch any Java. I don't say no, I don't like Java. So pick a language that you like, right? And that aligns with the work you want to do, right? And then get good at it and that will get you the job. But you said, you said how many jobs you're right. I haven't seen many jobs that say C but there are jobs that will say C you just have to actually look for it. Maybe they are not as many as they used to be, but you'd have to look for it.

And, and I agree with Jason that C has, I don't do software programming on a day to day basis. But because of my knowledge of C, it made it easier for me to understand HTML javascript. Um even powershell Python just because it, it gave that it's close enough to, it's not assembly language, but it's that fundamental understanding of what does it mean to think logically and actually program, but I want to hear your thoughts. Uh Emmanuel.

Yeah, I think as an engineer um or if you're even trying to get into that space, you should be thinking about programming paradigms, then start boiling it down to what you're like the, the various languages, right? So programming paradigms, you know, back in the day, you, you know, we have, we, well, we, we still have imperative and declarative. And back in the day, it was more procedural programming like four track. Um then we moved on to object oriented.

So as a beginner, I would strongly advise, you know, dive straight into object oriented programming, it's structured, you understand the fundamentals, you understand data structure. Do you understand the behaviors of components? I think this grounds you and, and I want to believe why this is why a lot of companies perhaps go the route of interviewing people about data structures because maybe they want to boil down to the fundamentals.

How are you going to structure a code or an execution flow and represent this in some sort of object and with some sort of association, right? And you know, with object oriented languages, you have Java, all this fun stuff, teach you about very complex topics and which is what a lot of, you know, universities uh teach for a good reason.

I think now in the real world while you're working now, this this might not completely hold because you as, as your experience goes, you realize that you're moving from, you're combining object oriented, reactive programming with logical programming and functional program, right? And you can start mixing the two of them. So as an engineer, I don't think you should, you, you probably will not boil down to focus on language. You probably boil down on paradigms.

You probably boil down on patterns, you probably boil down to how to solve problems at a higher level. Uh then language it just becomes syntax. Now, as a beginner, this is slightly different. Uh as a beginner, you want to understand object oriented programming so that you can explain things clearly to uh in an object oriented way, in such a way that what you're trying to explain is representable. Then if we now go down to syntax as to specific programming languages, I started off with Java.

That was good and fun, not so fun at the moment, but gave me the fundamentals that I needed to go. Right. Then II I, then I work primarily with Swift. Now I I messed around a little bit of Python. I didn't really enjoy Python. But the fact that I understood Java made me kind of relate to what Python was doing because there's just a lot of syntax sugar. There's just a lot of things that are pre built that you don't even need to worry about.

It's like magic, you have access to all this already computed stuff and you just need to do something and it disappears and it just works, right? And that's all great if you're in like the machine and its space where you use the Python and stuff, right? So, but to begin, I'll say, you know, go down to object oriented languages, learn those and I think you'll be good. So, so thank, thank you there. I want to find out from you guys, you know, in terms of specific languages, right?

So go SQL, which is a little bit different and KQL, which you guys may not be aware of except maybe Jason myself. And if you guys have played KQL before, which are, are, are, is it worth it learning any of the uh of these languages or new SQL? For instance, before I answer that, I just want to ask one question, Emmanuel just very simple, Java versus C, I just want your clear concise answer. Don't think, don't give your explanation, just Java or C you have to explain, you have to explain.

Oh no, it's my question. Let me ask Java. Yeah, scary. Well, now a lot of people might have like different opinions but from my own experience of learning Java, I found it easy, easier to comprehend. I've do a little bit of object to see it's some flavor. But Java, I think when you go from Java, you understand some basic concept that maybe you can dive deeper with C and stuff. But I can honestly, basically no one wants to hear about c Now let me answer.

There's no SQL versus he's taking, he's taking advantage of the whole entire podcast. Let me Jason, I, I'll, I'll let you rebuttal in a second. But let me just let me get this off regarding um SQL versus no SQL.

Learn whatever man I like again, I don't think there is a clear winner in, in, in that debate, I think depending on whatever company like we played around with uh no Sqo with Mongo DB, we played around with, I mean, Fires Store is, is, is no SQL as well, but we've also played around with post graphs, you know, so like have experiences with all of these because ultimately, the most important thing is what are all these things trying to do? They're, they're for accessing the database, right?

You're trying to read, right? You're, you're performing operations on a database. So that's what matters most like knowing how to mutate values, how to retrieve what are the best practices for uh security? What layer lives beyond what layer? So that um someone can't just save like a random script. And then the moment you try to retrieve it, your database is just spitting out all the information inside of it, right?

So those are things that matter more than actual SQO versus like no SQO it's the same conversation with like programming languages. All these things are are tools to access the underneath inner workings that actually power your, your, your software. So, like, uh I know myself have worked very extensively with Fires Store. Um, but we've also worked with Post Grass, right? So there's no SQL there and there's, uh there's SQL.

So there's all these different syntax and all this again, they're just tools at the end of the day. It's what are you trying to access the database? That's what matters most in my opinion. I think that OK, I'll drop the C thing. OK? We can have another debate on let's drop the CF because some will fight us. But like in terms of it's just like picking the right tool for a job, right?

But in terms of my experience because I'm a college engineer, I don't do that thing anymore, but it's just knowing the right tool for a job, right? So let's talk about SQL versus no sequel. OK? Sequel. If you want SQL, right? You want, you want consistency, right? You want relation, right? No sequel. You don't care about relation, right? Just want to get the job done. SQL is good for like I think it's AC ID. So like atomic consistency guessing with the eye uh and then durability, right?

So basically knowing what advantage each tool has is good. Also, don't forget there's also cloud databases as well, right? Obviously, Firebase is a cloud database, right? But when looking at the Azure, for example, I mean, there's uh Cosmo DB, right? Like knowing which database to use in the cloud, right? Um There's Cosmo DB and Cosmo DB can have Microsoft's own um database, right? Can also have uh you know, post race uh Cosmo DB, right?

So basically know what, to know what tool you're using and why you using it. That's kind of like, can you talk a little bit about KQL for those who don't know. So KKQL is a graph query language. Oh, sorry. It's Graph KQL is a Microsoft main query language, right? So you wouldn't learn KQL to work at Apple. We use KQL, but you use KQL if you have, if you're on Microsoft, right? And you want to query a lot of data, right?

In the Microsoft Management environment, for example, and KQL is very similar to SQL. So no SQ SQL can really makes it easy. Yeah, exactly. Yeah. OK. Yeah. You guys are, I hope that this is going to be useful for, for those who are um listening in terms of just programming and which one to start with or, or where to go um from that perspective. But just for listeners, the eye that Jason was talking about is isolation.

Um Does anybody else want to have any, have any thoughts on programming languages or uh you know, go lang or any of that before we move to the next topic? Because the next topic is kind of related. We're talking about API S. All right. So sorry, go ahead. I think we're good to go. OK. So Sam, tell me a little bit about your relationship with API S man.

I have a love, hate relationship with a PS but mostly love because it saves me a lot of time with having to build out solutions all in one module. So I don't have to be responsible for delivering the entirety of a feature end to end, right? So another team can be responsible for building out the back end functionality and then they expose that for us. Well, actually, maybe I should back up a little bit and explain what a rest API is. Yes, explain. Yes, thank you. What?

So let's there's probably people who are listening who are like, yeah, these guys are talking about API si have no idea what that is. So give an analogy if you, if you can cause that would probably bring it down to earth. Hold on. Let me, let me remember what a application API explain API first. What is, what's the, what's the acronym or the whole word was the application program interface? I believe that's what it stands for.

I remember this, the the the meaning of API might be a little bit pointless if we don't explain what it does. I think explaining what it does is a better way of grasping it. So an API but but also sorry to interrupt Sam. But also too like how has that helped you at work? Because it's one thing to talk about like, oh general but like, no, for real, like I have a project that we needed to do XY and Z, you don't have to give all the details.

But like this is why the API was necessary and this is why it's good that I know rest or post or whatever the case is, right? So I wanna start off with what an API is. An API is basically a way for computers to talk to each other. High level. That's all that. It is, it's a interface if you will wear one computer, one computing resource.

So it can be a mobile phone or it could be a computer, it could be a server whatever can ask for and or send resources to another computer resource or computing unit. Again, I don't know what a better term for that would be, but basically, it just allows communication between my computer and Emmanuel's phone or like a s usually like a server and a client. So a server as the name and as you can infer is something that is serving information or receiving data.

Uh And then the client is whatever actually makes use of said data or sends said data. OK? So now we understand what an API is, what is rest, rest is along a family of different like paradigms along how sorry they describe how we want to arrange API S. So you have stuff like soap, does someone know what rest stands for like the full rest. No. Ok. Wow. Don't know. That's, that's, that's disappointing. But anyways anyway, so r basically describes a couple of. So, so do you, can you tell us?

Oh, I have no idea. I was, I was asking, oh, that's yo, I don't know if it actually stands for something like r est. I see. I, I'm checking right now. It is. Seems like rest state representational state transfer. Really? What, what does that mean? I have no idea what that means. But OK, yeah, so back to rest, the, the, the gist for rest is rest describes a bunch of operations that you can do or you can perform with the resource. So you've got stuff like put post get, delete. What is there?

An update? I think update is put still. How many are they? 12345, give or take? I think there's also a couple that you almost never use. But the most important ones are delete, put post get and those action words, those verbs are exactly what they sound like. So if I'm posting something that means I'm sending out information. If I'm getting something, I'm trying to retrieve it. If I'm deleting, I'm trying to delete something.

And basically by defining what operations you can perform on an API we're able to structure the end to end um interaction between a client and a server. So I'll walk you through a simple, very simple um use case, let's say I have a mobile phone, right? And when a user logs into my mobile phone, I want to retrieve their information but their, their information doesn't like it doesn't live in the mobile phone.

Like again, we, we live in such a massive tech uh environment where your data is probably not in your, not probably your data does not live in your phone. Right? It lives somewhere else. So in order to retrieve that, we need to talk to another computer or another server and we do that through, you guessed it an API. Now, if I want to retrieve something, I'm gonna use the get operation.

And you can see that we, we're able to build more complex uh situations, more complex applications using these, there's just a couple of keywords, right? So now that we understand what an API is and we understand what rest allows us to do. How does that factor into your day to day? Well, pause for a second. Actually, I just wanted to clarify. Yes. Emmanuel is right? It is representational state transfer. But it's interesting because the re is in one word representational, right?

And then state transfer. So we get rest. So who you know, it's one of those things where you use it, but you don't necessarily know the meaning like you don't know what the acronym stands for. And um before I hand it back to you, Sam sorry to interrupt was you talked about gets, you know, et cetera. Uh And I know we finished the topic of, we kind of wrapped up the topic of, of, um, languages you should learn.

But one thing I didn't jump in to say is for those of you who don't want to be software engineers or who don't see yourself programming or working with, you know, swift or, or, or anything like that. But you want to go into another aspect of tech, which is it or you know, um information systems management, uh maybe even cloud management, powershell, you can learn powershell. I mean, there's so much you can do with powershell when it comes to working through with computers.

Um whether you're talking about active directory or, or Azure active directory, which is called in ID. Now, whatever the case is, you have a lot of power, especially when it comes to Windows with powershell. It's in the name powershell. I it's something that I encourage people to learn and it's not necessarily a programming language, I would call it. It's more scripting, but you can script a lot of things. You can do a whole lot with Powershell. So you might have something to say.

Yeah, you might have something to say. So yeah. Sure. Yeah, it's funny that rest stands for representational state transfer state, but it's a state that is very interesting because the server actually never keeps record of any state. So it's, it's once you start peeling down the layer like you, you start to realize maybe you need to take the, the, the meaning with a grain of salt a little bit but, but tying into, oh where was I? OK. Yes. What is that?

What is rest in, in an api what, what, what does that do for me in my day to day? So the first thing I'll say is data is so multifaceted and how we handle data, it requires us to have sophistication. There's a level of sophistication, right? It used to be back in the day where you would build an entire application and everything would just live in one place, but that's not scalable, right? You you deal with issues of scalability, but then you're also limiting the level of innovation.

So typically what happens is you have a database, your database is really in some data center, probably Amazon or Asia or Google cloud platform, like your data lives somewhere, right? But not in your mobile phone, right? And so with that means there's other other layers that exist away from the actual device that's consuming this functionality, right?

So we need a way to tie every part of that together so that when you open up your mobile phone or when you use an app, all you see is exactly what you need. You don't have to worry about how it got there. Like that's the whole engineering endeavor. So then tying it back to like what you would do in your, your day to day at work. Most times when you work at, even honestly, any size of company, there's always different parts of an engineering team.

So you've got people who are more primarily interested in like the back end capability, you and talk about backend engineers. You've got people who are more like database and or slash infrastructure, right? And so rest api enables all these people to talk because now they're able to consume the resource that each unit is responsible for.

So at a tech company, it would be impossible to do your job if there weren't API S there, if there wasn't a way for the database to be connected to the back end and the back end to the front end, nothing would happen or not even not that nothing would happen. There are ways to make it happen. You could put everything together but you wouldn't be able to scale vertically or horizontally. The other cool thing is, and I'll throw this one in there because it's a buzzword with machine learning.

The easiest way to consume the information that a model um produces is through a rest API, right? Like Amazon has uh I forget what the service is called now, but you can train a model and it'll automatically generate a rest api end point for you to make use of it. So I was working on a feature at work recently and it's like a prediction uh type model and all you'd have to do is send to it.

So post, so we post like a query like we can say men's hat, for example, and the that, that query is gonna go to a model that has been trained by our A I team and it's gonna return me some information. So that's how I use rest API S at work. I use rest API S to get like user information or you know, some back in functionality. The point I'm trying to make is rest API S. They're the things that basically make communication happen between back end, front end database and everything in between.

Thank you. I think you gave a pretty good, you know, one on one class on, on API S there. Um But uh Emmanuel, what's your day to day with API S? Do you, do you interact with API S at all or is that part of your job these days or, or no? Yeah, these days? Oh OK. Let me take a step back API S come in different forms. I think it's important to think of a PS as interface. For example, A PS don't necessarily need to be rest API.

So between some back end server API S could just mean some sort of way of communicating between a way of communicating, it could be communicating between the modules between an application, right? So for example, I used, I, well, I use APR for example to communicate between a module to another module. So a subset of code in an application to another for no, you can link at a PS almost, right? Maybe as functions, right? So in the class I have a function that maybe does something, right?

For example, function prints hello world. And in another class I have some, some some function that takes some sort of prestate, right? Um So and I'll take a step back the class, what's an interface? What's a function? I said a whole lot of stuff. So maybe what it's important to understand that API S are just a way of communicating, right? Uh In my day to day in swift, that's how I encounter API. I don't want to go into details of what a class is, what the interface, what a function is.

I'm going to give you a basic of programming. So let's not do that, but just think about it as a way of communicating what I, what I want to dial back on actually is between restful API S. We, we have something called, you know, uh R PC, right, which are procedural calls. So like how some explain rest with API is where that's a way, be a way you want to communicate. Importantly between two in it could be two between two independent systems, right?

So back in clients, server and clients, my presidio calls are slightly different where you want to communicate the procedure, the function itself. So it's, for example, you can have a client that has the implementation of, of what you're trying to do uh as like or maybe like a server or whatever that has the, the actual concrete implementation of what you would want to do.

And your client has the representation of the function and you use R PC to execute that function that has the implementation, right? So it's a way of having like um a presidio call. These are very neat, these are very neat like techniques. It's, it's a way of it's slow, it's, it's, it's not a type of API. So I think it's something to, to look at. So R PC is, is a, is a type of API where you execute like presidio calls.

Whereas restful API S are where you communicate between independent systems, they state based R PC. On the other hand has context of state, right? So you're passing in the function and the parameters, right? These are modern ways in, in, in the past, I've used our P CS to communicate between distributed systems uh for some complex operations, right? Uh where I, I have a client that has the representation of the function that does and that has the data imputes from something else.

But I have some distributed system that is supposed to execute that function with that data and how do some sort of load balancing for the complex operation, right? And then you use RP CS and, and the way the language I used for that was Golan. Uh That's something you can look at. I would give Peter a link where you can actually like dive into this, this topic. But I thought that's actually something I wanted to ask about.

Yeah. Yeah, because it's easy, you know, some people like, all right, this sounds interesting. This is actually worth learning. Where do I go to improve my skill sets on this? So um if you can send, yeah, I see the link now but if you can send it to me, um that way I can put it on the actual youtube video. But Jason, what, what is, what, what do you use at your job? What do you do with API S at your job? And I, I have an idea but I just want, I wanna hear what you, what you usually do with it.

If you, if, if any actually API S, what do I do? I don't really like call the APIS, I don't even build the API si know how to configure the API S. So how would, how would I, how, what do I do with an API? Right? I would create some sort if there's the developer that's a back end engineer, he screened API locally, right? I would take that API that works on his computer and put it on the cloud so that maybe Sam and Emmanuel can all fetch it for example.

And that is called and there's a lot of, there's a lot of different services that provide this, right? It's not just the big three Apple Microsoft, sorry, Google, Microsoft and Azure, right? The call providers, you mean AWS. Exactly Azure and GCP and API is like there's a, there's a coding part, there's, there's a bringing it to the cloud, there's a lot of things I can go into details. But let's say for example, you are an API company, OK?

You're an API company and you have a lot of people using your API, right? Like take for example, the weather network, right? The weather network has a lot of A PS, right? How do they prevent how they protect themselves and the rate limits, right? So what a clown engineer probably do is they would find a way to limit the A P for being called, right? Be like, OK, you know what you have all you have, we are allowed to call this API 50 times, right? Or we return a 429 error.

There's something you missed there, Jason what the weather company has an API why? Because they he they want us to use it to do what to put in an application. So that, so that what happens? Like what, what is the end user's interaction so that the end user can see the API the the user can see the front end. So good question. So the end user sees the front end but they don't know what's going on right in the back end. What apps do we, what, what is a common app that anyone can actually answer?

What is the common app that people interact with on their iphones or Android that use? Like it's, you know, it's very obvious this is, it uses it calls API S but we just end users just have no idea. Like 90% of all apps, man, 90% of all apps api somehow your own API, some third party API S are, you know, so he, he, he, he spoke about the weather app, right?

Like, so when you open your computer or you open your phone and you see, you have a particular app that tells you, you know, it shows, uh, it's like welcome and then it just puts your name and it has the weather, it's like it has the sun shining or it has, it shows like raining because it knows your location. And this is just for people who don't have an understanding as to like, why does this even matter? You're like, wow. You know, this is pretty cool.

It said, well, Peter and it shows clouds and it's raining because I'm in Seattle and it's raining today. That's very cool. And you scroll up and you, you interact with the app. It, it ran, it, use a, use an API to probably with the national Weather service maybe or, or some other company to be able to for you as a user to interact in that way. It's not that the app itself is necessarily built to have consistent tracking of the weather all the time. Right. So that way they can just, sorry.

Go ahead. Jason. Yeah. No, you're correct. Yeah, that's it. Keep, yeah. So I just wanna, and my point is to, to bring it to life, right? Like, let for those who don't understand API S like this is why it's important you're dealing with it every day and programmers need it because it makes another thing I want to talk about.

So in the IT world in in cloud and I was kind of thinking you talk a little bit about this, but so in organizations and this is my experience with API S recently, their organizations have apps, they have, they have enterprise applications in their company.

So you, you, you let's say you start working at company, a company a you log in uh you might see salesforce, you might be able to log into sales force, you might be able to log into box as a company, you might be able to log into udemy uh with your company ID. There are lots of other ones. Um but you know, so many applications, enterprise work day, for instance, like there's all these huge enterprise wide uh applications.

So if you've worked at any company that, you know, gives you some kind of package, say, you know, go here for for payroll, go here for hr stuff, go here. These apps, these, they're called enterprise apps. Those apps need API S to be able to retrieve your information from hr or from specific database, right? Because the app itself is not actually holding all that information.

So when you are configuring the application to be launched by the company, so we're working actually, I'm on, I'm on a project with a Canadian company. Very interesting. I was selling Jason about it um a while ago, but a project with a Canadian company and what they're working on is they're, they're onboarding large um like service now, Oracle sales force onto the Earth into Azure.

But they want their users to be able to interact with this and different rules but the users, but in order for the US to be able to interact with this in the right way, we need those API S to be able to call. All right, you know. All right. His name is Sam. Sam's role is manager of X department. Hence he has, he can, he can ask for a specific role or he can utilize Oracle in a specific way. Um And the list goes on and on, right.

So I just, I'm trying to explain like API S are used across the board and if you know and understand how to use API S or, or at least understand what they do, I believe it will be beneficial for you in your career entirely. But now with that said, um, we'll move on to our, probably Jason. Did you want to say something real quick? Yeah. My favorite API, we haven't really talked about this or maybe we have but is, is a really interesting API. Right. It's not a simple recipe. It's a web socket.

API. Right? So it's always on for some API S, some API S. Are you call it once it returns information? So my PIS are always always running, right? And you dive into that a little bit more. Why, why is it, what, why is it special? It's special because it's always on. So, and how does that benefit the end user? The user doesn't have to refresh the page. So essentially if there was no web socket, right? You wanna, you wanna chat your friend iMessage? Well, just imagine you send the message, right?

This they don't see the message, they have to exit the app, remove the app, like exit, like uh remove it from their memory and then click the back, click the app again. Thank you. See, see, like you now it's now you've explained the consequence of not having the web sockets to an end user. And I wanna make sure like when we're talking, we're talking high level and low level as well.

So like, yeah, you, you would have to literally close your app and otherwise you won't know if you got messages and some some messaging apps used to be like that, like a long time ago. Well, I don't remember. Maybe I was too old, too young, too young, too young, too young. But, um, ok, so, so that brings me to the next topic. Um, and Sam, you know, we'll run that by you first, which is front end or back end career wise. Which one? Oh, this is a dicey conversation? Oh, I don't know which to pick.

I've, I've, um like I said, so I'm a full stack engineer. So I've dabbled a fair bit with back end and front end. So primarily react uh for front end a little bit of view. Uh and then a lot of back end as well. But it's also interesting because if you're a mobile developer, you don't get a choice.

You're a front end and back end or logic uh developer if you will, regardless of your preference, like you're building the U I and you're also also writing logic that, you know, gets access, I'm sorry, gets data from like a rest API for example, and you feed that into, into the front end. But if we're talking strictly just web front versus back end, I think it comes down to your passion. I find that more people are full stack engineers out of necessity.

Um More than anything, I think a lot of people would love to just, you know, stick to one thing and just, you know, I'm a back end engineer or I'm a full uh I'm a full end engineer. So for those who don't understand um Sam, what's the difference?

So a front end engineer is tasked with building, you guessed it, the front end, the U I the user interact parts of the app that doesn't mean that they don't do anything logic based because again, stitching together like uh U I components, all of that is logic based as well, but they're primarily concerned about building out the customer facing part of the application. And the back end engineer is I I like to think of back end is you're building the functionality.

So usually you're the gap or you're the layer between the data layer. So again, if we assume that there is a database, your job is let me get the data. Let me, let me put it in a way that is usable for the user and then you pass it on to the front end or the user has entered some informa some data. Let me take that data. If I need to do some logic on it, I'll do it. But uh otherwise, if I need to send it out and get it straight to the database, that's what I do.

But again, this is an oversimplification of what these roles entail. But high level think of front it as user interact part of the application, they're typically skilled with stuff like react typescript. Um they're more design or I mean, not even necessarily design oriented. But their, their, their day to day works, their day to day relies on them working with like figs and figs like as a platform where you can, you know, write, you can design mock ups and, and and the look of your application.

So a front end engineer is more pre predominantly focused on that part of the application back end is I like to think of it as honestly everything but the front end so your your job is database and might even revolve around a little bit of security. You know, there's, there's a whole lot of things that fall under the responsibility of backend engineers as well.

But for me, I've done full stock my entire career and I can tell you that for me, at least I just don't see a value in having just picking one of them like I enjoy all phases of it and I don't think I would ever go into a gig and be like, oh, I'm just a back end engineer or I'm just a front end. Like I like I like the whole holistic, you know, process of taking something from the back end the database data layer to fruition and and having an actual user interact with part of the application.

Like I talked about it is slightly different from mobile where with mobile, those lines are so blurred. You're basically an everything developer, you're just a mobile developer, there's no front end back end, you know. So again, depends on what kind of system you're working on. But for web that's, that's a big difference between a full, uh, back end or front end engineer. In my opinion, I'd rather be full stock. Fair enough. Fair enough. Thank you, Emmanuel. What are your thoughts on that, or?

It's just that you have anything to add because Sam did cover it pretty well. Yeah. And I think about it this way, you know, like with full sack, it goes with the same, you know, like the Jack of all trade saying, you know, a jack of all trade is the master of none, but better than the master of one. Um That's the thing we fronted.

Well, you can't, it's, it's difficult to be a front end engineer actually because actually you need to be a uh it's difficult to be a full stock engineer because you need to first be a either a back end or, or front end engineer. You need to understand those two parts of engineering before you can call yourself a full stock engineer actually because you probably have there's a lot of intersectionality, right? You're bouncing off one. So you need to have good understanding of both of them, right?

Doesn't mean you have to be completely great for both of them, but it comes with experience over time now in my role, it's, it's a blend with mobile development, right? Because yes, you be in you, I you're building logic, you're building a like inter process communication, uh it gets there's different layers to it, right? So you need, you quickly realize you need to be vast in a lot of things as your experience go by.

But if you're starting off, probably you be more tasked with the U I side of things, be components, style, styling stuff, you know, basic logic of connecting different, you are making it reactive and stuff with swift. Um And as you go on, you now start touching things like multi treading as as you as operations, maybe going down to the foundation layer memory management. Right now, you are entering into a completely different world in the mobile development space, right?

Well, you're not really interacting with the U I component, you're you're interacting with how the how the system fundamentally works, right? You're more, I I think you're more of a backend kind of engineering mobile space then you, you realize quickly well to be a successful mobile engineer, you need to be V in both. Um and that happens with time.

So, so you said you need to be vast in both and I want to turn this question to Jason, how do you improve your speed or growth in becoming a full stack engineer? You just said you just put in the chat, full stacks are absolutely necessary. So where do you start? I'd say you'd have to start with the front end uh because it's if we're all visual creatures here, right?

So by starting with the front end, you're able to see, you know what you're actually developing, then eventually you might hit a limitation and say, well, my web app because web apps are, you know, everybody uses the web app, right? Can only do certain things locally, right? It has maybe some files that are saved, some images that are saved, right? And you maybe want to be able to fetch some information from this website. Let's take a Pokemon website, right? Pokemon API. OK?

But you can create, you can link an API is also by the way guys in the back end. OK? So you can fetch the API and then it will be on your front end. But now let's say you want to kind of twist a little bit, right? You wanna have your Pokemon plus, maybe you want to uh maybe uh change the description, something like that, right? You might have to get your own back end. OK? And the simple stacker for web, it's going to be different for mobile, right? It's just Jawas tripp everything, right?

So you're probably going to create your non GS server, sorry, your node server and you might and that will be your back end. So essentially start with the front end, right? And then start with the back end, little by little. And this way you can see what you're saying. Yeah. So start with the front end because you can see what you're working on. But I think Emmanuel actually asks a pretty good question. Uh, why don't you tell us a little bit about that?

Uh, Emmanuel, what's the job market for these types of engineering? Um, hm. What kind of jobs are they gonna be in, or what kind of companies are looking for for, for, um, engineers in front end or back end or full stack? I think comedies that produce that, that look, maybe we start with B to C company. So business to consumer type companies where they business to consumer type software as a service company where they there's some sort of application that consumer use this business, right?

Like for instance, for example, doordash right now there, they're gonna hire all of these type of engineers, right? The front end engineer is going to be either working on the mobile app or the web app working on the U I features. The back end engineer is probably going to be working on stuff with database on security or um analytics.

These are fun parts, the fully engineers is probably too also gonna be working on the same application but you know, kind of in a more generalized role could be focused, you could be, you could be a backend engineer that's also a full stack engineer. These can be true, they are not mutually exclusive if you are thinking about compensation. Why I find this varies even across companies, right? It could be the company specific too.

I find folks that are maybe skewed towards back end or FS that tend to actually have a higher compensation than front end engineers on perhaps web applications, mobile applications are slightly different I find. So for example, in the job market, a mobile, a mobile application engine, yeah, probably earns around I I would take maybe one of the highest scale there is because it touches on these two side of things too in some way.

But in the mobile ecosystem and it's very uh for example I OS development, right? It's it's a niche on its own. So you know, they they're in demand, there's a subset of people that can do this very specific thing. They need to have this broad breadth but also depth of knowledge. So the competition is higher, right? Front end engineer, I think it's a it it could be a saturated part in in in this three types of engineering.

I think it's maybe one of the saturated but depending on the specific company and what their values is and stuff you can get pretty good, very high compensation in this role actually because front and engineering is not easy, it's actually more complex than you would imagine. And then back in engineer engineering, actually, I I find it depends on the type of backing engineering and what you're working on to be specific uh that compensation test gets skewed towards, right.

So something to think about right? But I don't think you should venture into any of this engineering because of the compensation. Uh You quickly realize perhaps, maybe you should skew towards more your interest. Uh Then, yeah, at the, at the end of the day, what's most important is how, like I said it before. Happy, how happy are you? But really what I mean is how fulfilled are you?

Because at the end, you know, on no one's tombstone says he was the greatest swift or he was the greatest backend engineer of all time where he was, you know, he could, he could, he understood data structures better than his entire team. You know, it doesn't say that it talks, it talks more about the impact you had on people, the people.

So I said they're gonna put that on his, you know, it's people talk more about what was the impact that you had in your team as on a on an actual relational level with people, speaking of API S but really um human to human connections, right? There's, there's someone who um I think on linkedin, they said, you know, their, their title is hu the Human API.

And what I'm trying to get at here is that with all the information we've learned today and we've talked about today, the goal is for you to take that and say, all right, in what aspect of technology will I be more fulfilled? And do I enjoy doing what I'm doing such that I can actually make impact on end users by help.

You know, the fact that people are enjoying doordash or enjoying iMessage, facetime, et cetera brings a certain level of, of uh fulfillment saying I am part of something bigger than me or in your team. You're not so bugged down with the amount of work that you have to do that. You forget to care about the people you work with because you have no idea the kind of impact it go how far it goes when you take the time to just listen to your coworker problem, right?

Or, or issue they're dealing with outside of work. And I know we're talking about technical things. But I I also want to mention like that is very critical because the more you enjoy your work for, for every type of technical role, whether it's full stack or, or you know IOT or infrastructure as code, whatever it is, um as infrastructure as a service, whatever it might be, there are people who are earning the highest amount you could like mind boggling compensation packages in any field, right?

In, in, in, in U I design, whatever the case may be. So you can still get there. It's just a matter of finding how to enjoy it. So what I want us to do in wrapping up is um Samuel Star and then Justin and then Emmanuel, what would you say people listening should take from, this is a technical spotlight part of the conversation. Like we've talked about a lot of things like if, if there was one thing you should go home with, maybe something you said or someone else said, what would it be?

So Sam, you start? Yeah, absolutely. I definitely echo a lot of your sentiments around making an impact outside just the technological uh endeavor. So the one thing that I've learned and I think would be a important value for other people is just follow what you're passionate about. Like, ultimately, there's conversations around compensation and quality of life.

All of that is going to be inconsequential if you're not doing something that you love doing, like I could be making X amount of money, but I'm miserable and I feel like I'm not, you know, making any impact or whatever the case may be. I'm not getting gratification then what is it worth? You know, you only have one life and it makes sense to pursue things that will add gratification to your life and will improve the quality of life for other people around you.

So my biggest thing, probably something I'm trying to focus more on as the year goes by is just pursue more endeavors that are um beneficial to myself, obviously, but obviously to the world around me. So yeah, just pursue what you love, do what you like, do what you like to do, but also doing all that requires listening to podcasts like this to help you see beyond your own, perhaps, possibly smaller scope of, of, of what's out there, right? Like I, I didn't know my job existed, right?

Is that self promo? That's crazy. Sorry. No, I'm saying is that a self promo for your, for your own podcast man is promoting his own podcast on, on my podcast? Of course. So just to you, sorry, just, sorry, not just the Jason second time. So I would say just, just try software that makes you interested, right? So if you're just trying to learn, I mean, if you're interested of anything we talked about in this podcast, right?

Just try it out, you know, go Google javascript, you know, and try to create a game that makes you happy, right? It's about Billings. It's not just about, you know, compensation, it's about building software that improves people's lives, but first as well your own. So if you're miserable, running the software, they might be miserable, right? They might be miserable using the software too. And your colleagues might not want to work with you as well, right?

So that's my two cents on, you know, being happy with your job and being a good engineer, at least. Thank you. I appreciate that. And sorry about that. My, my supervisor at work, his name is Justin. So I'm always kind of like we talk offense. I'm always kind of like conflating both of them. So, sorry about that now. Over to you, Emmanuel. What's the take home? Technical spotlight. A take home?

I think it's very, it might be good to think about what you're good at and what, and doing what you're happy at. I find this some, this, I mean, sometimes it could be, they could be the same thing. Sometimes they could conflict. So what you, you're good at might not be exactly the same thing as what you're happy doing. I think, I think it's something perhaps you folks need to digest more. Right. So maybe depends on where you are, the space you are.

You know, you might do something like good at but not necessarily happy at and then you might use that to get to some, something that you're happy at doing. Right. It might not, it might not always work exactly as I'm just putting it out there like, you know, things don't exactly work completely as planned where you get something that you're good at and you're happy at. Uh So, but I think it's good to try and optimize for both. I think that's a good, good takeaway.

I think it's, it's good to what I found. It's good to think beyond the role of just a software engineer. I think, I think, I think it's exciting initially after a while I, I find that I, I start to think about other things outside the world of software engineering. How can I, how can I make life slightly better?

For people, for myself, for my family and for my community in some way, either as an engineer, either using what I've learned as an engineer in engineering or, or something completely orthogonal. Right? I think that that's where, where I put it as. Thank you, appreciate it. So we're, we're wrapping up here. Um So this is where we do the social media plug.

So I'm gonna ask you guys where can, let's say someone's listening and they're like, man, I really love the way Sam broke that API thing down or man, I really need to learn a little bit more about what Jason does. Sounds super interesting or man works at Apple, you know, I wanna say hello. How can they reach you guys? If, if you want, if you'd like to share, linkedin is probably the best way I from, you know, my understanding but you know, feel free to share. Yeah, I've got linkedin.

I'm more likely to see your messages on linkedin. I'm at Samuel. So William, I think, I think Peter will, will plug this in. But yeah, definitely like to shoot me, shoot me a message. All right, in terms of me, you can catch me at Jason nguessan.com, Jason and guessing.com, you just go on my website and uh get in touch. So Fancy Major Flex, go to my website guys. Nice. I like that though. That's very cool. Thank you, Jason. Yeah. Uh Probably linkedin.

Um Yeah, most likely my linkedin, I probably would respond. Uh And I'm sorry for folks that I might have not responded to, I get to linkedin like it could be overwhelming. Uh linkedin can be overwhelming sometimes. So I, even with the whole news of what's going around in the world, sometimes I just try to stay off of my like sanity. Right. But linkedin, it's probably the best way. Nice. OK.

I'll, I'll put all the links in, in the description, whether it's on youtube or, or other places where people catch podcasts, Spotify, Apple music and sorry, Spotify, Apple podcasts. And the list goes on. Um I'm gonna tease a little bit of what's coming up in the next episode. So there are a couple of topics we didn't really touch upon and we hope to dive into those in the next time the next time we meet.

So that's, we're gonna talk a little bit about leak code and then, you know, I know that Jason and Emmanuel have some strong opinions on that and we'll talk a little bit about maximizing productivity. That's to say like, what are some of the tools set? What are some of the tools and, and uh software that you use or even techniques that you use to be productive at work and outside of work. And I'm not trying to promote the grind mentality of like work every day to you till you pass out.

You know, there should be a balance, I believe hard work is important, but not at your own detriment. But II, I think for listeners it would be good to share some of the tips that work for you. You know, how do you organize your calendar, et cetera? And one of the other topics we'll talk about next is the Hedonic treadmill and tech and meeting overload. Now that we're part, I know Emmanuel and Jason are kind of hybrid working right now.

So, in the office and at home, well, how do you handle the overload of meetings in your calendar? Or perhaps, maybe that's not the case for you. So those are some of the topics that will, we'll jump into and for those of you who are listening, I want to say a big thank you to, to you for joining us today and hopefully you enjoy the episode.

What I would ask of our listeners is for you to review this podcast, uh wherever you catch the podcast because it does help the show get to other people and whether it's on Spotify or Apple Music, more people are able to see it. And that would be great for us. I will try to work on a newsletter as this podcast grows. And now I want to say thank you to Sam, uh Emmanuel Jason, thank you for joining today.

Do you guys have any last thoughts or things that we should, uh, that we didn't get to touch upon that you'd like to share before we wrap up, go Niners Super Bowl. It might not just did a full body eye roll. What about you, Jason? I'll just drop the C thing, another podcast. Well, thank you guys for joining us today. It's been fantastic. Um Join us next time for more. Talk about software engineering, it, career growth in the tech space.

We're all young here, so we don't claim to have all the knowledge there is about technology, but I do think that we do have hopefully some experiences that can help you get better in your journey in tech, whether it's uh you know, whether you're starting or whether you have already, you've already been doing it for a while. So thank you all for joining. Uh We'll see you right here next time. Enjoy the rest of your day.