When (and how) to say NO

It is our favorite time in the week, it is JS Party time! I’m Jerod, your internet friend, and I’m joined by three of my internet friends, including a brand new friend. Let’s introduce her first - Amelia Wattenberger. Welcome to JS Party!

Yeah, thanks. So excited to be here!

We are excited to have you. And Nick Nisi is also here… What’s up, Nick?

Hoy-hoy!

Hoy-hoy back at you. We also have anoter Amel-, but it’s not Amelia, it’s Amal…

Amel– oh, no… [laughs]

Yeah, I can never trick you guys…

Yet another name variation butchering, but it’s all good. [laughter]

Right… This is great, because I can pull the old bait and switch. “Why don’t you answer that one, Amel…ia!

Oh, look at you. Tricky-tricky.

Amal Hussein is here. What’s up, Amal?

Hi, everybody. Happy to be here.

Always happy to have you. Now, we wanna formally introduce Amelia. She has been on the show before, but now she’s here to stay as a regular panelist, so we’re excited. We’re gonna get to know her just a little bit… But first, I wanted to make a big announcement, because I want everybody to get excited about this. I’m excited about this. If you’ve been listening to the show and you’ve been hearing our intros and outros, I’ve been teasing up our next Frontend Feud episode, in hopes that we get that survey filled out by enough people that we can actually do the episode.

I’m happy to announce that we have it all locked in at this point, September 2nd, a very special episode of Frontend Feud. It is a podcast super-collab with some of our favorite web dev podcasts. So we have Shoptalk Show vs. Syntax, live on September 2nd, with myself hosting. We’re also gonna sprinkle in some JS Party animals onto those teams. Amelia will be joining Chris Coyier and Dave Rupert on Team ShopTalk, and Divya will be joining Wes Bos and Scott Tolinski on Team Syntax. So look forward for that.

[04:21] We do have a YouTube event already in the system, so if you wanna go to that YouTube page and click on the Subscribe, or whatever the button is, get the announcement when this thing goes live… You’ll definitely wanna participate in that one live; it’s gonna be lots of fun. And I’ll include the link to the livestream in the chat, as well as in our show notes.

So a very special edition of Frontend Feud. We still would like more people to take that survey, so if you haven’t yet, help us out by being part of the listeners survey at jsparty.fm/ff. Of course, one survey participator will get a free JS Party T-shirt.

We have to get to at least 100, otherwise it’s not a good sample size, y’all, and it just breaks everything. So fill out the survey… But Amelia, don’t go fill it out, because you have to be on the show, and we wouldn’t want you having the questions beforehand.

Do go fill it out with questions I know the answers to…

[laughs] Well, you might be able to do that. You’ll definitely give team Shoptalk the upper hand. But who do y’all think is gonna actually pull out victorious? I mean, we have a couple of weeks to prepare… Who’s your bet on, Nick? Syntax or Shoptalk?

Well, I listen to both of those shows and I’m going to say that if the questions – I haven’t looked at the questions, but if they are centered around Svelte, then Team Syntax all the way. If not, if they’re centered more around – I don’t know, anything but Svelte…

jQuery… [laughter]

I was gonna say WordPress, but I don’t want that to come off as like mean… [laughter]

Right… Alright, so I wrote the questions, but I don’t remember what they are, so I can’t give you any insights. Amal, what do you think? Chris Coyier, Dave Rupert vs. Wes Bos, Scott Tolinski in Frontend Feud. You’ve played Frontend Feud, so you know how it goes down… Who’s got the upper hand?

You know, Jerod, I think much like life, this is gonna be a rigged game. [laughter] You need to play to Jerod. Jerod made the questions; you need to put yourself in Jerod’s shoes…

That’s true…

…and you need to have a “What would Jerod do?” moment. So that would be advice to the teams… And I don’t know, it could be anybody’s game. It just depends on how well they’re willing to get into your head.

That’s right. I like that.

The real winner is gonna be Jerod if any team scores.

Basically, yeah.

Well, I do have a powerful mind, so…

Yes. Your mind is a powerful weapon, Jerod. We’ve acknowledged that, and immortalized it. Thank you for that. You know, he actually literally grabbed that soundbite and put it on Twitter… I was like, “Wow, Jerod…” [laughs] Wow.

Well, it’s the first time I’ve had a compliment for a lot of time. [laughter] You’ve gotta hold tight to it.

Yeah. Take what you can get.

Alright, enough about me… But I do agree - I think if either of those two teams want a good chance at winning, they’ll probably have to kiss up to me over the next few weeks in order to have a chance at the rigged game. But enough about me. Let’s talk about Amelia. So you’re here to stay, you’re gonna be a regular panelist. We’ve had you on the show before. If you’ve been listening for a long time, you probably remember her on episode 113, which was over a year ago now. She joined Emma and I to talk about D3, to talk about the state of CSS, or JS chart that you designed… You do a lot of visualizations, you do a lot of stuff. Tell us about yourself, Amelia - where you’re coming from, where you work… All the goodies.

Yeah. I think this is actually gonna be different than the last time I was on here and said what I do, and for who… I am Amelia, I live in DC, which I also might not have the last time I was on… I moved from Upstate New York right before the pandemic, so I don’t know DC very well, but hopefully that will change soon.

[08:14] I’ve been a frontend developer at small startups, so I kind of do a whole range of things; sometimes I dabble in design, but it’s mostly web development, and I really enjoy making data visualizations. So it’s kind of a niche that I really enjoy. Oh, and right now I’m working for GitHub. It’s kind of like we’re rebranding as the innovation lab. So I work on a really small team. There’s like two teams within the innovation lab, and we basically are focused on what is the future of developer experience, and we get to do prototypes and experiments to try out different things that we think might be cool, to help developers make their lives easier.

Nice. So we should get you talking with Chris Hiller, who’s doing R&D at Sauce Labs. A lot of his stuff is very much prototypes, and trying out new ideas… It sounds like you have a pretty fun job there.

Yeah. I’ve loved it so far. I’ve been there about five months now…

Awesome. Anything you can talk about, or is it all hush-hush in pre-launch?

That’s a really good question, honestly. I’m still trying to figure that out… [laughter]

I don’t wanna get you in trouble.

You can always claim forgiveness. You can ask for permission later; ask for forgiveness now… [laughs]

That’s true.

Just kidding. We don’t wanna get you in trouble. But that does sound like a really cool job, and I have to say - and I told this to Chris as well when he shared the news about this new role… Developers are really hard customers, and it was always like a personal goal of mine to be a toolmaker for a little while. I think I kind of got a little bit of that taste while I was working at npm, but… It’s an honor to be developing for developers, because you’re upstream from people who are upstream from everyone else. So there’s kind of like a high level of scrutiny on your work, and a high kind of caliber and demand for excellence… So I think that pressure is fun, but it can be really challenging, too. It’s hard to make everybody happy. We’re still arguing over tabs versus spaces, for God’s sake. [laughter]

Yeah.

That’s funny, because Nick just shared his dotfiles repo with me the other day, because we’ve been toying around with Neovim - or I have; he’s been using it for a while… And he was showing me some stuff he was doing. And it took every ounce of control in me not to open up a pull request and change his tab stops in his vimconfig to two spaces, which is the actual correct way of doing it. I didn’t do it though, which shows I’m maturing as a human.

You’re a better man than me…

[laughs] Well, we know that, because I’ve used two spaces, which is what [unintelligible 00:10:56.16]

Yeah, for the past six months I’ve actually only been working on some really intense research around if two spaces is better than four spaces, and the scientific conclusion is that two spaces is better.

Yes!!

I’m just kidding. [laughs]

Dang it.

I’m not sure at all.

I’m really on that page.

I was really hoping you were gonna pull that paper out and show it to us.

Yeah, I was like “Wait a second, is this written down somewhere? Like, this is fantastic. There’s some actual binary evidence.”

I’m just gonna edit out… I plan on editing out the part where she says “I’m just kidding.” [laughter]

Sabotage…

Because then we have a definitive.

Right, right.

At this point, as long as you have a .prettierrc set up to convert whatever I’m writing to whatever you want it to be, then I don’t care.

That’s a good point.

Yeah. I wish Prettier could be extended to more things… Because I really do think there’s things that are just really preferences. There’s so many ways to skin a cat for any particular thing when you’re writing software… And if we could just kind of really clearly differentiate preference versus functionality, and kind of make that clear… You know, teams just need to align, and once you align, you’re not arguing in pull requests. But if we could just codify those conventions more strongly than even just linting rules, that would be really fantastic.

[12:20] You mean like beyond style guides?

Yeah. I mean like fully enforcing conventions across the board.

Like architecture?

Mm-hm. Like file locations, naming of files, function ordering, function names… Just kind of like more broadly putting a gamut on stuff.

I already dislike how many ESLint rules yell at me, and you’re talking about adding even more?

Right, yeah.

You know what - I’m looking at codebases where I don’t know who wrote the code, so…

So you don’t know who [unintelligible 00:12:51.05]

Yes. I like it when you can look at different files and it feels like one story. But hey, everybody can dream, you know?

Yeah. What if you super-deep and not allow – like, “You’re violating the Law of Demeter, or something. We follow these rules around here, so you can’t actually do that.” Now, you need some high-quality static analysis. As we talked about the last episode, static analysis tools tend to fail in human ways, so that’ll probably end up just being a thing that annoys you and then you eventually turn off, because you’re sick of those warnings. You’re like “I know I’m violating the Law of Demeter, and I want to.”

You’ve described ESLint.

Or Demeter. I don’t know how you say it.

Yeah. But I think you might be on to something here by setting a threshold. You can only introduce four new warnings in a given PR, as opposed to like a hundred… [laughs] Maybe you can pick your battles a little more [unintelligible 00:13:43.25]

Break: [13:51]

So Amelia, what brought you to Washington DC? Was it GitHub, or was it you just wanted to move, or…? Why did you decide to move?

I am actually moving within the next year as well. These are the perks of marrying someone in Academia…

Oh, okay…

But hopefully this next move will be the last move for a very long time.

Oh, I see.

We basically started in Texas, in Austin, and then we went up to Upstate New York for a while, now we’re in DC, and then we will be in Berkeley, California, hopefully for good.

Well, that’s a big move.

Yeah, I’m excited.

[15:46] Myself, up until six years ago, I lived across the street from where I went to elementary school. I could walk my kids to the same exact park that I went to when I was in elementary school… In fact, when I cut my chin open in third grade, and had someone’s tooth go in my forehead in kindergarten. That kind of stuff.

So you’ve moved quite a bit, but I haven’t fallen very far from the tree myself. Amal, you’ve moved around quite a bit…

Yeah, but – I don’t know, much like a serial monogamist, I’ve been pretty stable in my moves, in the sense that I’m in one place for a really long time… So not like constantly moving around, but yeah, I was born in New York City, moved to Dubai when I was a child, lived there for like 17 years, came back for college in the Boston area… I have lived there since, and just recently moved out of the Boston area into the Berkshires, so I’m in this magical place… Look it up. It’s pretty magical. We have lots of –

[unintelligible 00:16:45.20]

[unintelligible 00:16:46.02] but we get world-class performing arts, and just lots of music, and good food, and culture, and people are really progressive, so it’s a very magical place in that way. So yeah… But Amelia, I’m really curious about your background. So you are like this kind of intersectional developer, kind of spanning a few different areas of expertise. I’m really curious, what are some kind of nuggets that you’ve taken away from being that person that’s jumped around different subject matters, and having to kind of glue them together as like the one person that’s doing it all for your teams?

Yeah, that’s a great question… What nuggets do I know? I don’t really know… It’s funny, because I was a psych major and neuro major, so I come from pretty far afield… And I feel like that actually ties in a good amount when I’m working. Just thinking about like the user experience, and where people are coming from when they’re looking at website.

I feel like there’s not enough people who work in-between design and development, where I feel like a lot of companies are still stuck in the “You make a static mock-up, and then you hand it off to the developer, and the developer codes up a website”, and it goes down the waterfall.

I think there’s a lot of really interesting things that could happen in the browser if the designer and the developer were closer, or potentially even the same person. I feel like we just kind of like had newspapers, and now they’re websites, but it’s like – that’s a big one for me, articles of like teaching things. When you’re reading article, you could just be reading text, or what if we could make it interactive? How can we take advantage of what the web has to offer to make things more exciting, make things easier to communicate? That’s not a nugget though…

No, that’s the holy grail.

Yeah. [laughs]

I think you’ve hit on some really important points. I agree. The artificial constraints around our business processes, and our need to categorize things - they’ve created artificial boundaries, and they’re kind of stagnating our creativity in terms of what could be… So yeah, I totally agree.

What are your thoughts on improving that? For that example of getting designers and developers to work closer together and not just like throwing something over a wall to have a developer implement a design? Is it some kind of like intersection of tools, where the design tool generates code, and then that gets kind of refined by a developer, or…?

Yeah, yeah. You can see all these no-code tools coming out… I think there’s two camps right now - there’s designers and there’s developers. And I feel like the no-code tools are bringing designers into development land, where they can make things interactive, make them responsive.

[19:41] I also think it’s great when developers move more towards design land… Which can be really scary, because I think developers have seen a lot of websites, and they know what looks good and what doesn’t look good… At least this is true for me. So when you first start trying to do anything designy, you know it looks bad. You feel bad about yourself, you don’t wanna share it, and you just kind of have to do that enough times that there’s that one time where you’re like “This isn’t so bad. I’m happy to share this with people”, and then you just get better and better.

I’m a big fan of the one person who can do both things, but also just like working closely together in tools like Figma, where both designers and developers are comfortable and they’re kind of like moving things around

Yeah. I have to say, it’s a lot to ask of someone to master everything about being a good designer, and then master everything about being a good engineer, and then go do both jobs. It’s definitely a lot to ask for, and I think we’re really lucky to have people who are able to shift between both worlds… But if we’re really honest with ourselves, I think there’s still very much a T-shape. Everybody has a T, T being like you have a breadth of things that you’re good at, and then you go on and kind of have your deep areas of expertise.

I think it’s really hard to be both. Even folks who identify as whole stack, like myself… I definitely move up and down the stack, but I definitely have areas of expertise, and I wouldn’t wanna be designing a full-scale backend that needs to serve a million requests per second, or whatever. I’m happy I’m able to consult, but that’s not my area of expertise.

On the same token, QA is something I think that is being shared – I don’t know, it’s being kind of more absolved, like quality… There were specific roles for testers, and those roles are slowly disappearing at companies, because they’re pushing that ownership onto developers… So that’s another thing, building quality software or scalable software - there’s an expertise to doing that well, and it’s another skill that we’re not making a lot of space for these days intentionally.

Ira Glass of NPR’s “This American Life” has a great little quote that he talks about, which gets passed around, the taste-talent gap I think he calls it… The gap between – and Amelia, you were speaking to this, with the developer who sees good design and likes good design, and can recognize it when they see it, and can kind of/sort of do it sometimes, but not always… And there’s this void between your taste and your talent, or skill. And he’s speaking generally about creative people. We all go through this, where it’s like, I know what I want to produce, but I can’t actually. My skill can’t get me there yet, and sometimes it can take years to where you’re actually producing things that satisfy your own taste.

So I think we all get there – like you talk about, Amal, different areas of the stack… I think even if you’re more skilled on the frontend and you see a really nice database schema for example, or a nice pattern in code, and you can appreciate that and say “Yeah, that’s good.” But then when you have your blank text area or your text screen, and you’re trying to design that, then you have the gap. So we all have areas where we have the gap. So I think growing as a developer - and I’m including full-stack, every aspect of what we do in software - requires you to be filling in those gaps in the area that you are over time, and just – you have to persevere through it, because you’re not gonna be excellent at everything. But the more you can do more, then you can actually provide kind of holistic solutions, the better you are.

[23:48] That’s one of my favorite clips… And I feel like an important part of that - maybe that’s just the way I heard it - is that the gap is the painful part, but it’s also a good thing to have a gap, because you know what’s good and what’s not, whereas there are tons of things I don’t know anything about and I have no taste in, where if I tried to learn them, I wouldn’t even know if what I was producing was like a good one or a bad one.

Alright, we are [unintelligible 00:24:15.01] for a break, and we’ll be right back to talk productivity tips and tricks… What are the odds Nick brings up Vim, TypeScript, or something like this?

[laughs] Foreshadowing…

100% chance.

You know what’s funny actually, Jerod? I have a really quick thing to tie this segment in with the next segment. Are you ready for it?

Oh, goodness… Let’s hear it.

Alright. So I’m a huge fan of knowing your gaps as well, but I’ve found that – my gaps decelerate your ability to work fast, but I’m able to really quickly fill that by just knowing who I can immediately reach out to to fill those gaps. I know my experts… If I have my “Who’s good at this, who’s good at that, who do I need to talk to for this”, so the more you’re able to build out your army of people within your team or your company, that are able to help fill in your gaps, the quicker you’re able to fill that pothole and move on. So that’s a really key part, especially working in large organizations - you need to learn how to lean on other people, and also just not have an ego. Ask for help, lean, ask questions, listen more.

Yeah. Well, it’s kind of the specialized versus generalized argument, because there’s definitely a school of thought that says “Why are you trying to get better at these things that you are good at? You’re excellent at this thing, and you can take that to the expert-of-expert level and be the best you can be at this particular skill.” Maybe it’s database design. Why not just be the best database designer and don’t worry about these areas where you have gaps?

And I definitely can respect both perspectives. I think in software - and Amal, I’m not disagreeing with you at all. I think having a robust team is really the answer, and you can fill out that gap by learning from these people who are excellent at it. You’re gonna learn way faster from somebody who’s good at this, interacting with them, than just by dorking around on your own in the dark for all those years.

So yeah, a team definitely fills that out, but in terms of what we should do individually, getting better - do you specialize/do you generalize? I’ve always been a generalist, and I think that in technology specialization can work really well in your favor if you pick the right technologies to specialize in, and it can really hamstring you if you make a wrong bet. So the hedge is to generalize, and if you find a specialty that’s clearly gonna be relevant for N years, go for it. Or maybe it’ll go away and come back, like Cobol. You know, I specialized in Cobol, I was out of a job for a while, but now I’m just picking whatever.

You read my mind. You literally read my mind.

Yeah, you’re just picking your salary at this point. You could charge whatever you want.

Pay me one million dollars for this pull request. Thank you very much…

Exactly. [laughs]

Send it to my Swiss account…

Break: [27:13]

So we thought it would be fun - we’ve done this before, but it’s probably been years - to just talk productivity, because there’s lots of little takeaways you can have, tips and tricks; there’s things that you can take… If you just get one thing out of this segment, then I think it’s a win. So we have a big list of productivity tips and tricks. We probably won’t hit them all, and they don’t all have names next to them, so like who put what in… But Nick put his name in, so…

[laughs]

Let’s start with scripting.

Ooh, yeah.

Parenthesis Nick. What’s this?

Yeah, so if you’re looking to be productive – it might be an XKCD cartoon, it might not be, but there’s some meme out there that’s like “Why spend five minutes doing this when I could spend three months automating it to save me that five minutes?”

Yeah.

And that’s the general approach I take to life, for the most part. It’s being productive at being unproductive. But seriously, I think that you can get really far with just tiny improvements to your own development workflow. And I can think of just a couple right off the top of my mind… Since joining the company I’m at, one thing that’s really – we have a monorepo, and it’s really hard to run tests in the monorepo, and target very specific tests. I don’t use any fancy UI for that or anything, so I’m all command-line… And I wrote just a simple Bash script called T, and I can pass it in the test file, and it’ll just run that very specific test, but it’ll also scope code coverage down to just that one thing.

So I can run that with a watcher and just see things, hone in… And it makes me productive overall, because I’m not waiting for an entire test suite to run, I’m not thinking about how I craft the special command to only run that… I just type T and it opens up fzf, which is a fuzzy file finder for the command line, and it lets me fuzzy-find to the specific spec file that I wanna run, so I don’t even have to think about that at all. I just start typing the name.

Then it goes and it’s automatically setting up the watcher and doing everything exactly the way that I want things to work. And that’s really big. And just from there, there’s really cool tools – I live in tmux, for example; I run Vim inside of Tmux. There’s the first Vim reference of the day… [laughs]

It didn’t take long…

…and I recently just learned about display pop-up in Tmux. It’s something that I can run from within my commands to just have it hit display pop-up and it will show the command output or ask me questions in a popup window inside of Tmux, so I can quickly do that. And when combining it with other things, like fzf, I can have a very complicated UI for this command line tool that is really simple to wrap a basic script around with anything, so that I can quickly do what I wanna do, and then that is gone; it just disappears after it’s done. Or it lets me copy what I need and then go from there.

So an example of something I use for that is logging into our app with various test users and all of that. I’m lazy; I strive to be lazy, and typing in the user name and password for a user is complicated, and takes a while. I have to load the page and all of that. With this tool I can just hit a key command, it’ll bring up a display pop-up window in Tmux, it will let me fuzzy-complete the email address of the user I want to log in as, and then I push a button and it will make a request, log me in itself, and it will just deliver back the jwt that I can then just paste into my local storage, and off to the races I go, without having to log in at all.

Oh, nice.

So just little, tiny hacks to make me faster and not have to jump through a lot of minutiae when I wanna change things around. Because I have to jump through a lot of minutiae anyway.

[32:12] Yeah. First of all, I’ve never seen Nick Nisi so excited, so hallelujah, amen. [laughter] Praise the tmux and whatever lords…

[laughs]

Speaking of tmux - I can never, ever figure out how to get out of my tmux session safely. I’m always paranoid about killing it… So that’s annoying, but anyways. But no, what you’ve just described, Nick - there’s actually another kind of hack that people use to do something very similar. It’s actually using your end-to-end test runner; so you actually write your end-to-end tests while you’re – like using Cypress, for example, while you’re actually developing a new feature. You start writing the tests for it, and then putting that test file on watch and being able to continuously run that and get to that point, so by the time you’re done you have your feature, and then you have your end-to-end test. But your [unintelligible 00:33:01.24] is there to kind of keep updating the UI and getting to that state, and you use a robot that moves really fast, so you’re not having to click around… So that’s another hack.

I can’t say that I’ve ever done that, but I really like the idea of it.

Yeah, it’s cool.

I should try it.

Yeah, it’s pretty neat. But I think logging in - and we’ve done this for our end-to-end tests, where you just do the programmatic login, where you get the token and you’re able to reuse that for different tests as well, so you just by-pass the whole login process and speed up your tests… But yeah, anyways… I’ll stop talking now.

I think scripting automation is probably the number one way that programmers feel like they have superpowers. Even if you do the backwards thing and you’ve spent hundreds of hours on this thing that takes you 30 seconds a day, there is the feeling of satisfaction that’s actually irreplaceable. That is worth all that extra time, isn’t it, Nick? …just because, like you said, Amal, the joy on this man’s face right here and his voice…

Oh, my God. My goodness.

[laughs]

He loves doing this. It’s so cool! Anytime you have something annoying and you can, by your own skill or ingenuity or whatever it is, get rid of that thing and automate it, it just feels so good.

Yeah. I don’t think we talk enough about Bash. Not that you need to use Bash for every single automation, but like–

Don’t bash on it.

…it is a really good skill to put in your toolbelt, because it will serve you for life, much like Git. It’s something that’s really foundational to operating systems, and our OS’es. So yeah, learn it once, use it always. It’ll really make your life a lot better, I promise.

I think unfortunately I use it rarely enough that it’s like learn it once every few months, but…

Oh, yeah. That’s most people.

Yeah. It’s horrible.

But it does get easier, yeah.

But I think that tools like other languages that make it easier to write scripts are starting to become more prevalent. I think a lot of command line tools are written in Go because you can then compile that and have that executable and you don’t have to worry about if somebody has Go on their machine to be able to run it… And you can do the same thing with JavaScript or TypeScript and Deno. You can compile that down and then pass that around and it’s a really nice and easy way to write in a more comfortable language and not worry about all of these dependencies, like the difficulties of running it for whoever you might be sharing that script with.

But I do think that that’s one thing that we kind of take for granted as professional software developers - we just write code every day, and it’s just what we’re accustomed to. But if you were writing scripts like this in a non-coding job, and automating pieces of your job away, it would feel like a complete super-power, and we should just remember that.

Yeah.

[35:56] It’s funny you say that, because we’ve just had a fellow write in… We’ve just published on The Changelog an episode all about Vim, and we’ve got a lot of feedback about people who use Vim and love Vim… And he is a trial lawyer, and he wrote in on that episode how he’s been using Vim since the ’90s. Actually, Vi before it was Vim… Since the ‘90s. And he’s using Unix tools, like the ctags stuff, and sed and awk, and it’s all text-based… And he uses it in his lawyering work, and he’s literally – I actually asked him back, I’m like “Is there anybody else? Do you have like a club? What’s the cross-section of lawyers who also use Unix tools?” And he said it’s one person, it’s just him. But because he’s that way, he has superpowers. And he handles things that take other people hours and days, especially because a lot of law is just text manipulation, and collating, and extraction… So he has these skills and he’s been doing it for years and years, and he says he can’t even count how many hours he saved over his career because he has these skills.

Yeah. Well, Amelia, to your point about learning Bash every few months, or relearning it - I do think we need to build up an arsenal of commands and scripts, and like “This is how I did this. This is how I solved that problem.” Just kind of build that for yourself, so you can just keep that as your own reference log… I mean, that’s why people blog; a lot of folks blog, just to kind of remind themselves of how they did it. You don’t need to make a blog, but just make a repo, and have it be your notes, and have that be something that you’re able to carry with you from job to job, and it’s your own arsenal of how you did a thing… Obviously, don’t steal company secrets, but… You know, most of the time there’s nothing really secretive about how to write this kind of a regex, or script this thing… There’s usually no company secrets there. But I would highly recommend that.

Yeah. Another thing on this list of productivity tips and tricks is pomodoro timers. Who’s using pomodoro up in here? Is that you, Amelia?

I added that… [laughter]

But you’re not a user.

…but I don’t currently use them. No, I do sometimes, and I used to do it a lot. The concept is basically just work in sprints…

Right.

Often you’ll set a timer for 25 minutes, and basically you can’t do anything except work. I don’t think you actually have to work, but you can’t do anything else. So you have to sit there, and eventually you’ll probably get bored enough that you’ll get some work then…

And you’ll start working, yeah.

Yeah. And then once the timer is done, you have 5 or 10 minutes to do anything but work. It just kind of forces you to sit down and either work or don’t work, and kind of treat it as like – you’re not like multi-tasking, reading Twitter at the same time as you’re coding. I’ve done it, it’s really nice.

It’s a discipline practice.

Yeah, exactly.

I was gonna say, it kind of ties into the hot new buzzword in productivity circles lately, and that’s time-boxing, and it’s really just planning out your day fully. That can be in the style of pomodoro, but just accounting for every minute of the day, so that you are maximizing what you can do when you take breaks, and overall just feeling good about the work you’re getting done because you planned to get it done at that time.

Yeah.

I’ve tried pomodoro years ago and it just didn’t click for me, because for me it takes a while to get into a state of flow - about 25 minutes - and then if I’m gonna take a five-minute break, my context is gone, and then I’m back, and I’ve gotta get it back, it takes 5 or 10 minutes… So I like to get into a state of productivity, kind of make-your-schedule/manage-your-schedule thing, like get the maker schedule going… Give me four hours uninterrupted… And I’ll take an hour off, I don’t even care. Because if I can go 3-4 hours without stopping at all, that’s where I feel the most productive. Because the first 10, 15, 20 minutes is wasted on remembering what I was doing, and trying to figure it out… And then [unintelligible 00:40:02.08]

[40:04] So I tried pomodoro, it didn’t really click with me… I know people that use it and swear by it, and they say they’re just so much more productive with this 25 on/5 off cadence… But I think the key is the discipline; it provides a structure for discipline for your work, so you’re not just dorking around, which we tend to do when we don’t have discipline.

I’m with you, Jerod. That’s for me really the maker’s hours thing. If I’m implementing a task and I need to have hands-on keyboard time, I just need my uninterrupted time… And I’m in flow state for a few hours, and I get it done. But breaking that up over multiple days - it’s really frustrating and not productive. I need large time chunks to get there, and it takes me about almost an hour to really get into a good flow state, too. Slow warm-up…

Yeah. Around flow state, I do have a blog post I wrote back in 2011 - holy cow, I’m getting old - all about how to retain your dev flow. This is between sessions. Because what I’ve found is that context ramp-up can really be a killer. And maybe it’s over the lunch hour, but usually it’s the day-by-day. So you finish at the end of the day, you start up the next day; and there’s certain little tricks that you can do to jump-start that, to get your context back quicker, and get you back in the flow faster. So there’s three things that I advise in that post, which - I continue to use one of these pretty much non-stop, we’re talking a decade later.

The first one - just leave yourself notes. Like, “What was I working on?” You’re trying to get back to where you were. Leave yourself notes saying what you’re up to. That’s the most obvious thing that people do.

It’s too much work for me… You know, at the end of my day, I’m ready to leave; I don’t wanna write myself notes from the past. So I just can’t really see that as a sustainable way, but it’s definitely a way of getting back.

The other one that I do sometimes, depending on what I’m up to, is leave failing tests. So like the last thing you do at the end of your day is to write a test that fails… Even if you have a test that’s passing, maybe just make it fail real quick, and then leave it there… Because then when you come back, the first thing you do is you run your test suite, and you see the failing test, and for some reason everything kind of rushes back in, like “Oh yeah, this is exactly where I was”, and you can kind of like jump back to that spot in your brain. But even that’s too much work for me. So what I end up doing – you know, I used to do all these things, but now a decade later all I do is this third technique, which is to leave some unstaged changes in your Git branch, whatever you’re doing. Specifically, I’m not gonna stage these, I’m not gonna commit this, I’m gonna leave it right here, and when I get back, I’m gonna see exactly what I had edited, but not committed. For me, that’s a great way to get back in the flow faster than having to start fresh and think about what I was doing yesterday.

Have any of you tried any of those techniques, or do you do anything to get back to where you were more quickly?

That last one is – I basically do that every day, because it’s just so quick to be like “Okay, this is what I was doing.” And then the other thing I do that’s kind of related is there will often be things that come up, like little tests where I’m like, “Oh, I just need to get this done” at the end of the day, and my instinct is to just bang them out, like “Oh, I’m gonna lose all this context. I’ll just get it done”, and then I’m working till like 6:30.

What I’ve been trying to do is – like, if I stop, having that small task to do in the morning I find is just exactly what I need to get in the groove again and then tackle the bigger tests a little bit later.

Yeah, I do something very similar. I really like having some – not starting from a blank slate in the mornings. So I will try and stop whenever I can for that. And just the way my schedule works out right now - I have to go pick up my kids, so as soon as the end of the day is here, I’m yabba-dabba-dooing it out like Fred Flintstone sliding down the dinosaur tail.

[laughs]

[44:00] I really try and actually get to a stopping point a half hour earlier than that, and then I have a checklist that I try and go through, of “Process this inbox. Go through my email and see if there’s anything to add to my inbox. Go through the to-do’s that I have accumulated throughout the day and try and flag priorities that I need to get done by tomorrow, or during the day tomorrow at some point”, so that when I come in I’m not just like “What do I do? Where do I go from here?” I just have a set list of “Finish what I was working on, respond to this email, go help this person with this problem they’re having” and just go from there.

I don’t always succeed at that, but it’s something that I really try and set myself up for successfully, and it sometimes works.

Yeah. Unfortunately, I have a combination of that. I have this rolling to-do list that I’m constantly looking at, and checking off, and moving things up and down… But I can’t leave the little things for the next day, because they just fall off of my important – my brain is very into problems, so the little problems aren’t always as exciting as the big ones… And I am somebody who, because of my job, I just have multiple things going on at any given time, so if I don’t finish the thing then and there, I will forget about it and I’ll come back to it like a week later, because it’s just falling off… Like, “Oh, great! I solved the puzzle.” So I’m notorious for having the longest pull requests… It’s like, “Amal, this pull request looks like it’s done. Do you wanna merge it?” I’m like, “Ohh, yeah, I just need to fix this end-to-end test”, but that’s not the exciting part, you know what I mean? So I don’t care. So that’s like a me problem.

But yeah, once I’ve solved the puzzle, that’s it. I’m less interested in all of the other mechanics of it. So if I take a break and come back to it the next day, it’s not gonna happen as fast, so I just need to get it all in and just roll it over the fence.

I can relate to that…

Yeah, seriously. And the best thing, that’s been saving my butt a lot lately, is GitHub’s new Automerge feature. So it’s like, as long as your CI is green, you get all the pull requests, you’re good to go - you just hit that button and you don’t have to come back to it, so you don’t have to baby your pull requests anymore. That’s been a huge boost to my personal productivity lately, just in being able to get things over the fence faster. Because I’m constantly context-switching, and so it just goes into my rotation and “I’ll get back to it in a few days…” But again, that’s a me problem.

So let’s do one more here… I like this one quite a bit; it’s not what you would normally think of, but it says “Knowing when to say no.”

Yeah, that’s a really big one for me.

That seems like a big one.

Yeah… This is just like general life advice. Especially last year during quarantine, it was just like “Oh, well I’m not leaving the house anyway. Why would I say no to literally anything?” And then you’re overwhelmed with a million contract projects, or like you said yes to some side project, and then you have like five to do in one day, and it’s Saturday, and even though you’re not leaving the house, it’s not restful…

I think my new rule there is 1) say no to most things, but also 2) there’s like an inherent cost in any project, no matter how small it is, because you have to get your mind in the right mindset, and think about everything around the problem… So that was a really big one for me to learn. I’m still learning.

There’s a great quote, I think it’s by Derek Sivers, I have the book right here. “Hell Yeah, or No.”

Yes.

If it’s not a Hell Yes, then it’s a No. That’s something that I constantly have to think about. Because sometimes it can be flattering to say yes to something, and you want to do that and see what opportunities might come out of it, even though it might not be… But in the end, it can become too much. It all depends. But that’s generally good advice.

[48:07] I like that.

Yeah, that’s one that I follow as well. And in fact – it’s tough, because you look at every opportunity as such a blessing, or such a cool, interesting… Like, you wanna do all the things, right? So it’s kind of like “Yes…”, but is it “Hell yes”? And you get to a certain point when the opportunities – I mean, some people are in a phase of life where there aren’t very many opportunities. Then it’s just kind of like - well, go ahead and take the ones that come to you. But as you move on and advance, and find opportunity, and it finds you, over time, you get to a point where you get a lot of them. And then the problem changes to which ones to select and which ones not to select. And in that case - yeah, I ask myself that question all the time. “Do I really want this? Is this an obvious thing that gets me super-excited?” Or I just kind of feel like it could be good, or it’s kind of like an obligation… You feel bad to say no; saying no reminds me of that Tommy Boy quote… Remember Tommy Boy’s dad was really good at selling stuff? Have you seen that movie, Amelia, Tommy Boy?

I have not.

Chris Farley. It’s a classic. You need to put that on your list. Say yes to watching that movie…

[laughs]

See, I just assigned you homework. Welcome to JS Party, where I assign people to do things… No, you definitely wanna see that movie, because Tommy Boy’s dad was a great salesmen, and one of his lines is – he’s selling this rotary [unintelligible 00:49:29.24] or I don’t know what he’s selling… And he tells the guy “Why say no when it feels so good to say yes?” And the guy, of course, buys the thing. He sells him.

[unintelligible 00:49:41.18]

But isn’t that kind of like how it is? It feels good to say yes… But does it make it the right choice?

You know, Jerod, I got advice from someone on this exact problem, a technique that they use… When you’re evaluating opportunities, you always wanna say yes to everything, but a metric that you can use to weed out the ones that are maybe less ideal for you, or if you had to do this tomorrow, would you say yes? Would you do this tomorrow if you had to do it? Would you make time in your schedule to do this tomorrow? Is this something that you’d be excited about doing? That’s a good way to weed out if you’re saying yes because you don’t wanna hurt the other person’s feelings, or because you feel obligated…

Right. Maybe a second part of this tip, since we all have had some experience with this, is how do you go about saying no? Because some of it is like, that’s the social awkwardness, or the anxiety about that interaction, letting somebody down, or turning somebody now… It never feels good, like the quote says, but are there ways that you’ve gone about saying no that have worked better than others, or how do you do it?

I’ll tell you the way that I use the most, which is by far not the best way, but it’s the most effective way sometimes… And that’s - I ignore it until it goes away on its own. [laughter]

So the ghost no… Okay. I mean, that is, I think – in certain cold requests… I mean, we do that all the time. We get so much email for The Changelog; people wanna come on the shows… I’m not gonna respond to every single email and say no.

Oh, is that why you’ve been ignoring all my emails? [laughter] Gosh, Jerod, I thought it was like –

The truth comes out.

Gosh, now I know…

I don’t know how to break this to you, Amal, but you’re on the show right now.

Anyways… No, no, I’m just kidding.

[laughs] Anyway. So in that case, a cold email - you don’t know the person, they’re asking for something… I’m totally fine with not responding, because there’s just too many emails in life. But what if it’s like a colleague, or a friend? You’re not gonna ghost a colleague if they ask you for something, right? You’re gonna have to tell them something. Amelia, what about you? How do you say no?

I’ve been waiting to hear answers on this… [laughter] I need all the help I can get.

Out of office message saying you’re in Alaska for three months… [laughter] And hoping that they forget about it by the time you’re “back.” [laughs]

I have a built-in excuse. I just say –

Kids…

…I have kids and I can’t do it.

Yeah, that’s a good reason to have kids.

Yeah, kids are a great excuse. It is.

[52:14] Yeah. I never wanna lie about it, and my reason is always like “This isn’t a priority for me” or “I don’t think that sounds great”, which I’ve tried before…

“I don’t think that sounds great…” [laughs] Yeah, it’s honest.

It’s just like, this isn’t – I don’t want to. You hate when you ask someone to do something and they lie about like “Oh, no, I can’t do that, because I’m not available” and you’re like “I didn’t say when…” [laughter] That never feels good.

Yeah…

They’re like “I have bowling league that night” and you’re like “Yeah, I didn’t give a date yet.”

Yeah.

Honestly, a line that I’ve been able to use pretty successfully so far is that I just have too many commitments right now, and my plate’s really full, and I would love to…

Yeah. That’s true, right?

It’s the truth though… I just can’t take anything else on right now. And it’s always nice to give people another option, so like if you can redirect them to someone else, like if you’re being asked to do a talk, or whatever… Just say, “Hey, maybe this person can help” and then just – I think that’s the most you can do. But yeah, you need to be protective of your time and energy, and most of the time people are understanding, so…

Right.

I do like that approach though, Amal, because it really shows that you did consider it, and you put a little bit of thought into it, which is – it’s not just like a canned no response in that regard. And even – I’m thinking back to maybe what you said, Amelia… Like, if you were brutally honest, like “No, that doesn’t sound good to me”, that would probably stand out as a significant response that they might get for something like that, and it might lead to collaborating or changing it to be exactly what you want, and that could be good, too.

Yeah, totally.

So I like the honesty of “Too busy, too many things going on.” One thing that happens with that with a persistent requester is they will then set a reminder to ask you again in a month, or 60 days… And that can be problematic. So now you’ve gotta do it again… So at times I will say – it’s similar to what Amelia says, but I’ll say something like “This just doesn’t feel like a great fit” or “It doesn’t feel right.”

That’s good.

It just doesn’t feel right.

It’s not you, it’s me.

And it’s really hard – I mean, it’s not really offensive. It’s not saying it’s a bad idea…

It’s not you, it’s me… You know? It’s like a break-up. [laughs]

Yeah, exactly. Yeah. Anyway, so it doesn’t feel right. I’ve never gotten someone to write back and be like “How dare you?!” Of course, maybe they’re thinking that, but they’re like “Oh, okay. I appreciate the time.”

Yeah. That’s great, because it’s not like “This isn’t good, objectively.” It’s like “It’s not good for me.”

Yeah. It just doesn’t feel right. It doesn’t feel like a great fit.

Yeah. Can I put someone on blast? Well, I’m not gonna put someone, I’ll put an organization on blast…

Maybe…

[54:53] There’s a particular Facebook recruiter whose last email to me was literally (I kid you not) like “Okay, Amal, so I know we’ve reached out to you like 50 times… Here’s hoping that number 51 will be successful. Blah-blah-blah-blah…” I’m like, “Oh, my God. What part of not responding to your emails, like “Not interested”, do you not understand?” Persistence can hurt you, so don’t be that person.

Yeah. So for the person who just cold-emails you five, six, seven times in a row without a response, I have a text expander for them, which is an all-caps “UNSUBSCRIBE”. And I just reply with that.

That’s smart.

Yeah. It’s like, “No, I don’t wanna hear from you anymore.”

Yeah. Well, Jerod, I don’t know if we’re gonna have time to get to this, but we’ll maybe put a link to the show notes, but for me, urgency/importance matrix has changed my life these past few months. I’ve started to adopt that, and I got some really good coaching on this from my boss, because there’s so many things we can do, also so many things that I want to do, and a lot of people and engineering leadership roles have a very hard time delegating, because they know they can do the work better than anyone else, or they have a particular way that they wanna implement this. And I’m talking to myself here… But sometimes it’s like, you need to really learn how to delegate, and what to delegate… And yeah, it might get done differently or slower, but it’s fine… Because it frees you up to do other stuff. But yeah, knowing what you can do first, do later, eliminate, delegate - it’s been a game-changer for me.

Right on. Well, we’ve been having too much fun, because we are way over time. We’re gonna have to just delay our brand new third segment, which was either gonna be called Awesome Hrefs, or Stumbled Upon, or Linkapalooza, which now that I say it out loud is the worst name I’ve ever heard… But we’re not gonna do it, so who cares what it was gonna be called…? We’ll save that for the next time that we do segments.

This has been an awesome conversation, I really enjoyed it. All the links to all the things are in the show notes, including Amal’s urgency/importance matrix… So if you just got a taste of what that is and you wanna dive into it, definitely click through and check that one out.

One last reminder - please do take the Frontend Feud survey, so we have lots of awesome responses, otherwise I’ll have to have Nick write a Bash script that goes and takes the survey for us, and just fills in fake information. And I’ll do it… Don’t make me do it.

[whispering] Vim… Tmux…

That’s at jsparty.fm/ff. Nick, Amal, Amelia - thanks so much for hanging out with us today at JS Party. Any final words before we throw that outro song?

Welcome, Amelia! We’re excited to have you.

Welcome, Amelia!

Thank you, thank you.

We are happy to have you.

We are representing the AM crew.

The morning people.

Yes.

Yeah. Alright, that’s JS Party for this week. We will talk to you next time.