Productivity Tools, Workflows & Tabs vs Spaces

Automated Speaker: This podcast is brought to you by our friends at Linode. Whether you're working on a personal project or managing your enterprise's infrastructure, Linode has the pricing, support, and scale you need to take your project to the next level. Get started on Linode today by going to linode.com/vue.

Ben: Hey everybody and welcome to Enjoy the Vue. I'm Ben Hong, and today on our panel, we have Ari Clark.

Ari: Hello.

Ben: Chris Fritz.

Chris: Hello.

Ben: And Elizabeth Fine.

Elizabeth: Hello.

Ben: Today we're here to talk about our tools, workflows and just nerd out on productivity. So, let's start with the base question. What is your developer tool stack, starting with your browser? Let's just go around the panel. Ari, why don't you start?

Ari: Chrome.

Ben: Okay. Chris, you're up.

Chris: Chrome, also. Yeah. Primarily. I test in other browsers too, but Chrome's my go-to.

Ben: Good, and Elizabeth?

Elizabeth: Firefox.

Ben: Ooh.

Elizabeth: I used to be on Chrome, now I'm really on the Firefox train a little bit so.

Ari: I'm not going to lie. From what I've seen, their developer tooling has gotten really good, but unfortunately, the only browser we support is Chrome at work [crosstalk 00:01:21].

Ben: I think that's a very legitimate reason to be on Chrome.

Ari: Yes.

Elizabeth: It is really, really good, but that's one of the reasons why I like developing on Firefox because the developer tools are great. And I find that the network tab is really easy to look through and it's really easy to view. And the console is really clean. So, yeah. I really like Firefox, but I also do use Chrome like half the time so.

Ben: Yeah. For myself, I use Chrome as well, but I have been sort of edging over to Firefox. One of the things I love Firefox for is they have a built-in screenshot feature, where you can just right-click, take a screenshot and it can actually do the whole page...

Elizabeth: What?

Ben: ... of website instead of just taking one shot and then scrolling down and [shotting 00:02:04] it...

Elizabeth: Oh my gosh.

Ben: ... the whole page is just...

Ari: My mind is just blown.

Ben: Boom. Like you get the whole thing. In Chrome, you have to install an extension and Firefox is native. It's so great.

Elizabeth: Oh my gosh. Okay. You just changed my workflow a little bit. A lot of the reason I use Chrome is for subtlety. I use Browser Stack sometimes for browser testing, and I don't think they have a Firefox extension, so that's a lot of the reason why I end up on Chrome for extensions that I need and stuff.

Ben: Sure. Cool.

Elizabeth: We didn't do you, did we? [crosstalk 00:02:33] Oh you did? Okay.

Ben: I'm on Chrome, primarily, but I'm actually playing with going over to Firefox.

Elizabeth: Okay. Cool. Join the dark side.

Ben: ... [crosstalk 00:02:42] instincts.

Ari: More of a light side, depending on how you look at it.

Chris: I've had many dalliances with Firefox over the years.

Ben: Oh, dalliances [crosstalk 00:02:54].

Ari: Well, I was actually a Firefox person for a decade until I became a developer.

Ben: Quantum made it really good. I really like Firefox after it went Quantum. Okay, so how about code editor of choice? So I'm on VS Code. Ari?

Ari: VS Code.

Chris: VS Code. I mean that's for Vue definitely the best experience.

Ari: It's literally why I made the switch because I was using Atom, but I was like, "Well, yeah. Looks like VS Code is the best option if I am going to do Vue."

Ben: What about you Elizabeth?

Elizabeth: Yep. I'm also on VS Code, which is awesome. Yeah, it's really great.

Ben: Yeah. I used to be on Sublime Text and I paid the $80 for my license. Believe me when I say I went kicking and screaming to VS Code. I was like, "I paid for this editor and Microsoft made this free thing that's supposed to be good."

Elizabeth: But I was like, "No, okay this is great", darn it.

Chris: I don't think we can mention VS Code without also mentioning the Vetur Extension, which adds syntax highlighting and snippets and a bunch of other things for Vue files. Really a must have if you're a Vue developer. It is officially maintained by the team too.

Ben: Ooh, I actually did not know that.

Chris: Yeah, it's maintained by Pine Wu who is a member of not only the Vue team, but also the VS Code team.

Ben: How convenient. [crosstalk 00:04:21]

Ben: It's not only a great Vue Extension, but its one of the best extensions that exist for VS Code period.

Chris: Yeah, Pine's amazing. If you ever get a chance, checkout his talk from the first Vue ConfUS.

Ben: Okay. Speaking of VS Code, there is the integrated terminal. So, what are they doing for terminal? Is everyone here using the VS Code terminal?

Elizabeth: Yeah.

Ari: I use the built in terminal, but I also use just terminal.

Ben: Ooh, you use Just [crosstalk 00:04:49]

Elizabeth: Just terminal?

Ben: Just terminal.

Elizabeth: Not even like iTerm or anything? Just straight up terminal?

Ari: Oh, no. No [Vanilla 00:04:55] Terminal. [crosstalk 00:04:58] I use the built in terminals for everything Git related. But then for running servers and stuff I just run those in terminal.

Ben: You also use shell instead of bash?

Ari: I use zish.

Ben: Yeah, okay. You have zish at least. Okay. At least.

Ari: I don't feel judged at all.

Ben: Yeah, you've redeemed yourself slightly.

Elizabeth: On the built in terminal, I've noticed recently that if you have a server running, lets say in your built in terminal in a workspace. Then you switch workspaces, then it cancels your terminal, obviously. Recently, I've been starting to run my servers in a separate terminal, not the actual terminal the iTerm. And then which, you know what, not even that long ago I used to have my iTerm with ... You know how you can customize it and make it look hardly one. I got really carried away, and then made it 60% opaque. You could see through a lot of it. It just made it look horrible and really hard to read. I can't believe I ever worked like that.

Elizabeth: It has multiple iTerm windows and they're all overlapping and they're all semi-transparent. I don't do that anymore.

Ben: You have a screenshot of that? I would love to see that.

Elizabeth: No. This is the old days.

Ari: I do at least theme terminal.

Ben: Okay, so at least you have a theme. It's not just a black and white character. All right, then you're all forgiven. I'm on iTerm as well and use ohmyzsh.

Elizabeth: Yep, I don't know what that is.

Ben: Oh, ohmyzsh? It's basically Zish, but it comes with packaged themeing and [crosstalk 00:06:36]

Ari: It comes with a bunch of aliases that are super nifty. I just type GAA for git add all. It is the best.

Ben: Yeah, definitely. If you're using zish already, its worth checking out. Although, I remember Chris saying something about something called fish, I believe?

Chris: Yeah, I guess I'll go and just talk about the whole thing. I used the VS Code integrated terminal for most things related to a specific workspace. But there are some things, like when I run Vue UI. I'll do that in separate iTerm window or even sometimes just regular terminal. It's been known to happen, because I just want something like running in the background. I just want something running in the background for all of the projects that I might use. And not have to worry about the terminal closing when I switch workspaces, as Elizabeth was saying.

Elizabeth: Yeah, I also have to SSH into servers a lot, for my work. It makes sense to have that separate.

Ben: Yeah, exactly.

Chris: I use ... I have beautiful, beautiful themes and stuff like that, that I set up. I like my terminal and my editor to be just a place that I want to hang out.

Ari: I totally agree.

Chris: I use fish, which is like ... I'd say if you're a keyboard geek. I also use Colemak and I'd say Colemak is to Dvorak as Fish is to Zish.

Ben: And that's Fish without "I's"?

Chris: So for the people who really care about keyboard layouts, they'll say Dvorak. No it's Fish with an "I".

Ben: Oh, okay.

Chris: For people who really care about keyboard layouts they'll often use Dvorak, if they want to optimize that. And then the people who are mega-nerds who really care and actually did the research, they'll be using Colemak instead, because it's better. And with the terminal it's the same way. If you're kind of geeky about your terminal, you're probably using zish. But if you actually want a terminal that isn't super slow and is super customizable, and does exactly what you need to do, and you don't mind learning a slightly different syntax, so that not all the bash commands work, then you'll use fish.

Ari: But why would I do that?

Chris: You do it if you're a control freak.

Ari: You do you Chris. You do you.

Chris: Yeah. If you want to control freak and it gives you anxiety thinking that maybe you're not doing the best thing absolutely possible.

Ari: Are you saying you're not doing the best thing possible?

Chris: No, I'm saying I am doing the best thing possible. The reason I am willing to go way out of my way to do that is because I experience just constant anxiety otherwise.

Ari: I mean if it helps you sleep at night, I support it.

Chris: Learning a new keyboard layout is cheaper than drugs. And it's like-[crosstalk 00:09:29]

Ben: That needs to be on a bumper sticker.

Ari: I don't know. It depends, because if you consider that your time is invaluable ...

Chris: I don't consider my time invaluable.

Ari: You probably should. One thing that was brought up during that is the concept of themes. What themes are people using in VS Code?

Chris: I'll go first. I'm using Sarah Drasner's Night Owl, with a font face of operator mono. Yes, I paid money for my typography.

Elizabeth: Like Chris said, you want it to be a place you hang out. If you're going to stare at it all day, every day for years, and years, and years is it worth it? Over [crosstalk 00:10:17]

Chris: I've gotten so much worth out of it.

Ari: Elizabeth?

Elizabeth: Yep. I also use the Operator Mono. And I use a thing called Horizon, which I really like, because its very warm and I like to look at things that are warm. It looks like a sunset color theme. I really like that. There's a light version and dark version. I go for the dark version, because I just think the light burns my eyes a little bit [crosstalk 00:10:43].

Chris: For a second, I thought she was like, "I like it warm." So I thought she was going to go light version [crosstalk 00:10:51].

Elizabeth: No. It's a dark but warm color. It's really nice.

Ari: I might have to check that out.

Elizabeth: Yeah, I know. Try it. It has a really good bright colors, but not too bright and good contrast and everything. I have the italic version turned on. With Operator Mono, you get the little cursive scripts, which is ... I just find that ... The cursive thing it makes it actually really a lot easier to read, cause it differentiates.

Ari: What about Chris?

Chris: I switch back and forth between Operator Mono and Monoco. Definitely, I use monoco for all the demos that I do, like in slides and stuff like that. Because I find it supremely readable. It's very familiar to a lot of people. Operator Mono can be a little bit pretentious with all that cursive. I don't know, cursive and code, I don't know they seem to be a route that ... It's just like, "Ooh, I'm writing code. Look at this." I prefer monoco most of the time probably. My theme is pretty heavily customized. I just use a lot of ... I changed a lot of the colors and there's not really a base theme that I rely on now. [crosstalk 00:12:07]

Ari: I keep wanting to do that, I just never take the time.

Chris: I find it an investment because it means that whenever there's something that I don't like, I don't have to go and start doing research to show different themes where, often times there's just one thing that I don't like about the theme. This way I can just change the thing that I want to change and be done with it.

Ari: It's on my to-do list to actually learn more about customizing themes. Because I'm really anal retentive about colors.

Chris: VSCode has made than it used to be. You can just sendset a lot of colors and settings.

Ari: It looks like its really easy, but ...

Chris: You don't even have to create a theme that you publish in an extension or anything like that. In the settings you can change a lot of colors. If you want to learn more about how you might create a custom theme, the Sarah Drasner's Night Owl is probably a great project to look at. It's open source and she's on the Vue Docs team. So obviously, she documents it well. It demonstrates a lot of things about how to create a great theme. It's a great template to work off of, I think.

Ben: What about you Ari?

Ari: I recently switched themes, which I never thought I would do, because I was just so used to One Dark from Atom. I just kept going with that. But, the code just started to piss me off too much. I have crappy monitors. I couldn't do it. So I switched to another staple Monakai and I used Dank Mono, which I think looks pretty similar to Operator Mono and its also [inaudible 00:13:53].

Chris: It's just a little bit more dank.

Ari: Exactly. Because that's how I roll.

Chris: This is like Operator Mono is what they use in ivory towers. Dank Mono is the cool street font.

Ari: I want to say Sarah Drasner uses Dank Mono, I'm just saying.

Chris: She's pretty cool.

Ari: Right, I think we can all agree on that.

Chris: I think this just supports the case.

Ben: All right, the big question, tabs or spaces?

Ari: I hit tab key and it puts in spaces, so neither.

Chris: No - spaces. Everybody uses the tab key. You can't pretend you don't have a side. Clearly you have chosen your side and it is spaces. It's only in Silicon Valley where they completely ... Obviously, they didn't talk to an actual programmer ...

Ari: When she's just hitting the space bar.

Chris: When she's just hitting space. It's like, "No, you don't understand that at all. That's not the thing with tabs versus spaces." It's not about hitting the space bar versus the tab key. Everyone is hitting the tab key.

Ari: Some people I think actual do hit the space bar.

Chris: But that is not the main argument. That is not the main tabs versus spaces argument.

Ari: I am on spaces.

Ben: How many spaces?

Ari: Two. [crosstalk 00:15:17] Obviously, two.

Ben: Obviously two. Ooh, that was strong. I like it. I like the confidence. What do think Elizabeth?

Elizabeth: Yeah, I hit tab key as well. And I think I get four spaces out of that. Little bit of a rivalry there.

Ari: I don't think we can be friends anymore, Elizabeth.

Elizabeth: Actually, wait, wait, wait. I was just looking at my config. I updated it. Originally, it started out with four spaces and it looks like I've edited my VS Code so that it uses two. Clearly, I don't feel strongly about it to the point where I don't remember, but apparently I use two spaces for my tab size.

Ari: Wait are there monsters out there that just use three spaces?

Elizabeth: That's a good question.

Chris: I don't know.

Ari: Unforgivable.

Chris: That'd be weird. I use two spaces and because I'm a little bit obsessive like this, I investigated the problem. I figured there has to be some research on what's more readable? I found that two spaces, three spaces, and four spaces, all equally readable, even giving people time to get used to it. Even for people who aren't used to it, two, three, four, all equally readable, which means that two is obviously the optimal, because you can fit more on your screen.

Ari: Exactly.

Chris: Two is technically the correct answer.

Ari: I agree. It is the correct answer. And there's only one correct answer.

Chris: Well, there is in some cases and this is one of them, I think. We've investigated the problem. We have the tools. We have found that two, three, and four equally readable. So if you're using three or four, you're wasting screen space for no gain.

Ari: Wait, but we haven't heard what Ben's preference is. And before he say's four ...

Chris: No, he's going to say three.

Ben: Amateurs, five okay, five.

Ari: What? No. Mm-hmm (negative). Not okay.

Chris: That is the wrongest of choices.

Ari: That has been proven wrong.

Ben: What's funny is I used to be spaces and then ... I joined a team that was very strongly tabs and the rational behind it was that you could let the developer choose the sizing of the indent. Because when you choose the space indent, you can't technically choose the indent size. You can choose how much a tab is represented by, if someone wants to do two, someone wants to do four. It was interesting because basically at one point when I was working with a team, it was like, what tabs are more accommodating to how a developer wants look at their code, versus enforcing them to two or four. Personally, I prefer two spaces.

Ari: I like to bend people to my will. I'm against tabs.

Chris: I think tabs would make sense if there wasn't an actual correct answer.

Ben: Well, technically tabs [crosstalk 00:18:08]

Chris: There is research that exist that shows two is obviously the best and anything else is sub-optimal.

Ari: I think it's okay to force people to be right.

Ben: But there's only weak argument I've heard for tabs. It's like well, "That's like more characters. Two spaces is more characters than one tab." So, a larger file size.

Ari: Is it though? Because aren't we all minifying that anyway.

Ben: On the web, yeah for us, for JavaScript. We are usually minifying that, but then what if you don't want to have to rely on a built process like that? I say it's a weak argument, because its so insignificant, in terms of extra file size, but its there.

Ari: I'm just going to ... with an anecdote, casually refute that. I work with a bunch of C programmers, not like C plus, plus C. We're talking old school. The RCTO is possibly more anal retentive about code formatting than I am, and that's saying a lot. He will put in spaces just to make sure everything lines up visually. Like I said, he puts in spaces and he puts in lots of extra spaces and he's a C programmer, so it must be okay, to say.

Ben: Although, isn't C compiled, so they wouldn't matter then?

Ari: Yeah, but C programmers definitely absolutely care about bits, literally.

Ben: Yeah, but it wouldn't make a difference in the compiled bits.

Ari: Yeah, but there's still a file system that they care about, right?

Ben: Yeah, I guess, yeah. If they're still storing the codes somewhere, that's true.

Ari: I should also mention that he also works in the storage array space so, literally his whole thing is about file size.

Ben: I guess if someone is running out of hard drive space because they're using two spaces, instead of one tab-

Ari: They have bigger problems.

Ben: ... just get another hard drive. You had this computer for 20 years now, it's time to get a new computer.

Elizabeth: Cool. Now that we have that figured out. I'm curious what all of your git methodologies are? Because, I feel like mine changes day to day. Sometimes I'll have bigger commit sizes, sometimes I'll have smaller commit sizes. Usually, if I'm making one little change, but going back and forth between something that worked and something that didn't work, I'll go in and fix up the commits. And then I guess reword the one that I squashed them all into, so that it encapsulates the one sort of feature I was trying to create. If I'm working on a larger feature, I'll usually ... A lot of times I will commit stuff like "stash", or "stuff", and "progress", and things like that. And then at the end I'll go in and organize them all. And I'll squash them into commits and reword them to what actually happened before I actually push it up. And then hopefully, not forget to do that. Because sometimes I do look at my commit history that hasn't been pushed up and see stuff like "did things." I'm like, "Oh, my gosh. That's embarrassing."

Ari: Everyone has had that commit messge.

Elizabeth: Lets commit some more, so that gets farther and father down, and nobody sees what I did. Ben what is your commit methodology like? How much do you like to squeeze in one commit? When do you go ahead and edit messages you've already committed, things like that?

Ben: Yeah, when it comes to git methodology, I'm a little actually OCD about this. I'll actually intentionally break up my commits, because I try to tell a story with my commit messages. Everyone has like this horror story of you're fixing this hot fix bug and you're looking at the code that got broken and the commit message is "code change". And you're like, "This does not help me, why you did what you did." I treat Git log a little bit, basically like they got to get documentation basically. It's the whole try to keep it with one line. I do the category thing, where I do feature, fix, style and then parentheses issue number, colon, and then start with your action verb of what you did. And then a short description of why you did it. That's sort of like my formal-

Elizabeth: Wow! That's so thought out. I do not do anything like that. I know that I probably should. Generally, I'll make a branch with the issue number on it. And then everything inside that branch is just my own thoughts spilled out into a commit message, with no format whatsoever.

Ben: It's not without its fault though. Sometimes, I'd be like into a feature and then I'll realize I should have committed a message earlier. I'll break it out to recommit it differently. It's a [inaudible 00:23:09]. I don't need to squash a lot. I do love using rebase. I do love rebasing branches.

Ari: I like to be realistic and show a very real story of my development journey. I never rebase, I never squash. What you get is what you get, including the really frustrated commit messages like, "Did some things because I screwed up earlier." Or I think my favorite commit message ever was, "Oopsies, fixing a typo!" And my boss totally called me out on that one. He's like, "Oopsies?" I was like, "Yeah, oopsies."

Elizabeth: You're like, "That's what happened. That's what's in this commit. It's accurate."

Ari: The size of my commit tends to vary. Right now we are getting ready for a release and to be honest we cut our release branch a little prematurely. I'm having to merge new features into two different very distinct branches. I try to make it so I can just easily cherry pick to the release branch. I now have the bad habit of larger commits, just to make my life easier. Honestly, if ... Otherwise, it sort of varies in how in the zone I am. Because sometimes I'll just forget to commit for way too long. And I'm like, "Oh, crap. I don't even remember what all I did." Well, we'll just do the gist of the overarching theme and totally skip all the other little things I did along the way. Yeah, that's me. Very natural with my commits. I do go easy about telling this story, I do try to start with a verb. Say what I did and why.

Ben: There you go. That's all that really matters.

Ari: But I do not keep it to one sentence. I am just not that awesome.

Elizabeth: I know. I never keep it within the commit message. I'm like, "Blah, bla Blah. And then this, and then blah, blah."

Ari: I'd rather have too much information than not enough.

Elizabeth: How about you Chris?

Chris: Yeah, I like descriptive commit messages. I think the more people you have on a team, the more important that is. When you're by yourself, I think it's okay sometimes be just, "Fix this. Okay, for real actually fix it, now. Okay, now it actually works." Since they are communication if ... There aren't a lot of cases where I'll go super far back in time to see what a commit says, to see why that change was made. Because there is so much other history in there as well, like around that code that changed. When I'm working by myself, I really don't think the commit messages are that important. But when it is an open source project or you're working with a team, especially a big team, then those can be really, really handy.

Elizabeth: The case where I use commit messages the most, and this goes back to VS Code, is I have Git lens- [crosstalk 00:26:00]

Ari: Yes, so helpful.

Elizabeth: So helpful. You can just click on a line and it brings up the commit message. If you try and think about if someone clicked on this line, what would I want them to see about this? Why was this implemented? What does this relate to? That's really the only reason I ever use Git messages, because I usually don't ... Unless, I'm trying to scroll back through a branch and figure out, "Okay, what did I actually do in the last week." That's the only other reason that I will look at commit messages. But yeah, Git lens is awesome. I really, really, really, prefer to view commit history and stuff like that in my code editor as opposed to on Git hub or BitBucket. It's just a lot easier to look through.

Ari: That must be nice to be able to use things like that. We just have an old Chrome Git server.

Elizabeth: Really?

Ari: Yeah. It's different.

Ben: And for those wondering more about the formatting I was talking about. It is an official Colemak open source spec. It's called Commitizen. We'll be sure to include that in the shownotes.

Elizabeth: Commitizen? Is that supposed to be like a play on words of citizen?

Chris: Citizen. Yep. Sort like the rules you follow.

Elizabeth: Be a good Commitizen.

Ben: A good Commitizen. It lends itself to a good recommendation of that [crosstalk 00:27:12].

Ari: What are some of your other favorite VS Code extensions? I'll throw out one, better comments. It allows you to annotate your comments in a way that will highlight them in different colors, based on the indentation. And since I'm a very visual person and I like to quickly parse things visually, I love it. For example, [crosstalk 00:27:33] if you just type "to-do" in all caps it'll highlight it in all orange, so it's easy to find later.

Elizabeth: Oh, my gosh. Because I was going to say my ... The only other VS Code extension I use is to-do highlight. So it's [crosstalk 00:27:45]

Ari: There's other options like alerts and questions.

Elizabeth: I have been looking for something like that so I'll have to try it out.

Ari: Yeah, I highly recommend it.

Elizabeth: Cool.

Ben: My fun VS Code extensions, there aren't many I like, but Polacode. So it's like Polaroid, but Polacode. It allows you to take snapshots of your code, but in a pretty format. It's really good for slides and that kind of stuff, if you're not using already keynote and those sort of things. Polacode is pretty great.

Elizabeth: Polacode.

Ari: I'm going to have to use that.

Ben: For those listening you would drop all these in show notes. Chris you got any fun VS Code extensions you like?

Chris: Yeah, give me a moment to pull up what I actually use in the enterprise boilerplate. Rather than just trying to remember that. Especially, for Vue developers, specifically, there are in a dot VS Code folder an extensions.js file, which VS Code will look at and recommend to you, but when you open that project and ask you if you want to install them. And the one that we mentioned already is Vetur, for Vue projects. Vue Peek is also a great one, for peek and go to definition for dot Vue files. There's VS Code eslint, for lint on save, VS lint, eslint with [stylelint 00:29:02], there's lint on save with stylelint, although that one it seems like has been deleted or something. I have to find a replacement for it.

Ari: Yeah, I keep getting that warning. I'm like, "I bet it's Chris' fault." And it is.

Chris: No, it's not my fault.

Ari: It's your fault it isn't installed on my computer in the first place.

Chris: Okay. I am sorry. I will remedy this as soon as possible. It's been annoying for me too. I just haven't had the time to research it yet.

Ari: Yeah, me neither. I didn't care that much.

Chris: Format on save with prettier, that's prettier VS Code and for SCSS Intellesense VS Code SCSS and then VS Code jest for better jest integration and then VS Code markdownlint, to lint mark down files in the editor. And that's it. Those are all the ones that I recommend in the enterprise boilerplate.

Ben: If it's not obvious Chris really likes linting.

Chris: Yeah, I really like linting because I'm lazy. I don't like having to do stuff. And I like it when my tools can fix errors that I make for me automatically and let me know that I did something wrong before I have to see an error in my web browser. Or see something just not working the way that I expected it to and then wonder why.

Ben: You have to avoid those awkward PR's, right Chris?

Chris: Yeah. I don't want to have to tell someone, "Hey, you missed a space." I don't want to be that jerk.

Ben: Cool. Well, I think as far as the last tools I think we should do guys before we wrap up the show, if you could name one productivity app that really helps to improve your workflow and your life, what would that be? To give like a more explanation. For me I really love Calendly. It's basically, you give a URL to someone, and they can just schedule stuff on your calendar. It saved me so much time when people are like, "Let's find a time to chat." And you don't have to open up your calendar and then message them and then search contacts ... Just send them a link, they'll figure it out and everything is automated. Calendly is my ... One of the best productivity hacks that I've had for me. Does anyone else want to go next?

Elizabeth: Well, okay. My number one productivity app ... I'm not going to say it because, Ben I think its your pick today, so I'm going to leave it for your pick.

Ben: No not all. What is it? What is your pick?

Elizabeth: Notion, oh my gosh. Notion is my number one favorite productivity tool. I keep track of everything there, like what am I currently working on, create kanban boards or combine, or whatever tasks boards, whatever you want to call it. And my own little documentation of ... For example, if I'm debugging something ... This is really dumb, but I will open a new notion tab and I will write almost this murder mystery style story about it. Try and figure out you know... This is what I do. This is what I use Notion for. It's really awesome. I used to do it in my notebook. Just write down ... Not in any kind of creative way. But I'll list all the possible suspects and things like that, and eliminate them, and list what I know about the situation, things like that. I use Notion for that. That really helps with debugging.

Elizabeth: And then I mentioned on previous episode Todoist and that was being really helpful for me, for keeping track of to-do items. This is actually going to be my pick, and I just ruined Ben's pick and my pick [crosstalk 00:32:34]. My pick is a new to-do app I found that is better for like ... I don't know. It's a lot simpler than Todoist. It's called Minimalist, two words pushed together, Minimalist. And it's a really, really clean UI, where it just basically lists your to-dos and you can just cross them off. And there's nothing else to it. It's super nice. There's no buttons or anything, it's all controlled with screen gestures, pulling down, or pinching or things like that. That's good if you want to stay in focus mode. I think its got a Pomodoro timer method on it. [crosstalk 00:33:09] Pomodoro your task. Yeah.

Chris: For that one you can't have different priorities and due dates and stuff like that?

Elizabeth: I don't think you can have due dates. You can move them around, like up and down. But it's really for just super simple todos. Yeah.

Ben: Any productivity tools that make your life a lot easier?

Ari: Yeah, I don't use any productivity apps. I'm feeling a little left out right now. I'm very much a handwritten person. I do use a special notebook that uses a disk binding system so you can move around the pages in it. Because I'm really anal about that. It really bothers me if I didn't leave enough room, because I was going to go back to some notes. And then I have to split it into a different ... I can't, I can't. I picked up ... at Office Max, its name is Tul, T-U-L and I really like it. I don't use apps, because I retain things better by writing them down, that includes to-do things. [crosstalk 00:34:11] Cause ADHD, and my brain just, yeah. If I don't write it down, it does not stick.

Ben: How about you Chris?

Chris: I'm going to say, my favorite productivity tool is researching productivity tools. Because, ultimately what we're trying to do is just get a better sense of control in our lives when we feel just like totally out of control. That's what it's all about. We're not getting anything more done. We're just spending a bunch of time maintaining our systems. So that we feel like we're optimized. But we could just be reading a book and enjoying that in the sun instead. It does actually help you feel a lot more in control to purposefully choose the systems that you're engaging with. It can give you a better sense of control and having things outsourced into a bunch of different systems, can help you feel more piece of mind, just in your free time. And help you feel less guilty about taking free time because you can trust your systems, that there is nothing on fire, that you're forgetting about, that you should be taking care of right now. That I think is the ultimate productivity tip. To actually be able to enjoy your free time with whatever systems that you use.

Ben: All right and with that are we ready to move on to picks? Ari, lets have you start us out.

Ari: Okay, I'm actually going to throw in an additional thing I didn't plan on, just because we didn't have time to get to this. I recently discovered an app called, Mockoon. And I actually discovered it because of Marina Mosti's book. But it allows you to quickly mark out servers. Since I don't really do a whole lot of back end development anymore, it makes it really easy to just build a dummy API, like for proof of concept. Mockoon, I highly recommend it. It's super simple to use. My other pick is a show on Netflix, like always, Diagnosis. Its created by a woman who was actually a consultant on the show House. She has a weekly article in New York magazine. And she used that to start crowdsourcing diagnosis for botched cases.

Ari: I think its, I want to say it's like six episodes. It's really interesting seeing these people on their journey trying to find answers for things they have no answers to. Not everyone gets the answer they want though. I just will say that. Those are my picks.

Ben: Chris, would you like to go next?

Chris: So, my picks are a Black Mirror episode. And to get a little context, there's only one Black Mirror episode prior to this, that I've ever enjoyed. All of the rest, I found kind of silly and not very interesting. Because it's just terrible people. People are being terrible to each other, often in a way that has nothing to do with the technology that's being explored. It's [crosstalk 00:37:06] just kind of silly to me. The one that I really, really, really did enjoy is San [Janipero 00:37:12], beautiful episode. I had a friend recently tell me, "Well, if you like San Janipero, there are two other episodes you should check out. And those are "Striking Viper and hang the DJ." And I watched, Striking Viper recently and absolutely loved it, or Striking Vipers, I think. I'm really looking forward to watching the other one, "Hanging the DJ." I won't give you any spoilers, but these are not typical Black Mirror episodes.

Chris: They're actually very good. Not trying to actually find some way to be like, "Oh, how can we make this like dark or something? Wouldn't that be cool? We'd have this cool technology. People were terrible to each other, wouldn't that be weird?" [crosstalk 00:37:55] It actually explores in a more interesting way how technologies could affect our lives and relationships.

Ari: I know I've watched these, but I cannot remember for the life of me. I'm going to have to go look them up.

Chris: And my second pick is building on Elizabeth's recommendation for Notion. Notion can also be used for relationships. I use Notion for a lot of my own relationships. You can list activities that you'd like to do together, discussion topics that you'd like to get to, boundaries, agreements, communication tools that you used to better communicate with each other. And I don't mean tools as in apps. I mean tools as in strategies to figure out what people mean, when they say like, "I'd like to do X." I have a request system that is zero to four on how much people actually want it. I won't go into a lot of detail there. And also, red, yellow, green for emotional capacity, before a devoted conversation. There are a lot of great tools that could be useful to share in relationships. You never have to think of like, "Oh, lets hang out on Friday, but what do you want to do? Well, we have like a huge backlog of stuff we want to do." Organized, rated and sorted by how much time it'll take. How much physical energy it'll take.

Chris: How much emotional energy it'll take. How much each person wants to do that thing with each other, any other side notes. It's so wonderful. It makes everything easier. You can just focus more of your time on just being together and building connections.

Elizabeth: I love that. I've never thought of organizing my relationships in that way. That's actually a really good tip. Why not?

Ari: I just don't have relationships and then it's so much easier. I'm actually being pretty honest.

Chris: Yeah, you're going the more minimalist route.

Ari: Exactly. That's [crosstalk 00:39:50]

Chris: You have relationships.

Ari: ... my friendships.

Elizabeth: Speaking of minimalist, since I ruined my pick, that's my pick. [crosstalk 00:39:58] I have a backup. It is a Vue Test Utils handbook, by Lachlan Miller, who is the...or a?... I think the maintainer of Vue custody tools. It's basically a handbook that shows a whole bunch of different examples and there's ways to use the Vue test tools. That's my backup pick.

Ari: I think it's about to be helpful for me, so yeah.

Elizabeth: Cool.

Ben: And so for me to wrap things up, my fun pick for the week is a new anime I just learned about called Doctor Stone. And for those who are tired of watching bit torn of anime's with bad stream quality and stuff. The sort of adjacent pick to that is Crunchy Roll. I'm paying for the premium subscription and it's actually pretty great, because you can basically legally download the anime's for off-line viewing. You like watching anime, definitely check out Crunchy Roll. But Doctor Stone was really interesting. Basically, the premise is the entire human race has been petrified to stone. And they wake up in the stone again and they've lost all the technology and they ... It's kind of like a fun eduction. Because you learn about what they need to do to get back the technology they've lost, if we all had to start over again.

Ben: But they had the knowledge from that millennia. Anyways, it's pretty interesting. And as Elizabeth mentioned, my second pick is Notion. To build on everyone's love for Notion, I think my one thing would be is the fact the infrastructure it allows you to build is insane because of the templates and relational databases. I know that's a lot to unpack if you're not really advanced into Notion. Maybe one of these days I'll actually create a course around Notion. I've been toying with that for sometime now. Anyone have any final thoughts?

Chris: Well, I do want to mention. Ari when you are mentioning the book by Marina Mosti, were you referring to Building Forms with Vue.js by Marina Mosti?

Ari: I absolutely was.

Chris: An excellent book.

Ari: It really is an excellent book.

Ben: We'll make sure to include that in the show notes. But yeah, with that thanks everyone for joining us this week. Until next week, enjoy the Vue.

Automated Speaker: This podcast is brought to you by our friends at Linode. With 11 data centers worldwide, including their newest data center in Sydney, Australia, enterprise grade hardware, S3 compatible storage option, and their next generation network, Linode delivers the performance you expect at a price that you don't. Get started on Linode today, by going to linode.com/vue.