Screaming in the Cloud - ADHD as a Superpower with Jess Schalz

Episode Date: March 9, 2021

About JessJess Schalz (she/they) is a computer gremlin multiclassing in software development and infosec. She’s a queer disability advocate, and this informs her empathy-based approach to technology. Her hobbies include watercolors and collecting human remains. Talk to her about weird medical history and cats.Links:Transposit: https://www.transposit.com/Twitter: https://twitter.com/jessica_schalz

Hello, and welcome to Screaming in the Cloud, with your host, cloud economist Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. And that's not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35% faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com slash trial. If your mean time to WTF for a security alert is more than a minute, it's time to look at Lacework.

Lacework will help you get your security act together for everything from compliance service configurations to container app relationships, all without the need for PhDs in AWS to write the rules. If you're building a secure business on AWS with compliance requirements, you don't really have time to choose between antivirus or firewall companies to help you secure your stack. That's why Lacework is built from the ground up for the cloud. Low effort, high visibility, and detection. To learn more, visit lacework.com. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Jess Schalz, who's a workflow engineer at Transposit. Jess, welcome to the show.

Hi, thanks for having me. So I'm going to dive right in and ask, what the heck is a workflow engineer? It sounds either amazing as far as something a company should have to improve development workflows, or alternately, it sounds like a coordinator type of role that has been up-leveled to have the word engineer shoved into it and some sort of weird descriptor for a common role. I have the sneaking suspicion it's the former, but I don't want to assume.

Tell me more. Yeah, a workflow engineer, in my capacity, is someone who works with customers or clients to build automated processes for what they need in their kind of DevOps-y workflows. So I tend to work with things like APIs to build custom calls or workflows for people that they can then call through Slack. That's kind of my function. So this strikes near and dear to my heart because one of the things that you self-identify as and is extraordinarily relevant to the way I'm starting to think about the world is that you are a advocate for accessibility and neurodiversity. Is that an accurate description?

Yeah, I would say I'm an aggressive advocate for both of those things. Yeah. The reason I bring that up is the more that I do things like, oh, I don say I'm an aggressive advocate for both of those things. Yeah. my own expression of ADHD, where I find it challenging to do certain things on a schedule. So everything I do start to finish on this podcast is either automating handoff to other people, getting me the things I need when I start these things, and making sure that I'm not scrambling last minute to go ahead and implement stuff. And on the one hand, it's made this feasible. I do a lot of these. And if I had to do all of these things bespoke and by hand every day, it would be an unmanageable burden. But on the other hand of it, I've always felt bad about this kind of thing. Like, if only I wasn't quite so shitty, I'd be able to do this like a functional person,

and I wouldn't be burdening everyone I work with. Is this aligned with what you're talking about? I think so. I think it is a way for people to approach a problem in a customized way that they are comfortable with and that is approachable for them. So it's not as overwhelming to go into a whole dev platform or a whole code base that you don't know to do something. So for people who aren't familiar with code in general, being able to have it in an accessible or approachable way is very useful. And we see that a lot with like automated processes for daily life too, like Google Homes. So it just depends on what that accessibility and approachability looks like for you. From where I sit, it felt to me like, well, let's back up a bit and remove from the podcast space. Because admittedly, for the audience,

that tends to be a little bit niche. It seems like we have more folks listening who are familiar with DevOps workflows. And once upon a time, I called myself DevOps because, you know, calling yourself a sysadmin means you're doing the same job, but you make a third less. So yeah, absolutely, I'll jump along with the hype if it means people are going to pay me. Yeah, you can call me anything you want if you're paying me. And the things I saw as a result of that were workflows were incredibly important. Everyone talks about CICD, for example, which made us feel way better about not actually doing CICD, because there was a lot of scaffolding that was tied into it. There was a lot of boilerplate. If you want to build

Hello World in a way that you would actually build an application, it's not three lines of code. It's 300 and most of a morning in some shops to get that stuff set up. So every chance you get, if you don't have something that is enforcing this or much more ideally doing it for you, you're stumbling through the, well, I'm just going to work around that and take a shortcut here. I know you should never hard code credentials, but I'm going to take a shortcut and do it anyway. For one of my production systems, I kid you not, the DynamoDB table has the word test in its name because it was an experiment to see if it works. And then it worked and well, that sucker's load bearing now. And it feels like that's the sort of thing that you allude to with

what you do as a workflow engineer. Correct. Yeah, that's very accurate, I think. It's what we try to go for. And what really drew me to the role in general is that we wanted to create something so that engineers and non-engineers can use this product in a way that is very user-friendly. So I don't mean to have this be a sales pitch, but... Oh, please, sell. Sell. user-friendly. So I don't mean to have this be a sales pitch, but... Oh, please sell, sell. Pretend for a minute that you're a mediocre white guy who's pushing something. Go for it. The only kind of promotion that is acceptable to talk about is self-promotion

by all means. Shine on you ridiculous diamond. Thank you. Yeah. I think what really drew me to this is that the reason I wanted to be a part of this team was because to me, something that's incredibly important is making sure everyone feels like they have power over their own processes. So for me with ADHD, it's a big problem in my home life. So for you, it's organizing the podcast. For me, it's cleaning big problem in my home life. So for you, it's organizing the podcast. For me, it's cleaning my apartment. So I've had several people suggest getting a cleaning service, which isn't responsible right now, but maybe in the future, that's something I'll do. And I think being a workflow engineer also ties into that in a lot of ways, because it lets us build processes that make parts of our lives easier and less overwhelming.

The problem that I always ran into, and I'm curious as to how typical this is across the industry, is that when I have problems with workflows or problems with these things, I look at this and I put on my consultant gaze at it from 30,000 feet view. And it's like, oh, the reason that I'm having trouble with all of this is because I'm shitty. If I were actually good, I would have done all these things properly. So every time I see a bad workflow, I take a mental shortcut to, I'm just super bad at things. It's my secret shame, so don't let people see. And I know by now enough to know that this is wrong. And everyone who feels that way is wrong. There are procedural and process boundaries there, but it feels shameful and you feel alone, which means that I don't think

people advocate too often for improving workflows because it sounds too much to them. Like they'd be advocating for replacing themselves somehow with someone who is better at this. Right. That's a huge anxiety with especially older sysadmins that are worried about code automating their jobs out of existence. I've heard that from a ton of people. What I drive for in workflow and general life process automation is that it isn't that you're shitty or it isn't that you are bad at your job or bad at things. It's that your current conditions aren't correct for you or they aren't correct for the current period of your life. So something I've recently changed in my life is that now I have timers in my life to tell me when to take breaks. Otherwise, I will continue on an activity for way too long.

I think that that tied into me for a long time where I just thought like, oh God, I'm just a bad engineer and I can't time manage. That's not the case. I just needed something to remind me every so often because my brain is funky. Yeah. It feels like I look at how it expresses for me at least in terms of not being like other people. And if you ask me to list off how my ADHD manifests and what that means, I will come up with a laundry list of ways that I am difficult to live with both personally as well as professionally. And it's a giant list of my shortcomings. I'll just completely gloss over the other side of it where it empowers me to do a number of things that would not be tenable otherwise. If I take a look at what I actually functionally do in terms of a marketing context for the podcast and the newsletters and the rest, in most companies,

that would be the role of three to five people in most cases. Yeah, I think ADHD in a lot of ways is a superpower because we are so able to jump from topic to topic. So I have found personally agile development works really well for me because it's so like short story. It's so quick and rapid development that it's way less overwhelming to me than things like water flow style or like huge project all at once overwhelming mountain of work style of project. And I see that also translating into my daily life where as an engineer, I find that very helpful for ADHD to let me jump through different hoops. I also find it very helpful for me to notice all of the things around me happening rather than only being able to address one thing at a time.

I'm always a little reluctant to make sweeping generalizations because if there's one thing I've learned, it's that ADHD is very much a spectrum disorder because I talk to other folks who have it and their experiences sound absolutely nothing whatsoever like mine. It may as well be someone from another planet. And then I talk to other folks and some of it sounds alike. And I talk to other folks and it sounds like my mirror image. So I'm very reluctant to make broad, sweeping generalizations about it. It feels on some level uncomfortable for me to talk about, even if I get past the stigma aspect, because it feels like at that point, I'm just talking about me. And honestly, I'm not great at talking about how awesome I am, because I don't want that to ever be the brand. It's super easy to have to come off as incredibly full of myself

and sound like a blowhard. That's why my favorite joke whenever I have to mock someone is myself. Because first, I'm not going to piss anyone else off. And secondly, I'm much more comfortable being the butt of a joke than I am getting up and sincerely telling people this is why I'm awesome. Because I don't see myself as awesome. I really don't. And I have enough people that tell me otherwise, who I trust, that I kind of believe that I'm something different, And I have enough people that tell me otherwise who I trust that I kind of believe that I'm something different, but I leave the value judgments completely aside. Yeah, it's definitely a fair statement to say that ADHD is an incredible spectrum of experience. For me, I think of it as a superpower and I try to think of it as a superpower for everyone,

but that might not be the case because how it affects me is very individual. So for me to say it's a superpower, I think it means that our brains just operate different from other people. And it's great. Like, I think that diversity is beautiful. It really is. And we talk about, well, what about diversity of thought? This is the kind of thing I equate that to in the non-horrible context. Yeah.

It's the, yeah the different ways of thinking, different lived experiences, different perspectives on stuff. That's super valuable. One of the hardest parts I found in the two years that I was doing this independently before I took on a business partner and a team was I was stuck in my own mindset all the time, where I didn't have anyone looking at my code, for example. So I spent weeks beating my head against something relatively recently. And someone was looking at what I was doing. I told them what I was up to. And they asked one question in response. I got viscerally angry at it because it was, that just saved me an entire complicated thing with basically three

lines of code. Like it is so good. It's awful awful. I'm angry I didn't see it. It's getting outside of your head and rubber ducking. Yes, absolutely. My manager is my rubber duck for me, where I'll come with her to problems with like, I don't know what's going on. Why is this happening? And she'll look at me and she'll look at my process and she'll be like, oh yeah, give me a second. I think you just need to reframe something. And then the problem is solved. And that bouncing off is so valuable for different types of brains. So before you were focused on workflows, you were in the world of InfoSec, which is fascinating to me, not least of all, because it seems that the primary tenant that I've ever seen at InfoSec is be as difficult for people to work with as possible.

What's the story? That's been a long history at InfoSec, hasn't it? It really has. It's one of those things where there are two worlds of security. One is what people say they do, like security is job zero. And then there's the reality of it, where, well, we built the slide, forgot security, and we're going to slap security at the very top and call it job zero like it wasn't an afterthought.

Your security is important to us, is what companies say right after they have publicly demonstrated that it very much was not. And so on. And then you wind up with a world full of vendors who are operating what is basically the same thing with different logos on it and it's easy to become jaded and annoyed. Then you have the entire community,

which is, frankly, toxic in many respects and why I got out of that space. Absolutely. If your person doesn't disagree with it and you're in the InfoSec community, feel free to email me if you can manage to put together an email that doesn't involve a bunch of profanity. Oh, man. I'm sorry, I'm being a little unfair, but not by much. I had some bad experiences in the InfoSec space across the board.

No, it's fair. So I'm trying to understand how you got to where you are. I actually had very similar experiences with InfoSec where it was so not beginner friendly. So much of it was if you weren't immediately excellent, then it was incredibly difficult to break in. But the thing that really struck me about InfoSec was that it was so difficult to measure wins. It was so difficult to feel like I had ever accomplished anything because everything is a constant struggle. So I loved working with users and I loved working with every aspect of a business and helping them find their solutions in a way that worked for all of us. But my goodness, it's hard to feel like you get a win. So I ended up switching back over to development, which is what I'm originally trained in,

because I figured at least I have incremental wins there. And that is easier for me to understand. But you got out of InfoSec. And I'm not trying to cast aspersions. I'm genuinely looking to know, what drove your migration from InfoSec-focused workflow focused? Because yeah, sure, security is important. At least that's what we always tell ourselves. But as far as developer workflows go, I don't necessarily know that there's a clear path there that I'm seeing.

Yeah, my path was, so I originally got my degree in software engineering, so that might be part of it. I think what I like about workflow engineering compared to InfoSec, why I would make that shift, is that with workflow engineering, I still get the aspects of InfoSec where I still have to safely handle information. I'm still touching information security and in that realm, but in a way in which there are deliverables immediately. It's not a question of a constant struggle, constant improvement. You never know when something's going to be finished. A client can say, I want X, Y, and Z,

and you can deliver that in a way that brings them joy. And I think that is the difference for me of like why I made the switch, because there's still empathy, there's still data handling and safety and working with people and making something for them. But I also can see my accomplishments in a measurable way. Forget dozens of visualization tools and view your entire system in one place with New Relic Explorer, the latest addition to New Relic One. See your system-wide health at a

glance with a dense hex view that has your hosts, services, containers, and everything else you probably shouldn't be monitoring but are anyway. And get in a statewide view of sudden changes so you can theoretically catch issues before they impact customers. But let's be serious,

you aren't checking your dashboards until 20 minutes into an incident that has been impacting customers for half an hour beforehand. So go to newrelic.com, sign up for free, and start exploring your system today. Be sure to tell them I sent you so that they can facepalm mightily. One question I have for you is if we take a look across the board

of DevOps space, and the only way to get security built in is to actually build in from the beginning. You don't get to bolt it on after the fact, and that's clear. So the workflow has to embrace that. But darting back to our earlier point, where we're focusing on the idea of empowering people who think in different ways. I look back at how software used to be built in the dark times of waterfall and whatnot. And I would have been a complete non-starter there in the way I'm only mostly a non-starter these days. But I have to wonder, is there some alignment in the way you

see things between agile development or the way that architecture has evolved that embraces different patterns of thinking that don't involve, we're going to make a plan and then for two years we're going to follow that plan? Yeah, absolutely. The ability to break things into pieces and see things in different perspectives is very, very unique to current development practices. And it shares a lot of thought patterns with people with a variety of different brains. So when you put a whole bunch of people on a team together with different kinds of brains, you all see things in different ways, and that makes the process more efficient. And it lets us build things in ways that we wouldn't be able to see two years into the future. And we get to do that so quickly now. And I think that's amazing and very, very cool to watch.

Do you see that this maps differently into the microservices approach versus monoliths? I mean, I know it's not quite the same thing as going from waterfall to agile, but there are echoes of it the way that I see the services architecture evolving. Yes, the building of those two things, I think, takes very different forms. And how I can map my ADHD onto a map of microservices makes perfect sense to me. So when I'm trying to build a monolith application, it's much more difficult because I have to fit all of these pieces in together that I can't quite visualize. Whereas microservices very clearly parallels my brain. So my thought processes are all over the place so are microservices and it works out really well for me like I can visualize that so clearly and that to

me makes development much easier and I think it is easier to digest for a lot of people as well like we talk about the curb cut effect with disability and with neurodivergence where it's anything that makes life easier for neurodivergent or disabled people makes things easier for everyone, regardless of disability or neurodivergence. And I think we see that in development too, where we can move things faster and people can understand systems better when they are broken up more clearly and it's less tangled. I wonder if this ties into, I guess, a common complaint I have about microservices, which is people will ask, should we use microservices? I guess so, because I saw some thought leader talking about it on a blog somewhere. I'm kidding. It's not on a blog. It's always on a conference stage. Point being, if I want to deploy microservices in my environment, from my perspective, the reason to do that traditionally was I have 5,000 engineers all working on a monolith,

and it turns out that the collective noun for developers is, in fact, merge conflict. So maybe we can find a better way of doing this, and microservices absolutely solves that people problem super well. And then it looks like it's almost been twisted into parity where you have five engineers working on 300 microservices. And I look at this and think that it feels like it's sort of missing the point here. Now, understand that my own architectures are, I want to say intentionally bad, but no, they're hilariously bad. It isn't always intentional. I'm curious

as to what your thoughts are on that particular alignment. That microservices are just inherently better? No. The idea of having microservices be an answer to the people problem aligning with how you see workflows evolving. I don't know if I would call workflows the solution to a people problem. Partially because I don't think technology can solve people problems necessarily. I think people problems are people problems and we need to solve them with people solutions. But the aspect of workflows is that we make those people solutions easier. So if your people problem is too many engineers on a team, that's not something technology can necessarily solve. That might be an organizational shift or what have you. But workflows can maybe make the

engineers' lives easier while they are still working on too many services. So in that respect, I think technology can only aid people's solutions to people problems. On some level, it almost feels like aspects of technology have lost sight of the fact that the actual purpose of this is to solve problems for people. And instead, it seems like some sectors are barreling on to, how do we create new problems? Have you seen the, it's a product, I can't remember who's done it, but it's a watch that tells your employer your mood throughout the day. I did see that. I forget who was making that, but my comment was that I was introducing the Amazon Fire Me. Yeah, as someone with depression, I was immediately thinking, my manager's just going to think I'm sad all the time.

And I was, I don't think I want that. But yeah, that's what it feels like to me. It feels like we are disrupting a lot of things with our technology. And I say that so sardonically that really it takes a human connection sometimes, and that can be very difficult. But I think it's a skill that everyone should develop and it's a skill that everyone should develop, and it's a skill that everyone should learn over time, having empathy for your fellow engineers or anyone you work with. I really think that there's an empathy story. And very often when people start talking about empathy, it is perceived by some of the worst people in the world as a form of weakness, where it's, yes, yes, be nice to people and great. An example of this is if we go back to the Glenn Gary, Glenn Ross movie, there's this great monologue about coffee is for closers. And there's this whole rant. And most people look at this with, that's an awful place. I would get

out of there and I would storm out and they're right. But there's a certain type of person who watches that scene, gets fired up and says, I'm going to go sell some real estate. There are certain folks who want to basically sacrifice everything in pursuit of certain goals. And on the one hand, I do admire the idea of that single focus that occludes everything else. On the other, it feels like it's a hell of a way to live, especially when it's for something as relatively shallow as getting a big paycheck. Now, again, I understand I'm incredibly privileged when I say that. I don't worry where my next meal is coming from, and a lot of folks do. If you're in that position, for God's sake, yeah, get money, put food on the table, feed your family first, then eventually you get to the point of thinking aspirationally what dent

you want to leave in the universe. I don't want to undersell that. Oh, yeah. That's a very good point that financial and food security and housing security, all of those things kind of take precedent over psychological safety in some ways. We see tons of marginalized people, myself included in the past, that will have to compromise their own moral ground and empathy to ensure their safety. That's for sure. But I think there's an aspect of empathy that still needs to be fostered in the realm of connection among other humans when we're talking about this kind of work too. Rather than test-driven development, I tend to do empathy-driven development because that actually guides the design of my product. So I tend to ask people what problem they're trying to solve

and how that problem makes them feel. And then I can actually address the root of the problem because nine times out of 10 in my experience, whatever somebody is actually frustrated with is not necessarily the problem they said they're trying to solve. So it lets me view their problems in a very human way that I think is very valuable. The biggest problem that I see in the entire industry is that we always have this short-term thinking, regardless of anything else. And we see it everywhere. In the to-do, I will fix this later, and you check, and it's 10 years old when you use git blame. Honestly, you can analyst that to git shame, because that's how we use it, but that's neither here nor there.

A challenging piece to that as well is whenever I talk to companies about technical debt, there's always this persistent delusion that never gets corrected, that as soon as we finish the next sprint, then we're going to go back and do everything right. We're going to fix the technical debt. We're going to start making technical

and architectural decisions that are not compromises. We're going to do it from a purist, absolute right perspective. And it never happens. The few companies that actually intend to strive for architectural purity very often run out of money. Their code base was beautiful, but they never found a business model. And it always feels like it's a short-term thinking problem rather than looking at the bigger picture. I'm not trying to sound preachy. I'm not trying to get here from on high. But the only way I think personally for this to get solved in some cases is one, for people to wake up, which good luck, and two, to have the workflows and the tooling and the way that you approach things to align with doing things right becomes easier than not doing it. Yes. I think perfection is generally antithetical

to the human experience. We see so many people trying to be perfect and build these perfect workflows and tools when maybe that's not what we actually need. Maybe what we need is to feel good about what we do and to feel more comfortable and to feel like it's easy. And if that's the case, and if that's what my workflows can provide people, then I'm more than happy to build that work because I know that I'm making lives easier doing it. When people say they want to start a company to change the world,

that's really what I'd love to see the actual answer be. How are you going to change the world? I'm going to make people's lives easier. Yeah. And a lot of companies will claim, oh, that's me. And sure, the intentions are there, but look at the externalities that generate from these hyper unicorns. It's a problem.

Yeah. I remember in my interviews actually for this company, I remember at one point talking with our leader of product and we had a discussion about how documentation is in itself a form of empathy because you are writing for the future. You're not writing for yourself currently. So whether it's being kind to yourself or being kind to others, it is still an act of kindness and human connection to write documentation for other people. And that to me is I think what workflows are about, what people are about, what engineers are about, and I'm excited to see people really embracing that right now.

It's optimistic for the future. I think that is probably the best note to leave this on. If people want to learn more about what you're up to, where can they find you? I'm on Twitter at Jessica underscore Schall's. Warning, I am vaguely feral on that account. But if you're into hot takes and bad takes,

I'm right there. Excellent. And we will, of course, throw links to that in the show notes. Thank you so much for joining me today. I appreciate it. Thank you. Thank you for letting me share

some optimism and some joy with you. It is refreshing to have, and it also just highlights how infrequent it is. Aw. Jess Shawls, Workflow Engineer at Transposit. I'm cloud economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform

of choice. Whereas if you hated this podcast, please leave a five-star review on your podcast platform of choice, along with an inarticulate comment saying that no, that's not actually what diversity of thought means. This has been this week's episode of Screaming in the Cloud. You can also find more Corey at screaminginthecloud.com or wherever fine snark is sold. this has been a humble pod production stay humble