The Scrimba Podcast

Alex (00:01):
Hello, and welcome to the Scrimba Podcast. On this weekly show, I speak with successful devs about their advice on learning to code and getting your first junior dev job. I'm Alex. And today am joined by Ben Hong, a developer experience engineer at Netlify and a Vue.js core team member. You are going to love this episode with Ben. He is so very articulate and thoughtful. We discussed a variety of things like how, despite studying psychology at university, Ben learned to code by himself. From there, he stumbled into developer experience, which I think is an underrated place for new developers to look for opportunities.

Alex (00:41):
As you now know, Ben is a core member of the Vue.js team, so we also discussed Vue a little bit and how it compares to React and crucially, how Ben got involved in such a prestigious open source project and how you can consider getting involved in open source too. Make sure you stay tuned to the end because I throw Ben some fun quickfire questions. You are listening to the Scrimba Podcast. Let's get into it.

Ben (01:06):
Yeah, so I did go to college, but I did not get a computer science degree. In fact, probably the farthest thing from it. My background's actually in psychology.

Alex (01:14):
And where did you go from there?

Ben (01:16):
Where did I go from there? So my first exposure to tech was as a kid back in the days of, I'm dating myself a little bit, of like Aol.com and where the internet had really just started to become a thing. My dad happened to purchase a book, I think it was HTML4 by O'Reilly and I happened to just stumble upon it. I kind of really fell in love with this idea that using just the notepad editor and saving a file with this .html extension. I suddenly had this thing that was like, I could see, I could edit, as opposed to more traditional programming languages at the time, like Java and one of the basic programming languages that you needed a compiler. It took a long time to get feedback. And front end was so compelling at the time. Because it was like, oh, I just write a couple lines of code. I could see my changes.

Ben (01:55):
But at the time I sort of played around with that and then never realized that, oh, this could be a job. This is code language, this is fun, or whatever. So it wouldn't be till many years later that, in combination with my psychology basically, where I was sort of really starting to get into the user experience side of things that I was like, hey, I also really enjoy the tech side of things as well. I'm not necessarily interested in visual design. So I was like, is there a way to bring my love for the front end stuff I used to do along with the UX things? And that was kind of the basis in which I spearheaded my career into tech.

Alex (02:23):
Presumably, if you started studying psychology, you didn't have a sort of end goal of working in tech. What happened along the way that made you want to get more into the coding side of things?

Ben (02:32):
On the psychology side of things, I've always been a really big proponent in the work that I do of making things easier for people, right? Having impact in the world is really a great way of feeling like you're contributing. And so before user experience became thing, I was just basically doing that. If the boss was like, "Hey, create a contact sheet in Excel," it was one thing to do that, but it was another to be like, can we make sure the columns are the right size? Is the font the right? I was just playing around with a lot of those things and can we abstract certain things into macros? I was really thinking along those lines so much that at some point I was like, Hey, maybe I should be a UX designer. This was when it was just starting to become a thing.

Ben (03:04):
Except at the time though, a lot of UX design positions were really heavily emphasized on the visual design side of things. I was like, oh, I'm not really a visual designer. I can play one on TV, but really you don't want me doing your visual design for your project. So it was like, okay, if that's the case, what else can I do? And then that's when it was like, wait, I used to love this front end stuff, like h on CSS, I wonder if I could pair them together.

Ben (03:25):
That's when I managed to hack my career together because there were no boot camps or really educational resources at the time, the way we have it now. And so it was this tricky, like mish mashing what I thought made the most sense in order to break into tech. The real divergence into code though, was that at some point needed to make a choice between being a UX designer or a developer, because again, at the time the careers didn't really allow you to do both at once.

Ben (03:49):
And so, because of my lack of visual design focus, in fact, I discovered this mid-interview. I'm talking about a horror story, I walked into the interview thinking, all right, I'm going to sell them on the fact that I can code and I can do UX design. And the director who was hiring at the time was like, Hey, if you only had to choose one, which would you do? Would you do design or would you do coding? And I kid you not, I froze. I couldn't even, I think I mumbled something. It was embarrassing to say the least. But what I walked away from that, after reflecting on that interview, which had basically gone sour, I decided to really commit. And so that's when I sort of decided to do the coding piece and that's where my coding career really took off.

Alex (04:26):
You found a way to marry your hobby for HTML and CSS with what was an emerging passion for design and things. But ultimately it seems like you are someone who always cared about the experience. Like it wasn't enough just to make a task pass or to satisfy a requirement from your boss. Like you wanted to put yourself in the shoes of the person using that thing and help them fall into the pit of success as we sometimes say, instead of fumbling and getting stuck with it. But then I feel like that's something that user experience designers think more about from developers sometimes. Do you think it's something that matters to developers as well?

Ben (04:58):
Honestly, I would like to think so. It's one thing to build something, but don't we as developers love building things that people use? And so if they're having trouble using it, I feel like that's not nearly as fun. It's like why a lot of us do spend a lot of time learning about tooling and that kind of stuff, because at some point you go, wait, why am I doing this from scratch every single time? I want to create better impact. So I think whether they realize it or not, I think a lot developers do care about user experience. It's just depending on the perspective in which they're taking it.

Alex (05:25):
If I saw a flake for your LinkedIn profile and tried to get a sense for what you've been doing, it does look like you've worked a little bit as an instructor and also as a traditional engineer, and now in Netlify you seem to be working on developer experience type stuff. Just for the benefit of anybody listening, what does developer experience look like to you in Netlify?

Ben (05:43):
So a developer experience, I think, is the job I wanted when I started my career. Because as you probably might have guessed, I like to joke that it's basically like a front end develop or a developer position, because it's not always just front end. Sometimes you're doing backend stuff too. And a user experience design position. And then the developer advocate position all sort of had a baby and then that's kind of what developer experience can be. And I say that can be is key because, you don't necessarily have to be big on content for example, but there's this whole idea that, to your point of, how do we improve the tooling experience so that we can make things easier for people? When you sit at the intersection of being able to code and being able to think about your users, then you have an ability to create impact that sometimes when you exist on those other extremes, you lose a little bit of context, right?

Ben (06:27):
Because you're so deep in the rabbit hole and a specific thing, you might not realize where the intersection lies. Another thing that's interesting too, if you decide to get into the developer experience part of it is that, some of us are actually, a lot of us are also usually very heavily embedded in the community. So when you're talking about talking to users and understanding what they're thinking, that's a big part of it.

Ben (06:44):
When you see the real pain points of people actively talking about difficulties they're having, it gives you better insights to actually give feedback back. Whereas, sometimes even if you're doing user experiences and research, for example, you can get some contrived answers. If you just do a randomly group of participants, who might not have the same experience or the buy-in to actually give you the feedback that you need to actually make the right decisions when iterating on your product.

Alex (07:08):
Maybe we can talk a little bit about developer relations and developer experience as a potential career avenue for new developers in a few minutes. But one thing I wanted to sort of segue into is your involvement with the project, Vue.js. Can you summarize what you're working on, on the team and where you stand right now?

Ben (07:24):
Yeah. So for those who don't know Vue.js is one of the, I think we're now in the big three of JavaScript frameworks for especially, the rendering of things easily. So if you heard about React is kind of spoken up in the same vein. And so basically, I'm on the core team. My role primarily on the team is a lot of community engagement as well as work on the dots to make things easier because one of the things we pride on in Vue.js is trying to make things as approachable for people as humanly possible. So I'm sure we'll dive more into that, but that's kind of my high level role with the Vue community.

Alex (07:53):
It is a fantastic role. It's obviously very impactful and it sounds like a wonderful place to be. Whenever I've learned about somebody in such a position, I'm always very curious. Like how did you end up being in that position and what can new developers learn about contributing to open source and getting more involved from your story?

Ben (08:08):
One of the things that when it comes to open source is, and I think this is important to recognize is that, the tricky part of it is that you need to have the time to contribute to it. Right? And so this is why I think when we hear a lot of blanket advice regarding like, oh, you should just contribute to open source. It's tricky because there's a balance of, well, if you have certain responsibilities that prevent you from that, that can be a gatekeeping kind of thing. And so for me, at least I think one that is less about you issuing pull requests to the code base, that can be very stressful in that kind of stuff. But what you can do is just get involved with the community because believe it or not, I think a large part of open source is just showing up consistently.

Ben (08:42):
So whether it's just being around in the discord, helping to answer questions it's interacting with people because as many of us have experience in the pandemic, having human connection is super, super important. And so learning to cultivate those relationships over online communities can ultimately push you much farther. Because that has a larger implication beyond just merely contributing to open source. Because let's face it, open source libraries have their ebbs and flows and their popularity, but your ability to connect with people and to build communities or to just add that value that has long term impact across many, many aspects of your life.

Alex (09:14):
If you are enjoying this episode of the Scrimba Podcast, can you let me know? Lately I've been inviting you to please tweet or email me with your key takeaways from the episodes. Ask around, I will thank you personally for tuning in, as it really does mean a lot and gives me an idea about what you like about the podcast, therefore, what to do more of.

Alex (09:35):
Next week, I'm speaking with Staffy Rosco, who is a newly hired developer with the most amazing success story. Her job application landed on deaf ears basically, she got no response. So she followed up. And again, and if I remember right, she followed up one more time. If you can believe it, her application got lost or disregarded, even though she was obviously a perfect candidate, as they've now hired her.

Staffy (10:01):
Sometimes I think people think you just apply and that's it. And if you don't get a result or you get a rejection that, that's the end of it. And sometimes it's not, or at least I believe it's not.

Alex (10:12):
This is one of the most famous websites in Barcelona by the way. And it just goes to show how without persistence, Staffy might not have found the success she obviously deserved. That is next week on the Scrimba Podcast. Make sure you subscribe so you don't miss it. Back to the interviewing with Ben. One question I have for you, Ben, and I think it's something new developers might be thinking is, especially with a project like Vue.

Alex (10:38):
It seems really hard to contribute to for a variety of reasons, especially when you are a new developer, since you might not have the most concrete skills and generally the bigger the project without anybody to hold your hand or show you. Because in companies you get onboarding when you join a big project. In open source that doesn't always exist, no matter how good the docs and the intention is. I'm just wondering, what's your advice and philosophy about new beginners contributing to these kind of any project, but also bigger projects like Vue?

Ben (11:03):
I think, especially when you're contributing to big projects like open source, the key thing to remember here is that it's not about issuing the next PR that becomes the new feature for a given library. In fact, the easiest place to often start is to simply, one find a project that you actually care about. Even within the Vue community, that's a fairly big thing. Just because you care about Vue doesn't mean you necessarily contribute to the core library. For example, I don't necessarily contribute code to the core library.

Ben (11:27):
But what I do is that like in the discussions for the API, I might see how things are, I might give feedback on where I think this might make sense or maybe places where it might not make sense. And so as a result, if you're new, a lot of times, once you find that project that you're interested in, like helping to read the issues to see what kind of problems people are having and then learning over time, as you contribute to those discussions and learn from what people are talking about, that's how you end up gaining mastery.

Ben (11:50):
And so I would say specifically in the Vue community, a great way to do this is, as you're reading the docs, for example, because the docs is the key where a lot of people go to, to reference things. You can help to improve explanations as you learn things. You might be like, oh I'm reading this section to learn about this about Vue, but this doesn't make a lot of sense. So then file an issue, right? Ask questions because this is where we can help engage then, which honestly that helps you gain your expertise. And so then you get this mutually beneficial thing where over time you become able to answer those things or be able to actually add value. Because you're like, oh, well actually I wonder if it would make more sense to be explained this way. This way, you're kind of solidifying your own learning process while still contributing to the larger community as a whole.

Alex (12:28):
And it's easy to underestimate the impact you can have as a junior.

Ben (12:32):
Yo, absolutely.

Alex (12:33):
Sometimes you might feel a bit insecure, like you're new or something like that. And you haven't got the most to offer, but to your point Ben, a maintainer can't put themselves in your shoes unless you help them and talk about where the roadblocks were. So by sort of stimulating that conversation, you might spark new ideas and help the maintainers or that kind of stuff. And you're saying that documentation is another good place you can start to contribute.

Ben (12:55):
Yeah, it is in particular because, I know a lot of people, they're like, oh I don't just want to fix a typo. That's like certainly way you could like, if you want to add your name to the contributor list, that's certainly a great way to do it. But in terms of like actually growing and that kind of thing, your questions are incredibly valuable to the community. When you show that you've taken the initiative to go, I've read the concept of slots in Vue. I don't understand this part. Asking those kind of questions are important because it gives us feedback as the docs team to go, what about this isn't working?

Ben (13:24):
Because our goal is, again, I can only speak for the Vue community, is to reduce the barrier of entry so that you don't need a video course to get started. You could literally read the docs. Some people learn well with video courses, there's nothing wrong with that. We want to at least provide a free entry point for everyone who just wants to read it and who can understand it. So the better we can do that, the happier we are. So your questions and being confused that helps us. It's not something to be insecure about is what I would say.

Alex (13:46):
Do you have some memory of your first open source contributions or your first contributions to Vue?

Ben (13:52):
I can't remember exactly what I can choose. I think my first peer was to the docs. And the thing is, is that when you're contributing pull requests, I think one of the classic mistakes I've seen with people who are new to it is that they usually make a big PR. They see this page, they're like, oh, I can improve it. And they spend hours or weeks rewriting the whole thing and then they submit it. Maintainers, especially on UGS, most of us are doing this as volunteer work. This is not our job. And so when you get something massive as this, it takes a lot of time for us to review things.

Ben (14:18):
It's not as simple as, oh, you just submitted a typo chain to prove kind of move on. All the time there needs to be like, there's a lot of contextual things that you might not be aware of when we made certain decisions. And so what I tend to recommend for people near to open source is that, rather than just submit a change immediately, filing an issue and having those discussions to say, Hey, I'm willing to take this on, here are what my thoughts are. This allows us to gain trust in the contributors. Because I can tell you, it might sound silly, but the hardest thing at open source is people who have good intentions, but then ultimately don't follow through.

Ben (14:48):
That's hard as maintainers because this means that you're like, oh, I'm going to do this thing. And then we wait for like a week, two weeks. And don't forget, we've realized this is free work. So we're not trying to put deadlines on anyone, but then at the same time then it's like, so if I go and do it, am I taking away someone's opportunity to contribute to it. And so this is why I was saying maintaining a consistent presence and gaining trust from your maintainers is honestly most of the battle. I remember submitting my first PR and I remember it took two or three weeks before I finally got approved.

Ben (15:15):
It was nerve wracking because I, as a first time contributor didn't know what was going on. I was like, do they hate it? Are they afraid to like, what's going on? The imposter thing just to kind of goes through, but the reality is that, maintainers got a lot going on. And so if I had filed an issue and talked about it, I think that gives a lower barrier for the maintainers to interact with you. And then to your point, Alex, as far as like my involvement, eventually what I did was I just kept showing up and more importantly, I went to the conference.

Ben (15:40):
I went to the first Vue conf in the United States. And that's where I actually had the opportunity to meet a lot of the different teams, that gave a lightning talk at that and then got to talk to the team members and figure out where they needed help. And so being proactive in finding ways to add value rather than just being like, Hey, I want to be on the team. How can I be on the team? My entry point was that I realized I didn't have a good way to help build community, especially with meetup events. And so since I'd organized my own, I was like, I'm happy to spearhead an initiative to show how this works and to talk to you all about it. And that's kind of my entry point to working with the team which certainly evolved since then, but yeah.

Alex (16:13):
There's a lot of follow up questions I could ask and I do want to move on to a slightly different subject. But before I do, I want to ask you quite a hard question if that's okay?

Ben (16:21):
Please.

Alex (16:21):
Why do you want to go to all this effort to speak at the conference, give a lightning tour, get involved. What's your motivation?

Ben (16:28):
One of the things I've always loved about being a part of the web community is that, this is a place of sharing and I'll use the cliche sharing and caring. Because one of the beautiful things about the web is that our code, you can view the source. You can see the HTML, you can see the CSS, granted minified, JavaScript a little harder to decipher, but there is this sense of not having this proprietary way of doing things. I know that part of my success in the community is because of other resources other people created.

Ben (16:53):
And I remember going to conferences earlier in my career where I was really inspired by the people talking on stage. And I wanted to also give back in that way as well. The other thing too, that I think that's a big part of this, which I think we'll talk about as far as your career as a developer. Because I know while there are a lot of resources in boot camps and stuff nowadays in the tech industry, one of the hardest things I think a lot of junior people can empathize with is it feels like it's really hard to stand out.

Ben (17:16):
Because everyone seems like they have the same keyword and buzzwords in their resume. And everyone's building the same six to do NBC apps. So how the heck do you stand out? If we want to talk about being unique? I think oftentimes while we have a lot of imposter syndrome early on in our career, the key thing to remember is that you as an individual have so many unique perspectives that you just don't don't realize yet. What I try to tell people is that, the biggest return on investment you can put as far as your time on things is you as an individual.

Ben (17:41):
So when people talk about branding and speaking and stuff, yes, it is tricky to handle the public speaking, like fear and that kind of stuff. But if you're talking about standing out from the rest of the crowd, a lot of times that requires you to do things that are frankly different than everyone else. And if something's difficult to do, oftentimes not that many people are doing it. And so things like public speaking, things about writing about your experience, being vulnerable, things that like engaging with the community, that's the stuff most people think, ah, I'm not going to spend the time to do that. But if you spend the time to do that, you suddenly stand out in a way that's completely different than everyone else because you're the one that took the time to invest in yourself.

Ben (18:17):
And the great thing about this is that, this is something you can take with you. No one can take that away from you. Like when you invest in your own brand and that kind of thing, you get your own blog, you get your own livestream, you get your own speaking stuff, no company can ever take that away from you. That's was also part of my motivation too, was like, I needed to find a way to stand out from every other person that did the same thing that I did.

Alex (18:36):
Does it sound like passion to you? I'm passionate about code. I'm passionate about my career. It happens to be what I enjoy to do a lot in my life. And for that reason I've never found it to be so inconceivable, but to stand out, I should give talks and build my own blog and things like that. It's always made a lot of sense to me, but not everybody's like me and maybe not like you and they might not even be that passionate about code. But that wouldn't change their ability to be a highly disciplined and efficient professional. I just wonder how somebody in that position might think about conference speaking and blogging and stuff like that. Do they just purely use it as a tool for standing out in that case? Or do you think there's another way of looking at it?

Ben (19:11):
It's funny you mentioned the passion piece because I think to me, it's actually the other thing that you mentioned, which is about discipline. Where, if you're just sharing your learnings, because let's be honest, when you're learning something you're probably taking notes to some degree. And so if you learned in public, even if you never public speak, that is still very different than people who don't do that. You're simply just that extra step to have your blog to say, oh today I learned about D3 and how to render groups or whatever. Like this is my snippet. And over time I think what people don't realize is that, when that muscle becomes easier to access, you end up doing a slightly bigger thing.

Ben (19:43):
When you see the impact too. I think there's a bit of encouragement there from like a connection aspect as well. Because when you see people engaging with that being like, Hey, by the way, your post that you wrote that you thought no one would ever need is getting 10, 20,000 hits and people are like, you saved me three hours of debugging. You start realizing, oh this has profound impact. Just like why I think a lot of us get into tech is because our impact scales in a way that would never have been possible without technology. And so I'm not necessarily saying you need to public speak or whatever.

Ben (20:09):
I'm just saying that when you think about things to do you to stand out and to push yourself forward, that's the thing that's always been exciting about for me is personal growth and development. And helping people find ways to create impact. When you want to create impact a lot of times the thing that helps is doing the thing that's against the grain of what everyone else is doing.

Ben (20:26):
Because by the time you've sort of jumped on the bandwagon, you are fighting the noise, you're fighting against the people paying for ads and all that fun stuff. But if you're just doing you, I can't stress enough. You have a ton of unique perspectives and skills that you don't even realize. For example, myself, I did coding, but I also was big into psychology, philosophy. I have my anime background, nerding out about go, the board game and all these different pieces. I've come to find if you start to connect those dots, you end up having a unique perspective on things that other people just won't and people find that very helpful.

Alex (20:56):
It does depend what kind of jobs and what kind of career you're trying to build as well. I think so much of this nuance gets lost in Twitter and social media and things. And it impacts a lot of beginners because they see these little nuggets of advice or they see this little nugget of success without understanding all the context and all the other details. But the point ultimately being that you are your own person and you have to find what works for you. And there's absolutely no rights or wrong way, just your way. Shall we talk a little bit about Vue.js in the context of the French and ecosystem and specifically for beginners.

Ben (21:27):
One of the biggest differentiators with Vue is that it is open source at its core. In other words, there's no company that's driving Vue's roadmap, and what's going on. It's built by the community for the community. And for some people, this could be really important because what this means is that, basically, you don't have to worry about any moral implications of using a specific tooling. And then as a result though, because we're not bound by a company roadmap, this means we can really spend the time to look at what other frameworks are doing and learn and adapt what's best for them. One of the reasons I fell in love with Vue. And so I have experience with basically most of the frameworks that people are using these days, is because it is designed to give you what you need and then get out of your way.

Ben (22:07):
So in other words, rather than having you learn a lot upfront, it lets you leverage what you already know. So in the sense that you've learned HTML, you've learned CSS and you know just a little bit of JavaScript that is enough for you to do a ton with Vue.js without having to worry about the barrier of entry of like, oh, I don't know, all of JavaScript. And so as a result, contributing to a Vue code base can become a lot simpler. The proverbial example, I always like to use when it comes to talking about this is, I was teaching a introductory Vue workshop and there was a designer that signed up and was kind of actually nervous and almost didn't join because she was like, I haven't done coding in so long and I don't even really understand this JavaScript stuff. It just have really basic syntax understanding.

Ben (22:46):
And I was like, it's fine, just come and just let's see what we can do. And within an hour or so I had her up and running and being productive with a Vue code and she was making things, dynamic, Reactive properties. It's that kind of thing that makes me really excited about Vue is because, we keep trying to look at industry standards and figure out like, okay, these things are really good. How can we make it easier for people to get involved? And then at the same time though, we don't want to be so opinionated and dogmatic that people feel like they have to do it our way. Instead they can pick and choose what works best for them, and then as a result, they can build the kind of app that they want without having the dogmatic opinion of, you must do it this way. If you don't do it the Vue way you're doing it the wrong way. Right? That is one of the most anti-Vue things that we have.

Alex (23:27):
If someone is learning React right now and there's a very good chance you just got them very excited about Vue. Because, I feel a little bit excited about Vue. I'm just wondering if they made the wrong decision.

Ben (23:37):
You did not make the wrong decision. The fact that we're learning concepts and I think this is what's the key thing here. The technology we choose as we grow in our careers helps us to learn concepts and then we evolve those ideas. A lot of times I think developers have run into, I've had experience with who've done React primarily, often don't have other framework experience. This can be troublesome because sometimes you lose sight of what other people are doing. And as a result, your ideas are kind of more isolated in that regard.

Ben (24:04):
One of the things I love seeing is the [inaudible 00:24:06] learning from one another. And so especially with [inaudible 00:24:09] entering the ecosystem now. People are like, oh, like maybe things could be done this way. If you've worked with React for a while, especially with Vue 3 and the new composition API, hit me up, I live stream every week. We can tweet, I can show you all like, I think there's a lot of things that could be brought over to the React ecosystem that Vue does that would make developers lives a lot easier.

Alex (24:26):
Does it make sense to learn React and Vue in that case?

Ben (24:30):
This is a tricky one. I would say in terms of efficiency, I know that a lot of arguments made for React are often times like, oh, there are more jobs. Especially in the United States, because a lot of companies saw Facebook was using it. So they're like, oh therefore React can scale. Therefore I use React. But I think especially with Vue 3 and a lot of people who have started to take the time to learn how it works, there is a growing market in the Vue community. What I recommend is if you're learning your very first framework and let's say you've learned HTML, you've learned CSS and you know just a little bit of JavaScript. I actually think take Vue for a stroll. Honestly like with the docs you can get up and running within, I would say give it half a day or a day, that's it.

Ben (25:08):
I'm not asking for much. And what you'll find is you'll probably learn a lot about how Vue thinks about things. And then you can suddenly do your React journey for ensuring that when jobs ask, if you have React experience, you have that. But then at the same time, I do think that, what I've found is a lot of people are using maybe React in their day to day, but they've started using other framers in their side projects because there's wanting to experiment with more ideas and techniques.

Ben (25:29):
What I'm trying to say here is that it's good to specialize in a tool so that you can certainly have the on job experience. But from a learning progression piece, I do think there's a lot of value in checking out Vue because again, Vue and React have been very complimentary to each other over the years, as I've learned. It's particularly Vue and just sort of taking in different things. So do what's interesting to you. I think that's the key thing. If you can keep that flame going, that torch going that's what's key actually. And so if you decide to use that for you, that's okay too. That's why we have different frameworks.

Alex (25:57):
I couldn't help but notice that you have a fair bit of experience teaching as well because you did some stuff with companies, we all recognize the Udacity and Treehouse. You've been a and still are I think an amazing conference speaker. You are an instructor and you do some awesome work of Vue mastery. I want to link things like Vue mastery and computer properties and your Twitch streaming things and the show notes too. So let me just say now for anybody looking for those, they can find them in the episode description. But sort of drawing on those experiences. I wanted to ask you what is some advice you can share for anyone learning to code and maybe struggling make things stick or feel confident in their abilities in general?

Ben (26:32):
As far as making things sticky in terms of the things you're learning, the key thing, or actually this is just more of an education principle, is that finding a problem that you can engage on directly. So whether it's your cousin has a website they've been meaning to build or whatever, like having a problem that has tangible meaning for you outside of arbitrarily learning a concept, can make all the world of difference between contextually, why something is done a certain way or basically it gives that value. The more you can attach that, or just ask your friends and family, does anyone want a website? I'll build it for you. And then that way, one you have this engagement and you end up building this accountability. Now you're building it for someone. You have some buy-in. I would say, having a problem to engage on that's what makes it sticky.

Ben (27:12):
Otherwise, I would tell you as someone who has bought a lot of different books and courses with the aspiration of learning something, and I've watched a lot of stuff, if you don't use it, you're definitely going to lose it. So that's the piece on that. Confidence in the ability. I think the key misconception with career growth is that, they keep using the ladder analogy. Like you're climbing the rungs. If you see yourself more as an ecosystem that grows over time, you're acquiring new things that are new skills and problems you've learned to solve.

Ben (27:38):
That is way more important than having these, not even just specific job titles, because one thing you'll learn as junior engineer is that in our industry, there is a lot of inflation in terms of tech job titles. Where some companies will promote people really fast, but then you'll have a senior title at like year two. And then all of a sudden you're interviewing for other senior positions that have different experiences. So for me, letting go of those attachments to those qualifications of titles, and rather, like I said, investing in your own ecosystem and who you are, that will always shine through in the long run rather than the sort of short term game of, let me just keep grabbing titles. Because at some point you might find yourself a little bit in over your head and finding a hard way back from that.

Alex (28:16):
Tech is such a bizarre industry where you have so many freedoms, but then we get to make up our own job titles as well. What is an intern at one company could be a junior at another. What is a junior developer at one could be a regular software engineer at another. Some people become senior engineers after two years. I've always found that strange. I never understood that because if we are intending to grow and continue to write code for our whole career, which could be 30, 40 plus years, it seems bizarre to me that after two or three years, you're at the point of seniority. But yet, we learned the language of our industry, that's important to remember. That if you don't learn the language, you could be very overwhelmed and upset because it makes no sense, logically thinking.

Ben (28:54):
Yeah. Learning to set your own compass and not letting others set it for you will be very key to not burning out in this industry. Because if you keep comparing your title and your salaries to people, I found that most people just end up becoming perpetually unhappy, because there's always going to be someone who ended up, and who are privileged in some way that got some odd, really crazy negotiated deal. And that doesn't make you less as an individual.

Ben (29:15):
Whereas if you can align your compass to your values, what you want out of life and finding a community that can support you to helping to build that, I think that is the key ultimately to longterm success. Which is what I hope those looking to join the tech community. That's what you're looking for. You're not looking to just get a quick payout in five years and then burn out and go on a farm for the rest of your life. Basically, I want you all to be happy and not burnt out because it's not a fun experience.

Alex (29:39):
Ben, thank you so much. How about to finish things off strong, we do some quick fire questions?

Ben (29:43):
Yes. Keep at it.

Alex (29:46):
Okay. Since March 2019, you've barely missed a commit on GitHub. How does that feel?

Ben (29:52):
Well, and that's the funny thing about metrics. So part of those commits, yes, those are code. Some of them are also just like I'm a big note taker. So if you're into productivity things, obsidian, I'm a huge fan. And I talk a lot about that on my streams during the week. So yeah, one of those things is just like my notes being committed to my repo so I have a backup. So just know that is where GitHub metrics get a little bit funky because it's not true commits.

Alex (30:15):
Oh that's so cheeky. If I connected notions to GitHub, I would be a solid green blocker, I think.

Ben (30:21):
There you go. See, that's what I'm saying. Right.

Alex (30:24):
Oh man. All right. Next question. You've worked both as an instructor and as a developer and various things in between, if you had to say, which do you like more teaching or coding?

Ben (30:34):
Oh, this is so hard. Okay. I think I would probably have to say teaching and only by a really slight margin above. There's something really nice about engaging with people and seeing that light bulb happen. As developers when I build things, I don't usually get to see the users use it and that kind of thing. Whereas teaching has this sort of tangible aspect of interacting. And I've met so many wonderful people through teaching or even just taking workshops that I think that just pushes it very slightly ahead, but don't get me wrong. I actually love building things though.

Alex (31:05):
So you have a degree in psychology. Does it help you in your work at all today?

Ben (31:09):
Yes. It does. But you know, it's funny. People always think about studying psychology, like you've learned how to like manipulate people and all. It's really not that. In fact, for anyone who with an undergrad psych degree, most of it's just learning concepts and it's really just spending the better time, to learn about communication and how to be empathetic with people. And so that skill actually has nothing to do with taking a degree in psychology. That's just something I happened to be interested in. So I took a degree to learn what the terms were for different things, like bystander effect or to learn about different like group think and that kind of thing. But in the end, if you invest in learning how to communicate with others and to understand other points of Vue, there's a great t-shirt that was at a conference one time.

Ben (31:44):
Where it was like, coding problems aren't hard, it's people problems that are hard. And I think anyone in the industry can tell you that one of the most difficult things when you're working in this industry is actually convincing people that either your solution is the right way or maybe not right, but maybe like how to go along with what you want to do or more importantly, how to resolve those blocks. And a lot of times the things you aren't technological things, but people things. Because if they're not convinced or whatnot.

Ben (32:07):
And so the more you can do those sort of things and invest in that kind of skill. The more you'll see that again, it pays off in many, many different ways from being able to talk with people, but then also just grow your career as well. Because if you can better understand people's problems and they feel like they can talk to you, you'll find that at your job, you'll become the people, people want to go to, to ask for questions. Even though maybe the person next to you is the expert on it, they'll want to talk to you first, because you're just easier to approach. And frankly, I would say the ability to easily work well with people that will carry you very, very far in life.

Alex (32:35):
What is one thing you wish the Vue ecosystem or community had for another community or framework like React for example, does have?

Ben (32:43):
This is a tricky one because to be honest, this entire time that Vue has been inexistent, it's been learning from the frameworks. So for example, React hooks, for example, I think the composition API was inspired a lot by that. React is certainly very, very popular. And so I would love to see more diversity within the Vue community for different libraries and that kind of thing in that. So Vue, we do have official libraries for routing and that kind of stuff. So if you're not interested in trying to figure out which third party library makes the most sense, you could always go with the officially Vue recommended one. But then at the same time, I'd love to see more third party ideas as people start to experiment and do things. I think that would be great. And that's one thing I think the React community does do really well, is there's a lot of experimentation going on within the [inaudible 00:33:19].

Alex (33:19):
Last question because I want to link your Twitch stream and all your resources for anybody who wants to keep learning from you and so on. But just to give people a specific idea about what they can look forward to from you. What is one of your favorite talks or presentations that you've given in the last little while we can link to, to close out the episode?

Ben (33:36):
Oh, if I had one talk that I would recommend developers to check out is actually there's a getting started with note taking and particularly obsidian, because I think obsidian has a really nice intersection with developers as far as like having a bunch of markdown files that then allows you to do link thinking. So that'd be my pick, I think, for this one now.

Alex (33:54):
Ben Hong, thank you so much for joining us today on the Scrimba Podcast.

Ben (33:57):
Yeah. Thanks so much for having me

Alex (33:58):
That was Ben Hong, developer experience engineer at Netlify and a Vue.js core team member. Thank you for listening. By the way, if you made it this far, you might want to subscribe for more helpful and uplifting episodes with recently high juniors and industry experts like Ben. You can also tweet me your host, Alex Booker. My link is in the show notes. And you can share what lessons you learned from the episode, so I can thank you personally for tuning in. Seriously, try me. And until then I will see you next week.