Enjoy the Mew: Healing Community Paper Cuts with Jason Etcovitch

[INTRO]

[00:00:09] T: Hey, everybody, and welcome to Enjoy the Vue. I'm Tessa. Today on our panel, we have Alex.

[00:00:16] AR: Hello.

[00:00:17] T: Ari.

[00:00:18] AC: Hello.

[00:00:19] T: And our special guest for this episode is Jason Etcovitch, and maybe his cat Mookie. Hi, Jason.

[00:00:26] JE: Hello. I'm not going to pretend to meow, because I'm pretty sure she's going to do that soon anyway.

[00:00:31] T: Nice. Who are you?

[00:00:34] JE: That's a really good question. I'm Jason. I work at GitHub, on the Special Projects Team. I’m probably known best from doing paper cuts type issues all across the product. It was little things that you thought, “This sucks. I hate the way this works. It's probably really easy to just have this little feature. Make my life a whole lot easier.” That's a lot of what we do. I also hang around a lot in the Node.js ecosystem. Done a whole bunch of work all across the JavaScripts and stuff. Oh, and I'm in Toronto, Canada, where it's a beautiful, sunny day that I'm inside.

[00:01:09] T: Wow. Okay, so question, somebody told me a long time ago that people from Toronto, say Toronto, but then everybody I meet from Toronto doesn't say Toronto. What is that? Is it Toronto or Toronto?

[00:01:23] JE: I'm actually from Montreal, and I moved here seven years ago.

[00:01:27] T: Traitor.

[00:01:28] JE: I don't think there's a correct way to say Toronto. What I do see is people with t-shirts that have TRAWNA, like Trawna on it, which is really funny. I don't think there's a right way, but there are a lot of wrong ways.

[00:01:43] AR: It's like saying Atlanta. You don't pronounce the second T. Atlanta.

[00:01:50] T: I hear that you also went to art school?

[00:01:53] JE: I did. Yeah. I studied graphic design at OCAD University, which is here in Toronto. I studied there for three years. Then actually, in the last three months of my university career, I was working full-time for GitHub, and that was a really dumb. It's a ton of fun, though.

[00:02:12] T: Wait. Working for GitHub, or staying at university, or something else?

[00:02:16] JE: Both.

[00:02:19] T: I mean, you still do that now.

[00:02:23] JE: I'm not a full-time university student anymore, thankfully.

[00:02:26] T: Yeah. How did you get into GitHub, if you're doing graphic design? I assume you weren't doing graphic design for GitHub?

[00:02:32] JE: I studied graphic design for a total of six years. Three of which were in Montreal, where it's this post-high school pre-university system. I studied graphic design a bunch there. Then at a certain point, I was doing freelance work, and I wanted to have a website to show people all of my freelance work. I figured out HTML and CSS, and then kept going from there.

Then at one point, I started doing a mixture of design and development work at startups here in Toronto, part-time jobs, summer jobs, freelance stuff. Then, I got an internship at GitHub, where I was – I think my job title was training designer, or designer for training. It was for some training material. That just evolved. Eventually, there was like, we want to make this straightforward HTML website. I said, “Oh, yeah. I'll do that.” Then it just kept going.

[00:03:29] T: That's cool. To be fair, I mean, you were three months away from your university, so I get why you keep saying that.

[00:03:37] JE: Exactly. Everybody was going to celebrate. It was going to be awesome.

[00:03:40] T: I feel like, you're one of the more knowledgeable people I know in tech. How did you make a transition from doing graphic design, to working full-time as a developer at GitHub? That seems like a really big, intimidating change.

[00:03:53] JE: It never felt intimidating, because it never got to this zero-to-one point. I was never designer one day, engineer the next day. It was more like, I was doing some design work, I had to do a little bit of coding work. The graph just shifted in one direction over time. It especially changed when, as I was an intern, some of my other intern friends and their co-workers, they were starting up this project called pro-bot, which is a framework for building GitHub integrations. Open source project started by a lot of GitHub employees.

I said, I want to help. I know enough to be helpful, I think. Then, that took on a whole life of its own. My internship ended. Kept working on robot. Then eventually, I came back to GitHub as a contractor, basically using pro bot to build this thing within GitHub. It just flowed in this really opportune way.

[00:04:53] T: Sounds like, quite the career development.

[00:04:56] JE: Yeah. It was a lot of right place, right time.

[00:04:59] T: I'd like to hear more about the paper cuts, because I feel like, it's that meme of when you apply to a job, and then you make one PR for that thing that's bugging you, and then you put in your notice, is it a lot of those kinds of things?

[00:05:13] JE: It is exactly that. You see a button that you wish was on the left, instead of the right side. A 100% of people feel that way, but for whatever reason, it just hasn't been changed. Our team is the one to go and change that thing. It extends to features really, really small to slightly medium sized. A couple weeks ago, somebody on our team shipped support for surfacing citations in repository. You look at a repository, they have a citation file, a license file. Now in the GitHub UI, we pull that out, display it properly, make it really easy for people to cite a repository, essays, or documents or whatever. That stuff, it's like, who's going to do it? Other product teams have priorities around larger features, or performance stuff, or things that they absolutely have to own as part of the repositories team. Also, we know that these things should get done, so who's going to do them? Special Projects.

[00:06:23] T: Yeah, citing books is so annoying. I never even thought about having to cite a repo, like these lines, this file. Oh, my gosh.

[00:06:32] JE: Yeah. There's a lot of things like that, where our team is very, community focused. We'll look through all kinds of different feedback forums, like Twitter, obviously, but a couple of different repositories on GitHub, like feedback. We have a feedback discussion. We will legitimately say like, “Oh, look. This person's asked for this feature. Could we do it?” Then we do a bunch of research and try to figure out if it's actually going to be really useful for a lot of people. Most of the time, it is. We just go out and do it.

[00:07:02] AC: If we wanted new features, where should we go and complain loudest?

[00:07:09] T: @gloomylumi.

[00:07:11] JE: Honestly, I probably shouldn't say this, but I will anyway. I think, Twitter is probably a really good place. Nat Friedman, if you @ mention him on Twitter, most of the time, he will respond, especially if it's a well-thought out idea. A lot of the time, my team's product managers will look through those Twitter requests. There is also, I think, github.com/github/feedback. There's a discussions thing in that repo, where you can just propose ideas, propose bugs or anything like that.

[00:07:45] T: Nice. It sounds very much like Slack. I hear, they also troll Twitter to look for new ideas.

[00:07:52] JE: Yeah. Well, I mean, that's where people are complaining. If people are complaining, it means that there's something we should fix, or improve.

[00:07:59] T: Yeah. I'm curious to hear more about this research and how much you're involved in it, because I don't know if this is the case for Alex and Ari. I feel a lot of times, from what I've seen, and what I've heard about basically, the PM will be like, “Hey, we should do this feature, because I think it's good, or because our customers said they wanted this exact feature the way that I'm proposing it, and then we just go ahead and build it.”

[00:08:17] JE: Yeah. That's a really good question. Our team works in these really tight iteration loops. We won't take on a project that will extend past two-ish weeks. It's more of a guideline than a rule. If a feature request, or a bug fix, or something like that is going to take more than two weeks, we just won't do it. There are other teams that should be responsible for those larger, more complicated pieces of work. A lot of our research from the engineering side is just trying to understand the feasibility of it. Because we operate across the product, no individual engineer can be an expert in every part of the product.

There's a lot of understanding, talking to people, talking to the teams that actually do own that part of the product to try to understand, is this a thing that we could do? Have you tried to do this in the past? Sometimes if we choose not to move forward with it, all of that research is really valuable. That's the thing that we can deliver to the owning team, so that if they do want to take it on, like we just did a week's worth of research work for you.

[00:09:29] T: Nice. Yeah. Do you feel your design background comes in handy for the research and iteration phase?

[00:09:35] JE: Not so much on this team, because we've been working with some really, really great designers on this team, that just do the best work I've ever seen. It's really awesome. On other teams that I've worked on at GitHub, I've had to do a little bit of actual visual graphic design work. Then, there's also the question of how do things work? We approach these very vague, sometimes prompts. Part of learning that design mindset is understanding like, how does a person approach this thing? What are the various touch points that they have to consider?

As we're doing that research, we're trying to understand all of the systems that a particular product feature touches, right? We're talking about issues. Sure, okay, we want to add – actually, there's a perfect example. Somebody on our team added support for rendering code in issue titles. If you do backtick, a markdown code fence thing, in an issue title, how does that get rendered? Well, it's pretty straightforward, except that where our issue titles render across all of GitHub? How does it influence the API? All of these things, you have to see that holistic view of, and I think, design school was very helpful for me for that.

[00:10:58] T: Yeah. Alex, also is really into design.

[00:11:01] AR: Yes, graphic design is my passion. I may have just taken your suggestion and tweeted @NatFriedman, to see if we can get an option, so that we can have GitHub in Comic Sans. We'll see. I'll keep everybody posted, if that goes anywhere.

[00:11:17] AC: Well, Alex, it was really nice having you on the show. Bye.

[00:11:24] T: Yeah, I have to admit, aside from Vue being larger than 6 kilobytes, GitHub not being in Comic Sans is really stressing me out and keeping me awake every night. I wanted to go back to something you said earlier about community and citations. Are you able to weigh in on that new machine learning feature that GitHub has been rolling out for the last couple of months?

[00:11:51] JE: Yeah. GitHub co-pilot. I can only give you a non-representative view. I didn't work on co-pilot, so I can only tell you about it as a consumer of it. It's very cool. I think it's a really, really nice experience as you're writing code to just have somebody suggest things to you. As far as the licensing stuff, I can't say anything about it, because I don't know anything about it. That's about as much as I can say.

[00:12:20] T: I haven't tried it, so it's more than I can say.

[00:12:23] JE: It's very cool. I will say that. I was using it for a long time, especially as I was starting to use libraries in Ruby that I hadn't used before. It saves you quite a lot of time going back and forth from the docs. Docs are still super important, obviously. It helps you answer the question that you didn't know to ask yet. What is this API called? Just suggests it for you.

[00:12:47] AR: Yeah. I can see it as being a really good starting point, leverage thing and not like this one, now write your entire application for you, sort of a thing.

[00:12:57] JE: Exactly. It's not going to write some with application. It's not going to replace a human being writing code. It's the Gmail autocomplete of your coding experience.

[00:13:07] T: Or the LinkedIn autocomplete.

[00:13:10] AC: We don't use the L word here.

[00:13:14] T: Bringing up projects that don't last longer than two weeks, sounds like it must be really exciting. I'm jealous.

[00:13:21] JE: It is very fun. It's also like, it is the most humbling experience, because as soon as you get to be not an expert, but as soon as you become knowledgeable in one area of the product, boom, you're shifted over to some totally different area. You have to spend a week reading through code, just to understand what's going on again. In that respect, it's super fun, because you get to learn all the time.

We do also take on larger projects, which we call explorations. Those are really big bets around what could GitHub do that would really change how GitHub works, or a whole new product, or that level of exploration. We don't try to always see it through the end. A lot of the time, we'll just spend a couple of weeks building something, getting it to relatively functional, maybe a bit past MVP, and something that you could see yourself using, and then sometimes it will just shut it down. That's usually around six weeks to eight weeks thing.

[00:14:27] T: Yeah. I always feel like, when you start a new job, that first few weeks, or a few months that you have to get used to a new codebase is super stressful. How do you handle looking at new code all the time? Because you're saying it's exciting. I'm like, “Is it?”

[00:14:41] JE: Yeah, that's a really good question. It's hard sometimes. It truly, truly is. The best way that I approach it is to just know that I'm going to feel really dumb for a bit. I'm just going to not know what I'm talking about. I have to be open to asking questions, where it doesn't sound like I know what I'm talking about, because I don't.

In our company, people are generally really open to helping. If I pop into somebody's Slack channel and say, “Hey, I'm doing this thing, please help me.” They'll at least point me in the right direction. Then, it really is just a lot of focus time. My team doesn't have a lot of meetings, partially because we need a lot of time sitting down, reading through code, taking notes, understanding what we're looking at. That's hard to do if your day is broken up by 30-minute meetings.

[00:15:33] AR: That'd be nice to not have very – a lot of meetings during the day.

[00:15:39] JE: Yeah. It's definitely one of the bigger perks of my team.

[00:15:45] T: Speaking of everyone being open, I heard that you are very excited about a new open graph image generator. Can you tell us more about that?

[00:15:56] JE: Only because of that incredible segue.

[00:15:59] T: Thank you. Someone appreciates me.

[00:16:02] AR: Tessa is the best at segues. I just want to say that right now.

[00:16:07] JE: I can tell. That was incredible. Yeah. One of the explorations that my team did was around an open graph, image generator. Open graph images, those are when you share a URL to something on social media, like Twitter, whatever. Twitter, or that social media platform will scrape that website, that link that you posted, and collect a bunch of information about it, including an image.

Oftentimes, you'll see on Twitter, a URL is shared. You'll see this really nice preview image and a description of that website. we took on a project to make an image generator for github.com URLs. think a repository or an issue, you share a URL to that on social media platform. we generate this really nice preview image that shows the language breakdown of that repository, how many stars and forks and that stuff it has, As you're scrolling through Twitter feed, or your LinkedIn feed, or whatever, you get all of that contextual information without having to drill deeper into the link itself. Just makes for a nicer browsing experience.

[00:17:25] T: Yah. Nove not having that doom scroll interrupted.

[00:17:31] JE: In our initial issues and stuff about it, the primary goal was to replace people's giant faces in Twitter feeds, because nobody wants to see my giant face in a Twitter feed.

[00:17:42] T: I mean, now that they decreased image cropping, that could be pretty fun, right? Just scroll for all the way down. Is this the thing that I was asking you about with the cards, where you see people's photos now, is like, how would you deal with what if somebody doesn't want their photo?

[00:17:58] JE: Yeah, that's the one. Our thinking with that is that we're already sharing all of that information. Just changing the template of it didn't feel a legitimate change.

[00:18:08] T: Yeah. Not an increase in you filling information. That makes sense. What inspired the team to work on that project?

[00:18:17] JE: I think, our CEO, Nat Friedman, actually just said, “Hey, this is a weird experience. Can we do something?” Our team said, “Well, yeah. Sure, we can.” Let's try it out, and we did. We built this little node server that collects some stuff from the GitHub graph QL API, and then puts it into an HTML template, renders that in puppeteer, which is a programmatic Chrome browser. It’s called the headless browser, so there's no actual UI. It just does browser things invisibly. Then we output an image, and there we go.

It was really just somebody being like, “Hey, can we make this a better experience?” There was no metrics, or anything like that, that we were actually trying to accomplish. It really was just trying to add polish to the overall GitHub platform experience.

[00:19:15] T: Oh, yeah. This is a question I've been having lately, then. If you're trying to work on a project, but you don't have quantitative metrics to measure, or let's say, the metrics that you're measuring are not really – They’re the thing that maybe execs, or sales people like to see, but they don't really measure the quality of your work. How do you justify your work to your product manager, or your manager, or the CEO?

[00:19:44] JE: That's such a good and difficult question.

[00:19:47] T: It's so hard.

[00:19:48] JE: Yeah. Because how do you prioritize a project? How do you say like, “Oh, yes. This is important, if you don't have the data to back it up.” How do you get the data to back it up, if you don't prioritize that project? Where in that loop does it fit to get all of that data? I think it really depends on the size of the project that you're looking at. If collecting data is going to take two weeks, and actually doing the thing is going to take two weeks, just do the thing. See if it works. See if people have a positive response. Do it in a way that it's easy to roll back, if people actually hate it.

We use feature flags quite a lot for shipping, really any change, so that if it's causing bugs, if it's causing problems, if it's just causing people to be upset, we just turn it off without having to redeploy anything. Then I think for larger projects, you do need some amount of data to say like, “Is this three-month project going to be worth it?” I think you have to be willing to put in a little bit of time to collect that data. Sometimes it's really hard. I hate doing it, but it's important, because otherwise, you won't know if you've made a positive impact three months down the line.

[00:21:08] T: Right. In other words, get some baseline of whatever it is you want to measure it, so that you can show that there was a change or no change.

[00:21:16] JE: Yes, exactly. If you didn't get that baseline, just look at Twitter. If they're happy, then you did a good job.

[00:21:24] T: Yeah. I mean, it sure sounds like Nat spends a lot of time on Twitter. I'm going to be expecting code spaces or VS code in Twitter pretty soon. I want to edit my repos from Twitter. I'll just tweet out stuff and it'll update my repo.

[00:21:38] JE: Yeah. Well, I know, really, that's true for most companies. Anytime GitHub releases a larger product feature, like code spaces, product managers, and engineers will be looking at Twitter and looking at Twitter hashtags and whatever. Looking for that feedback that you only get when you release something to a bajillion people on the Internet.

[00:22:01] AC: Is that a technical term?

[00:22:03] JE: Yes, a bajillion. Yeah.

[00:22:05] T: They didn't teach you that in math class, Ari?

[00:22:08] AC: I guess, maybe that was DFQ and higher. Yeah, they did not.

[00:22:15] JE: They taught me that in art class.

[00:22:18] AC: Oh, see. There we go. Didn't go to art school.

[00:22:22] T: Wait. Okay, important question. In Toronto, or Toronto? Is it math? Or maths?

[00:22:29] JE: Math? No S, I think.

[00:22:33] T: Because everything is spelled Queen's English. I was like, is it maths as well?

[00:22:39] JE: I will have the same reaction, if you ask me to do math, or to do maths, which will be no. I don’t know if that helps you.

[00:22:48] T: Yeah, that's fair. I feel like, it's really nice to have all of this information automatically populate in Twitter, because they feel like, having to do a lot of manual work that you have to do over and over again. We have a lot of that for the podcast, and they can get mundane sometimes. Yeah, I don't know. How can we make our lives easier with software, Jason?

[00:23:06] JE: Such a good question. She really is just the best at segues. It's impressive. There are a whole lot of ways to automate all kinds of different workloads, right? Automating, it's really just about finding the things that you do over and over and seeing what parts of it you can automate through some programming, or some creative means. It's not really all about writing code. Sometimes, you're just stitching together different services and different applications.

You send an email to all of the people. I got an email when I joined the podcast. That's automation. Otherwise, you would have to manually send out that email. I think, as soon as you can identify those things, you can already start to automate all kinds of nifty workflow things. With the Open Graph image generator, that's a really interesting one, because we really didn't do anything novel with that.

There are a ton of really great blog posts out there that walk you through how puppeteer works, how you would take a screenshot with puppeteer, and then how you collect all of the information and put together an HTML template that goes into puppeteer. That's where you can get really creative. If you wanted to make an Open Graph image generator for all of the Enjoy the Vue podcasts, maybe you could pull from the podcast RSS feed, put all of that together into a template and take a screenshot of it, or maybe there's an API, or who knows? World's your oyster.

[00:24:49] T: Also, that was a question I had earlier actually, do you also automate the alt text for the image?

[00:24:56] JE: That's also a meta tag on the HTML payload. You share a link, Twitter, whenever they crawl that whole website, all of HTML, and they look for very specific meta tags, like OG, colon image and OG colon image alt. That would be the alt tag for the image. There's really not a whole lot we can automate there, because it's like, this image that we generated. What we do is, I think, we take the repository’s description. It would be really cool, actually, if we did annotated the parts that you're looking at, like the number of stars and that stuff.

[00:25:36] T: Sounds like, you got another paper cut. Scale it for yourself.

[00:25:40] AR: Yeah. Now he knows what he's doing for the next two weeks.

[00:25:45] JE: That's exactly what it is. We talked to people, they have good ideas. Who's going to do them? That's what we're here for.

[00:25:53] T: Yeah. My commission fee is a low, low, one pick of mookie per idea.

[00:25:58] JE: I can do that. I can send you so many pictures of Mookie.

[00:26:02] T: Yeah. I'm wondering what pitfalls, or good patterns you've seen working in automation, because one headache I ran into with the specific automation service we use is that if you set up all of the triggers that you need, and then need to change the order, you've got to delete and re-add things. I feel that's very specific to our service. I'm wondering if there are general things that people should watch out for, or keep in mind.

[00:26:28] JE: Inevitably, you'll write a piece of automation, and then say, “Oh, but we actually need this other input, or we needed to compose within this larger automation workflow.” I'm thinking specifically, about GitHub actions, because they have an API for passing information to a GitHub action, specifically, so that you can compose them in other workloads. I think, that whole system evolved over time, because we started – I say, we, I had nothing to do with it. We started to see that automation tools didn't just live on their own. They didn't exist solely in a bubble. They work within these larger workflows. If you build your automation tool in an inflexible way, you'll really regret it later.

I think, the other thing is automating too much, because you absolutely can do that. If it's not actually going to save you time, if you're constantly trying to fix this tool, and it's causing so much headache, then just don't automate it. Make your life easy. Automation is not supposed to make your life harder.

[00:27:39] T: That makes me think of Wallace and Gromit, where he has the thing that makes him breakfast and puts on his overalls and yeah, it just doesn't work out that well?

[00:27:48] JE: Yeah. Imagine if every time he did that boil, splattered all over him from the breakfast, right? That would be making his life harder. Why would he do that? Just stop. Make your own breakfast.

[00:28:01] T: I haven't worked that much with automation, beyond setting up pre and post-commit hooks, I think using Husky, or a package like that. Alex, Ari, have you done a lot of automation?

[00:28:13] AC: Nope.

[00:28:17] AR: I've done a little bit of automation. I guess, I've done a little bit more than just a little bit of automation. I've done some automation. Mostly using glistening for web hooks and stuff like that, in Twitch stream stuff.

[00:28:34] JE: Yeah. I think, the Twitch API ecosystem is so fascinating. Because there's these things that happen in real-time. You're on a live stream. There's just so much that you can do with all of that information. You think of it this way. You can have a live stream that's ongoing. Then 10 minutes in, a tweet automatically fires. That is a thing that you can do. It would probably result in more Twitch live streaming engagement. That stuff is super interesting to me.

[00:29:04] T: Now, I want an automation that if somebody sends a first chat message when I'm streaming, there's little audio that plays for me, being like, “Hi, chat.”

[00:29:11] JE: Yeah.

[00:29:12] T: That would be fun.

[00:29:13] JE: 100%. I'll help you build that.

[00:29:16] AR: There we go.

[00:29:16] T: Thank you. Yeah –

[00:29:17] JE: Or I’ll just watch you build it on stream. It'll be cool.

[00:29:21] T: Oh, my God. That would be great. Yeah, let's do it. Yeah, I mostly set up hooks, because people didn't want to use the linter. The build wouldn’t build without the linter. Also, we wanted to change linting rules, but nobody wanted it to get in the way of committing. I was like, “Fine, I'll put a pre-push hook,” so it will check before you push up to GitHub, or not GitHub, Bitbucket. Then people were like, “Oh, then I can't push up regularly.” I'm like, “But you can commit regularly if you're not going to run the linter.” Yeah, I don't know. You try to make it easier, but it's also hard to get everyone on the same page.

[00:29:57] JE: Yup. I was like, that was prettier.

[00:29:59] T: Yeah. I was about to say, prettier.

[00:30:02] JE: Yeah. I did not want something touching the code that I just wrote. Then I used it enough to be like, “Oh, wait. This is actually nice.” It took me a while to get there. I think it's hard to change people's mind sometimes.

[00:30:16] AC: I love prettier. I get mad when a repo doesn't have it set up. Because sometimes I'm copying and pasting between files and maybe the nesting was a little different. Oh, my God. When I paste it and it doesn't just automatically have the right indentation, I am so mad. Because I'm like, I have to indent this myself? Oh, my God.

[00:30:40] T: I think, before prettier came out, I had an extension like Beautify or something, so I just highlight and click Beautify. Yeah, I mean, I guess if it comes in at the end after I'm done writing, and then I don't have to keep on interacting with the code while I'm working on it. I'll be okay with it. Yeah, I think for everybody, how often they want something like that to happen is very different. That's another struggle if you want to automate things.

[00:31:04] AC: VS Code settings, just saying.

[00:31:07] T: I will say that, maybe prettier’s name, I don't mind that as much as Standard.js. I really don't like that they call that Standard.js. That really bugs me.

[00:31:15] JE: That's fair. I really like Standard.js. As a rule set, I like the code that it lints. Yeah, I can appreciate that. The naming is not well-loved.

[00:31:28] T: Yeah. I just feel like, so many things that I see there are things that I don't usually see elsewhere, unless people are using Standard.js. Which brings me to a very important question, semis, or no semis?

[00:31:44] JE: No semicolons.

[00:31:46] T: Yes. You hear that, Sam?

[00:31:51] JE: Yeah. Tessa just shouted out somebody who –

[00:31:54] T: Is wrong.

[00:31:55] JE: Yeah. Is definitely wrong. We could easily argue for an hour and still not change each other's minds. Also, if you're going to write code with semicolons, you do you. Whatever makes you happy, but I don't want to.

[00:32:09] AR: I would argue that the semi-colon versus no semi-colon debate should be centered around what is your full stack look like? If you're using Python, no semicolons is probably a good idea, because Python doesn't use semicolons. If you're doing PHP on the back-end. Having semicolons on the front-end, probably a good idea, so that you keep it consistent across the entire code base.

[00:32:38] JE: I like that. That makes sense.

[00:32:40] T: I don't know. This is reminding me of when I worked with some Java developers that were like, we should write our JavaScript like Java, because we write Java on the back-end, so we should keep them the same on the front-end path.

[00:32:50] AC: That felt so awful.

[00:32:52] T: I mean, if we can do whatever we want, let's send her a line code, while we're at it. I think, that would be good. [Inaudible 00:32:57] align it. I will say, I've been trying to learn Rust lately, and remembering the semicolons is so hard. The compiler doesn't know what to say like, “Oh, you forgot a semi.” It's just unexpected token. I'm like, I feel like, it shouldn't be that hard to be like, you forgot the semi, but I keep on forgetting the semi and that's painful.

[00:33:18] AC: I just don't like reaching for the semicolon. I don't know. My pinky, it doesn't find it naturally. I don't know why, but it does not.

[00:33:28] AR: My hot take is, I like the semicolon, as long as whatever linter prettier thing I'm using, does it for me and I don't have to think about it.

[00:33:42] T: See, that’s the problem, the thinking about it. I spend so much time learning of the ASI rules, the automatic semicolon insertion. Then learning semis. Then when I saw that Vue CLI by default, creates a project without semis, I spent so long – probably as long as it took me to learn to put the script tag on top to unlearn semis. Now, if I would have to relearn it again, it would be such a struggle.

[00:34:08] AR: My thing is that, I remember, half the time to put one. Internally within my own code, I'm just super inconsistent. I'm like, “I’m at the end of the line. Semicolon.” Then I'm typing something, enter. Typing something, enter. Typing something.

[00:34:20] T: There are spaces. I feel like it.

[00:34:24] AR: Yeah. Yeah. That's why I appreciate the automation tools and the linters being able to do that for me, because –

[00:34:31] AC: It's been years since I used a semicolon. What even is semicolon?

[00:34:38] JE: I'll never know.

[00:34:40] T: I do use them when I'm writing English a lot. That's about it now.

[00:34:45] JE: It's funny, because I think my biggest gripe with them is that I don't find them a visually attractive character in my code. It's like, it’s at the end of the line hanging out. In prose, in English, semicolon’s fitting into a sentence. It just breaks it up, and it's so nice. I'm very inconsistent.

[00:35:07] T: It's like an unfinished thought in English. Then in code, it's no, I'm finished now.

[00:35:12] JE: Exactly. Yes.

[00:35:15] AC: No. Finish is end curly brace. Duh.

[00:35:25] T: Oh, I'm so embarrassed. Called out. This is making me think back to my first job. I really liked tabs. I spent so long getting used to using the two spaces before my first job, because I was sure that everybody there would be like, “You have to use spaces.” Then I started, and my first team was just a very – “We don't care how you write your code, as long as you keep it readable and commented.”

[00:35:49] AC: Did we really just go down tabs versus spaces lane?

[00:35:53] T: I mean, we can.

[00:35:55] AC: I mean, you just did.

[00:35:57] AR: All right, Ari. Give it to us.

[00:36:00] AC: I actually have no strong preference. I use the tab key to insert two space.

[00:36:08] AR: All right, I'll give my hot take then, since we're going down this route. Tabs are correct.

[00:36:15] AC: Why?

[00:36:16] AR: Accessibility.

[00:36:17] T: You can resize, though.

[00:36:19] AR: Because if you want them to look two spaces, they can look two spaces. If you want them to look four spaces, they can look four spaces. It doesn't matter.

[00:36:31] T: Actually, paper cut. When I was learning coding, my group hated me, because I used tabs. Then in GitHub, it would look like eight spaces. You don’t want to use it only for that reason, because they were like, “We don't like looking at it on GitHub.” I'm like, “But you're looking at your editor.” They were like, “No.” Why, Jason? Why?

[00:36:48] JE: That's such a good paper cut.

[00:36:50] T: I know.

[00:36:51] JE: No, I mean, it's like, thank you for telling me. I would be surprised if it's not already on our project board. If it's not, I'm going to put it there.

[00:37:01] T: I'll be watching for it.

[00:37:02] JE: I'll let you know. I'll keep you updated.

[00:37:04] T: Then @NatFriedman.

[00:37:06] AC: That’s the only reason I'm anti-tabs is because of the horrid effects it has when viewing it on GitHub.

[00:37:14] JE: That sucks. That's terrible. It shouldn't do that.

[00:37:22] T: Yeah, I wonder why that is.

[00:37:24] JE: I'll fix it. We'll fix it

[00:37:27] T: One more Mookie pick for me.

[00:37:31] AR: Did we talk about the cool thing that GitHub started doing recently, today?

[00:37:37] JE: Oh, GitHub code spaces?

[00:37:39] AR: Yeah, that thing.

[00:37:40] JE: Yeah. That was released yesterday, August 11th. I don't work on the code spaces team, and I don't want this to be an advertisement. It's really cool, and I've been using it a lot. You should check it out. It's like a virtual machine for all of your projects in the cloud, so that you can code on an iPad, or an iPhone, or anything that has an internet connection and a browser, or VS code.

[00:38:06] AR: Yeah. It's VS code in your browser, but also VS code in your VS code, so that you can VS code from anywhere with VS code.

[00:38:15] JE: Yeah. I will not use code spaces from the browser, because the key binds are all weird. I only use it from VS code. It's like, why would you even bother if you're going to be using your local VS code? That my math books fans don't spin when I run anything. Because now, all the processing is in the cloud, so I don't have to worry about that.

[00:38:38] AR: In the cloud.

[00:38:41] AR: Which means that I can add more fonts to the thing and make it look even better.

[00:38:47] JE: Exactly.

[00:38:47] AR: That was great.

[00:38:49] T: Nice. Yeah. I feel like, shortcuts in the browser are always tricky. When I used to edit with Pixlr, and they'd be Command+T, or Ctrl+T is your transform shortcut. That obviously interferes with a tab shortcut. You don't want to override those. 

[00:39:06] JE: Yeah, we just added more shortcuts when you're writing markdown in GitHub. You open a new file, you start writing a markdown file. We had to do a bunch of research to make sure that we weren't conflicting with anything, to make sure that, like he said, command and control work properly across operating systems. It's really interesting.

[00:39:27] T: On that note, let's wrap up. Jason, if people want to learn more about you, and all that you do, where can they find you on the Internet?

[00:39:36] JE: The best place is Twitter. Twitter.com/jasonetco. Everybody always spells it wrong, so I'm sure there’ll be a link somewhere.

[00:39:44] T: They do?

[00:39:45] JE: Yeah. I often get ECTO, but it's actually ETCO.

[00:39:51] T: Ecto, like a Ghostbuster. Okay.

[00:39:53] AC: I was like, these Ghostbusters fans, obviously.

[00:39:57] T: Sounds like, Jason and company. Jason Etco.

[00:40:01] JE: Yeah. I also get a lot of Jason etc., which is funny, but not accurate at all. I also get a lot of JSON. That's fine. I'm cool with that one.

[00:40:14] T: You don’t know who it is, but you're cool with it. Nice. With that, it's time to move on to this week's picks. Ari, would you like to go first?

[00:40:25] AC: Sure. My pick this week is a mobile puzzle game that came out a bajillion years ago.

[00:40:36] T: That’s a technical term.

[00:40:38] JE: Yeah, technical term. Yeah.

[00:40:41] AC: That I just recently started playing again. It's called Marple. It's just a logic puzzle. I don't know. It's something that's really good to kill a few minutes, because I think my average puzzle time is three minutes, 40 seconds. If you just need to kill a few minutes, but also want to feel you're doing something productive with your brain, I highly recommend Marple.

[00:41:07] T: Nice. This is reminding me of when Ben used to recommend games, and they all sounded like work. Alex, what are your picks for this week?

[00:41:18] AR: My pick this week, we just started watching, because I'm super late to the game on this one. We started watching Shera and the Princesses of Power on Netflix. It is super fun. We're enjoying it greatly. That is my pick. If you're looking for something fun and light-hearted to watch, go watch Shera and the Princesses of Power.

[00:41:42] JE: I think, I will.

[00:41:44] T: Are you a princess of power?

[00:41:45] AR: Oh, yeah. I am. I am a princess of power. There you go.

[00:41:50] T: Jason, what are your picks for us this week?

[00:41:54] JE: My cat, Mookie, just came to live with me. Now, anytime I leave my apartment, I want to know what she's doing. I got this Wise camera. It's like a security camera. It’s really inexpensive. It's super high-quality. I'm very impressed with it. I've only had it for two days, but it's pretty cool. Now I can see where she's snoozing. If he's trying to get into any treats, or something while I'm out. Very excited.

[00:42:21] T: Nice. I like how now that your cat is living with you, you're like, I need more pictures of my cat, versus when she wasn't living with you.

[00:42:32] JE: I always need more pictures of the cat. I want to make sure that she's – now she's in a new space, and I don't want her getting stuck in the dishwasher or something. I don't know. I don't know what she'll do, but she'll get stuck somewhere.

[00:42:46] T: Maybe she'll get stuck in a code space. Oh, no.

[00:42:50] AC: Oh, no. The vast majority of my text exchanges with my partner are just pictures of the cat doing cute stuff.

[00:43:00] JE: As it should be.

[00:43:02] AC: We're afraid the cat will move before the person gets in from the other room. Naturally, my partner's 15 feet away from me technically, still sending a picture of the cat.

[00:43:15] T: You might say, he's more like a pawrtner?

[00:43:21] AC: Tessa, it was really nice having you on the podcast.

[00:43:25] JE: I’m really glad to see that she does this everywhere.

[00:43:29] AR: Yes.

[00:43:30] JE: I respect it.

[00:43:31] T: Thank you. I got to protect the brand. All right, Jason. We've been asking all of our guests to tell us more about their headphones lately, but you're not wearing any.

[00:43:41] JE: I'm not wearing them, but I'm holding them up to the camera now. These are the SteelSeries Arctis Pro Wireless. I was bullied into buying them. They're actually really good. I'm happy with them.

[00:43:55] T: So good that you're not wearing them.

[00:43:58] JE: I have a proper microphone, and I like speakers for when I listen to music on my desk. These are really just for playing video games and yelling at my teammates in Valorant. Usually, they're all my friends though. I don't yell at strangers.

[00:44:14] AC: Why not? It's fun. I mean, I have never.

[00:44:18] T: Yeah, if you feel yelling at a stranger, no. Anyway.

[00:44:22] JE: Games are too toxic.

[00:44:25] T: Finally, it's time for my picks. We already talked about this a bit earlier. Code spaces and VS code in a browser seems really cool. Yesterday, Jason and my buddy, let's call him a pal. Our pal, Joel tweeted out, go to any GitHub repo and press the period button link, which I guess it has a semicolon on it, so semicolon friend. I did, and then VS code popped up. I was like, “Wow, that is super cool.” Seems like a much nicer way to navigate a repo online than the typical search and stuff. I know, GitHub also has its own shortcuts for that, I just never learned them. Yeah, so that's pick number one. Pick number two is The Matrix, the original movie that came out in ’99, or whatever, because I have to watch it again for homework. I'll be doing that soon.

[00:45:11] AC: It was ’98. I actually have no idea.

[00:45:14] T: Okay. You looked really offended, but I – You know what, Ari? We’re going to learn today.

[00:45:20] AC: Oh, it was ’99.

[00:45:22] T: ’99.

[00:45:22] AR: What do you mean the original Matrix movie? There was only ever one Matrix movie.

[00:45:27] T: I’ll just get out. Isn't there that one coming out soon, but without your Morpheus, because, yeah, I read an article with Laurence Fishburne being like, “I’m not in the fourth one.”

[00:45:39] JE: I'd watch it.

[00:45:41] T: Yeah, just to see for sure. Cool. On that note, that is all for this week's episode. If you aren't following us on Twitter, what are you doing? We're going to be tweeting Mookie pictures all next. No, I'm kidding. I don't have permission to say that. We might, maybe.

[00:45:55] JE: I'll give them to you, if you’ll tweet them. The world needs to see this adorable cat.

[00:45:59] T: They really do. We'll be tweeting Mookie pictures during the week of this episode. Follow us on Twitter @enjoythevuecast. Alex is going to start a new Twitter account for us called @enjoythevuecats. Watch out for that.

[00:46:12] AR: Yes, we’re going to have – anytime we get pictures of our cats, we will put them up on Enjoy the Vue Cats.

[00:46:19] AC: I do. I need to just start sending them to the group chat?

[00:46:22] AR: Yeah. We'll figure out a way that we can –

[00:46:24] T: You can log into Twitter, Ari, on another account.

[00:46:27] AC: No, because I will inevitably, not realize which account I'm on and then I'll pull a Donna Meagle.

[00:46:36] T: Oh, no. Posting cats on your personal account. Reputation ruined.

[00:46:44] AR: Maybe we'll work on some automation for this and we'll automate the Enjoy the Vue Cats account.

[00:46:52] T: Yeah, and don't forget to like and subscribe and smash that bell icon. Be sure to subscribe to the show. If you have time, leave a review here. I hear it really helps us out. Finally, remember to tell at least one friend what you enjoyed about today's episode and how adorable Mookie is. Thanks for listening. Until next time, enjoy the Vue.

[END]