Mandy MooreRelicans host Ali Diamond talks to Senior Developer at Kyruus, Autumn Crossan, about encouraging and helping developers to get started and achieve their full potential by enabling them to do cool stuff they want to do, making business's workforce work better, and doing code reviews + giving helpful feedback.
Should you find a burning need to share your thoughts or rants about the show, please spray them at devrel@newrelic.com. While you're going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you'd like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @PolyglotShow.
Jonan Scheffler: Hello and welcome to Polyglot, proudly brought to you by New Relic's developer relations team, The Relicans. Polyglot is about software design. It's about looking beyond languages to the patterns and methods that we as developers use to do our best work. You can join us every week to hear from developers who have stories to share about what has worked for them and may have some opinions about how best to write quality software. We may not always agree, but we are certainly going to have fun, and we will always do our best to level up together. You can find the show notes for this episode and all of The Relicans podcasts on developer.newrelic.com/podcasts. Thank you so much for joining us. Enjoy the show.
Ali Diamond: Hi, everyone. Welcome back to the Polyglot Podcast. This is Ali talking. I am a Senior Developer Relations Engineer here at New Relic. You can find me everywhere on the internet including Minecraft at endingwithali. And today with me I'll be talking to Autumn Crossan. And normally, I love to get the guests to introduce themselves because there's no one who can tell their story better than themselves. So, who are you?
Autumn Crossan: Hello. My name is Autumn. I am a Senior frontend-y person, mostly at a company called Kyruus. We make some cool med-tech stuff. In the past, I've done some agency work. I've done some food tech work. I've done some this and that. I've been jumping around for the past little while. I'm also currently sitting here, coming to you from a room that is just full of musical instruments. So we were just talking about it. And I'm looking at it in the video preview thing, and I'm kind of like, yeah, there are lots, huh. I don't know.
Ali: So this is a podcast. So for the people who are just listening, in the background, I see 1, 2, 3, 4, 5, 6 guitars, the banjo on the side, drum sets, a full keyboard.
Autumn: Yeah, it's a lot. [laughs]
Ali: This is a full studio.
Autumn: It's a good time.
Ali: You could rent it out, and people can come make their own music in there.
Autumn: [laughs]
Ali: It's fully stocked. I can tell.
Autumn: I have considered this. If I ever needed some side income, I guess from programming; I don't know. [laughs]
Ali: I don't know. But you kind of said it yourself: you do frontend-y things. And before we started recording, you talked about some of the responsibilities that you like to take on and encourage, and that involves helping developers get started, achieve their full potential. And I was wondering if you could dig into that a little bit more.
Autumn: Yeah, totally. The work that I am the happiest doing, just, generally speaking, is enabling other people to do the cool stuff they want to do. I currently have two members of my team who are no longer new, but they're still the newest on the team. And so, when they started, we had a specific program basically to mentor these folks in an actual formal capacity. And I mentored these two folks in an actual formal capacity and spent a lot of time. I had to tell the team a few sprints ago I'm not going to be doing feature work for a bit because our Jenkins stuff is broken, and I need to go fix that.
I'm currently on a different team and helping out with code there, as well as people stuff there, as well as helping out with people stuff on the original team. I like to be the glue, as we were talking about before. I like my main value at work to not be the lines of code that I'm writing, but the help and the assistance that I'm rendering to other people on the team who are writing those lines of code and who are actually shipping that cool stuff if that makes sense.
Ali: Yeah. And we were actually talking about this article I brought up earlier called Being the Glue by Tanya Riley. And if you want to go check it out, it's noidea.dog/glue. And it's a really, really fantastic blog post talking about being catty-cornered into the role and taking on the responsibilities of making the team function better, and realizing that that person isn't getting the moving forward in the technical aspect that they're hoping for, and eventually getting stuck in that non-technical role as a technical person because no one else is willing to take it on. But that's, as you've said, where you thrive.
Autumn: Yup.
Ali: And as you go through your job, these are the roles and the jobs that you like to take on. So do you want to dig in more about how you make developers' lives even better? What would you call this?
Autumn: I don't have a really good name for this, honestly. I'm struggling to even describe it in ways that are cohesive at all. In my experience, the sorts of things that I'm interested in doing winds up involving a lot of certainly more people work than tech work. There's a lot more mentoring. There's a lot more meeting with people about the current state of things. And in my case, it was lots of discovery of tech debt. I work on a very old med-tech application. And we have quite a bit of tech debt, including something like 60% of our codebase is still in CoffeeScript, so it's old.
Ali: Oh my God.
Autumn: And it's a lot. And we're digging through this and trying to figure out what would make these developers happier in this codebase that we can actually just go do? Where are the easy lifts for developer experience? So some of it is that. Some of it is going and talking to folks about things that are bothering them. The other half is fielding requests from people in the moment.
I think of myself as like one of the company routers sometimes because somebody will say, "Hey, I need help with some specific detail of our very old app. And I'll say, "I don't know this thing, but I do know who to talk to. Go talk to JP or go talk to somebody else over here. Go talk to Bryce, who worked on this app forever." And I wind up doing lots of that kind of routing of stuff.
I also wind up doing lots of code review, a lot more than I ever did when I was not a 'senior developer' quote, unquote. I'm reading people's code. I'm giving feedback. I'm following up on that feedback. Basically, I'm applying the skillset of a developer to a more people-focused focus, if that makes sense. I'm not primarily concerned as much with making this business money with code. I'm concerned with making this business's workforce work better here, if that makes any sense.
Ali: That makes total sense. One of the things I'm super curious to talk about is even though you aren't writing code, how do you feel like your past experiences have brought you to this point where you feel confident enough to be able to review people's code? Because I think that a lot of companies sometimes people are like, "Oh, I don't feel like I know how to code well enough to do code reviews." Or like, "I don't know what I'm doing. Why would I know what someone else is doing? "And then it's always such a struggle to get people to do code reviews. Let's talk about code reviews more.
Autumn: Yeah, extremely. So I started...this is the first job that I've had that I've really been able to do this kind of work, at served on…like, above the table or whatever. I've basically been a full-stack developer to this point in my career. And I've kind of been shipping front and back-end code like DevOps-y stuff more recently and all that kind of stuff. So I do have the basics of stuff down, obviously. I certainly have my own opinions. And I think at this point, I know when to hold to my opinions and when to be like, this is actually probably fine. There's that judgment you have to make up, like, is this thing that I'm going to request them to change just a thing that I would have done, or is there a really good reason to request?
I guess part of it was just writing lots of code, reviewing lots of other people's code while I was doing more IC work, more like individual stuff. And to this point, I would not call myself an SME on this application by my standards. But I certainly I'm the person on the team who has the most subject matter experience about this application. It's nice to have on the ground code view and the 30,000-foot in the air like, here is the shape of this repo and where this app is going in the future, and the general shape of it, if that makes any sense. So I think between those two things, I got it covered.
But without having all that experience, I might feel differently actually. I might not have a ton of confidence in the specific nitty-gritties of code review, at which point I think I would just find someone who...I don't want to say outsource that requirement or anything but just find someone on the team who does know it and who does have the bandwidth to commit to doing all that stuff and check in with them as needed if that makes any sense.
Ali: That makes total sense. And I should ask, given that you say that...and out of context, I don't mean to be hovering on code review, but I love asking these kinds of questions. But I would love to know what are some of the most common errors you see when you're doing code review and what should people keep in mind when they're writing their code?
Autumn: Like I said, we have some...they’re not juniors on the team, but they are the most junior on the team. It's such a weird place to be as a developer. So I see lots of code from folks who have only been at this for a few years. I see lots of code from folks who've been at this for 5, 10, 15 years. And so, I guess there are a couple of broad classes of things. There's the class that is doing more work than you have to. So the most common one that I see of this is not typing .map and instead making a new array and iterating over a collection to add things to the array and returning the array, that sort of stuff.
There's the stuff that is not terribly extensible, like to do design pattern stuff that would violate the open-closed principle and all that stuff wherein I know that we're going to have to apply a theme like a dictionary to this component somehow, so I'm going to build an in. If I just didn't build a junction for that there, that would be a dig in code review. I see lots of stuff like just broadly not being terribly conscious or cognizant of the ways in which this thing will age over time. Again, one of the things that working on a legacy application has been teaching me is the decisions that you're making today should probably be intelligible in six years because that's how long this is sticking around. So it's just like using that as a guiding principle. You kind of see a bunch of different facets of that coming out in code review, I guess.
Ali: And you said this yourself that beyond just code review, you do a lot of different things at the company. And doing a lot of different things requires a lot of different switching and time management. How do you most effectively swap between your different projects, your different roles, and different tasks?
Autumn: The thing that specifically works for my brain...and this is where your mileage may vary. I am a person who has the kind of ADHD that is just kind of irritating all the time. And you constantly have to be accounting for it, and you constantly have to be finding ways to mitigate things. So I have embraced context switching broadly. I do it all the time. I do it probably hundreds of times per day on a busy day.
I basically try to conceive of all of the different contexts that I need to switch into and out of, kind of like rooms as rooms in my house. Like, if I'm up here, I can play the guitar, or I can play the piano, or I can do whatever else, music stuff. If I'm down in the kitchen, I can cook a meal. If I'm in the living room, I can read a book. Being able to section off chunks of work into cohesive, again, I'm going to call them rooms because they kind of feel like rooms to me, into like sort of cohesive little rooms that I can be like, oh, okay, someone messaged me about a DevOps thing I have to go fix. Let's go to the infrastructure and knowledge room. And we'll write code in the infrastructure and knowledge room until someone comes and asks us to do an HR survey that just got posted in the Company's Slack channel or whatever. Okay, let's go to the worker bee room and go do that.
And in my experience, being able to know where you are in that space and switch between those spaces either at will or with low friction, I guess maybe I want to say, has been the most helpful thing for me in terms of combating ADHD on days when I don't have whatever internal willpower it is that controls ADHD. I'm doing that regardless, so why not just make that a way of life? And then if something comes up, something comes up, and I have to jump out of it. But at least I can have that pattern and have that kind of structure.
Ali: I'm super curious. So context switching, one of the more painful parts of context switching, is ripping someone out of deep work and getting them back into deep work. And so, this is me coming from a point of selfishness.
Autumn: [laughs]
Ali: I love to hear actionable advice. What is some of your most actionable advice for getting quickly and effectively getting into a deep work-study state and to not let that be a distractor when you have to step out of it?
Autumn: Yeah, totally. So I noticed as I'm doing all this stuff, more tasks than I think I realized require an amount of knowledge or information loaded into your brain as if it were like RAM in a computer is kind of my go-to metaphor for this. So if I'm writing code, not only do I need to know what the codebase is like, but I also need to know what I'm hoping to accomplish with this pull request. I also then need to know the stuff that is in the way, the stuff that has already been changed, the stuff that I think will change, et cetera, having all of these variables in my brain.
And I didn't realize that that was such an amount of overhead before I had started to pay attention, I guess I'll say. Every task has its own set of that. Every task has its own stuff that you have to think about before and after and all of this sort of mental baggage that comes along with it. And honestly, a lot of my coping skills for this are finding ways to externalize all of that state. If I'm stopping writing code for any length of time to do an administrative thing or go and talk to somebody on Slack, I always write a to-do comment. It is the very last thing that I do before I close the laptop or go open Slack or something.
If I'm working on a ticket and I have, oh, I have to tell my manager about this one particular weird thing that's going to impact scope, the last thing that I do before I get out of social mode is go and type an outline of that whether it's in the Slack message box or just like an event buffer or something somewhere. I guess, in a sense, it's having a wider view of all of the stuff that needs to get done over the course of your day and figuring out which buckets those fall into and how you can optimize for future you to do a little bit less of that context switching. Because if you can consolidate stuff better, it can result in, not always, but it can result in fewer switches and fewer of those weird impedance mismatches or stuff like what was I doing? Oh no. That I think is my perennial failure mode of like, well, what the hell? I have this stuff on my desk. What was I writing? [chuckles]
I think visibility for me is always the way to go, and having especially visibility directly on top of the task in question either in a code comment or like downstairs on my fridge, I have a million things magneted to the fridge with sticky notes on them just be like, do this with this. So just kind of finding ways to surface that stuff such that you cannot miss it when you return to the task. And you can actually get back into your brain much faster in my personal experience anyway. Your mileage may vary.
Ali: Yeah. And one of the things that you said earlier that I'm super keen on digging in more is you talked about segmenting your work and knowing what you can do where. So say someone is given a pretty vague task. How would you sit down and work with them in order to help them understand how to segment and break down that work?
Autumn: I think it's very dependent on the specific task in question. But having recently done this with an engineering task…I forget what the exact bug was. There was some kind of bug in a calendar component that we'd written. And one of the folks on my team had gotten a very vague ticket about it. And I had to sit down and talk with them through the things and like, well, okay, what do we want to be different now at the end of this? How many things does this touch? What stuff will you have to interact with? Which repos? Which other pull requests? Which chunks of the codebase? Which individuals in the organization?
I'm not always a literal mind map, but I basically make a mind map, even if it's in my mind. And then you can go from there and break things down by like, okay, well, if I have to talk to this person, talking about this task is actually blocked by doing this other task. So I need to do the task on an engineering switch that is prior to the social switch where I'll go talk to the person. It's a little bit like Pepe Silvia if you've seen It's Always Sunny. I have in my mind a palace. I guess I just have like yarn spun across every room. [laughs] I guess I'm just constantly keeping track of stuff. But if you're like me, it might work for you. I don't know if that's necessarily good advice for most people, but it seems to be okay for me.
Ali: That makes total sense. And having to deal with context switches, you talked a little bit about this mentorship. What are some of your biggest pieces of advice for people that you bring on as mentors, whether they have to do with a lot of context switches or not?
Autumn: So separate from the base mentorship advice, stuff like obviously be kind, be really curious about this person, and be available but don't be smothering, all of the kind of normal mentorship stuff. And as far as doing that while context switching, honestly, it is kind of hard mode. I've done it twice recently, and it's not the easiest thing that I have done at work recently, at least in my case. It meant I needed to sort of supercharge taking advantage of switching stuff and being really cognizant of in what brain spaces I could do which things. So I became very fastidious and very, you could say, neurotic about the ways in which my open applications were laid out on my screen.
I have a new-ish system to switch between applications with very few key presses. I have key commands set up for basically everything that I could do on my computer just to minimize the chance of going to do a task and then suddenly an attention switch. Or suddenly, something gets in the way and totally wrecks your train of thought. If I can press Command-S or right Command-S and just go back to Slack and then be right there to take the message, it's so much easier. So it's finding small environmental hacks that work for you that way.
I've seen people on Slack that I've been a part of who have...I think they're using Windows machines, and they've locked down specific applications at specific times. And I know that if I'm in a work headspace before 11:00 a.m. and I can open up Discord or Slack or something, it's going to go away. So it's just like, kill that completely. So that kind of finding stuff that works for you and finding stuff that will minimize that friction to get back into things as you come back or as you leave from specific tasks. But yeah, doing it while mentoring is hard. [laughs] Kudos to folks who are having to do that now because it's not fun.
Ali: Yeah. And I want to delve a little bit more into...you kind of touched on this. So you have a lot of things optimized to help you with your context switching. What are some of your favorite productivity tools that you use on a regular basis?
Autumn: This is good. This is nice. So I use at the moment two different to-do list apps. I use both things. I'm on the iOS space and Todoist, which is cross-platform. I also have that application switching thing that I was talking about, which is scripted in Lua using a tool called Hammerspoon, which is just like macOS-specific: here is a whole ton of system calls and stuff that you could just like run from low code. That's really nice.
I have a bunch of stuff in my vimrc, A, to make it, so I don't have to like putz with aligning parentheses and stuff like that, and B, to open up a new buffer really easily and get something out into a to-do list and keep it around someplace. I have commands to do that for when I guess I’m feeling like David Allen. I read Getting Things Done a year ago or so. It has informed lots of my office and work-life, and one of the things in it is constantly have some way to capture whatever you're thinking at the time. So if you need to come back to something, make sure you can write it down first. Again, I don't really use lots of discrete tools. You could say I use Obsidian, the Markdown thing, to take notes, and I do. But it's not wired into my brain in the same way as the key commands, and all the Vim stuff is.
So yeah, it's just like one of the important things that I have learned or one of the things that I have learned that is important to software engineering is ingenuity and creativity with the tools that you have. And if you can apply that on a meta-level to your environment and to the ways that you're doing your work, I think you're only ever going to have lots and lots of success doing that if you approach it earnestly like, what will I actually use? Which things am I missing? How can I write code to better my own life, basically?
Ali: Yeah. And as we approach the end of our conversation, do you have any tips that you'd love to share with the world? Just anything you want to get off your chest to just tell everyone about.
Autumn: I guess the one that I'll go for is pick up an instrument, maybe. [laughs] The same parts of my brain that are activated when I'm playing music are a lot of the same parts of my brain that are activated when I'm being creative and finding solutions to problems, whether that'd be like personal stuff or in the code problems. It really can tap you into that kind of thinking that some folks are not always immediately privy to with no direction or context, if that makes sense.
Ali: Yeah. That makes total sense.
Autumn: Playing music is good.
Ali: Yeah. And do you have anything that you want to plug? Plug your SoundCloud.
Autumn: So I don't have a SoundCloud, but I do have a Bandcamp, and it is autumngrace.bandcamp.com, Autumn like the season, Grace like Amazing Grace. A lot of the stuff that I have there is pretty not experimental, but kind of I wonder what happens if I go and play the banjo in front of a microphone? Which is the thing that I just recently released, so it's cool. If you want to see some weird experiments stuff of just me sitting in my attic, head on over. [laughs]
Ali: That's awesome. And so, I want to say thank you so much for joining me today. So again, I'm Ali, at endingwithali on everything, including Minecraft. And I want to say thank you so much to everyone listening, and you'll hear us on the next episode, so thank you.
Jonan: Thank you so much for joining us. We really appreciate it. You can find the show notes for this episode along with all of the rest of The Relicans podcasts on therelicans.com. In fact, most anything The Relicans get up to online will be on that site. We'll see you next week. Take care.
