Episode Summary
Jessica Schalz is a workflow engineer at Transposit, a company that build interactive runbooks for DevOps and SREs to turn alerts into action. Prior to this position, Jessica worked as a security engineer at Remitly, a product security engineer at Target, and a DevOps intern at Jamf. Jessica also worked as a teaching assistant at Girls Who Code and an undergrad research assistant at the University of Minnesota.
Join Corey and Jessica as they talk about what exactly a workflow engineer is, how Jess is an “aggressive advocate” for accessibility and neurodiversity, why Jess believes ADHD is a superpower in many ways, why Jess prefers agile development over waterfall development, how ADHD is a spectrum and people with the condition never really experience it the same way, what it was like working in infosec and why Jess decided to return to their engineering roots, the power of collaboration and how it lets teams see things differently, the important role empathy plays in collaboration, and more.
Episode Show Notes & Transcript
About Jess
Jess 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
Transcript
Announcer: 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.
Corey: This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the Enterprise (not the starship). On-prem security doesn’t translate well to cloud or multi-cloud environments, 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 percent faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com/trial.
Corey: 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.
Corey: 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.
Jess: Hi, thanks for having me.
Corey: 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 in 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.
Jess: 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 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, like, Slack. That's kind of my function.
Corey: 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?
Jess: Yeah. I would say I'm an aggressive advocate for both of those things. Yeah.
Corey: The reason I bring that up is, the more that I do things like, oh, I don't know, record podcasts and build workflows around it that people can work with, something that I'm noticing is that what I've accidentally been building here is things that accommodate 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. 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?
Jess: 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 codebase 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 and approachable way is very useful. And we see that a lot with, like, automated processes for daily life to like Google homes. So, it just depends on what that accessibility and approachability looks like for you.
Corey: 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 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.
Jess: [laugh].
Corey: And the things I saw as a result of that were, workflows were incredibly important. Everyone talks about CI/CD, for example, which made us feel way better about not actually doing CI/CD 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 three hundred 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. And 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 is load-bearing now.
Jess: Yep.
Corey: And it feels like that's the sort of thing that you allude to with what you do as a workflow engineer.
Jess: 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 could use this product in a way that is very user friendly. So, I don't mean to have this be a sales pitch. But—
Corey: Oh, please, sell. Sell.
Jess: [laugh].
Corey: Pretend for a minute that you're a mediocre white guy who’s pushing something. Go for it. The only promotion that is acceptable to talk about is self-promotion, by all means. Shine on you, ridiculous diamond.
Jess: 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 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.
Corey: 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 by now I know 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 there'd be advocating for replacing themselves somehow with someone who is better at this.
Jess: 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 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.
Corey: 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 podcasts and the newsletters and the rest, in most companies, that would be the role of three to five people, in most cases.
Jess: 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 waterflow 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.
Corey: I'm always a little reluctant to make sweeping generalizations because there's one thing I've learned, it's that ADHD is very much a spectrum disorder because I—
Jess: Oh, for sure.
Corey: —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 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 for that 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 believe, that I'm something different, but I leave the value judgments completely aside.
Jess: 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 that’s great. I think that diversity is beautiful.
Corey: 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, 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 and I told him what I was up to, and they asked one question in response and I got viscerally angry at it because it was—that just saved me an entire complicated thing with basically three lines of code.
Jess: Oh, yeah.
Corey: It's so good, it's awful. I'm angry I didn't see it. It's getting outside of your head and rubber ducking?
Jess: 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.
Corey: 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 tenet that I've ever seen in infosec is be as difficult for people to work with as possible. What's the story?
Jess: Ah, that's been a long history in infosec, hasn't it?
Corey: It really has.
Jess: Yeah.
Corey: 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 offering 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—
Jess: Absolutely.
Corey: —and, again, if you're [unintelligible 00:14:44] 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.
Jess: [laugh]. Oh, man—
Corey: 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.
Jess: No, it's fair.
Corey: So I'm trying to understand how you got to where you are.
Jess: 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. Like 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.
Corey: 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 to 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.
Jess: 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, like, immediately. It's not a question of a constant struggle, a constant improvement; you never know when something is 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 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.
Corey: 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.
And get an estate-wide view of sudden changes, so you can catch issues before they impact customers.
So go to NewRelic.com, sign up for free, and start exploring your system today.
Corey: 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 it 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.
Jess: Right.
Corey: 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 the 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?”
Jess: 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 cool to watch.
Corey: 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.
Jess: 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 our microservices. And it works out really well for me; 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 talked 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.
Corey: 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 the blog, it's always on a conference stage.
Jess: Oh, yeah.
Corey: Point being, if I want to deploy microservices in my environment. From my perspective, the reason to do that, traditionally, was, I have 5000 engineers all working on a monolith, and it turns out that the collective noun for developers is in fact, ‘Merge conflict’ so maybe we could 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 parody, 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.
Jess: That microservices are just inherently better?
Corey: No. The idea of having microservices be an answer to the people problem, aligning with how you see workflows evolving.
Jess: 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 solutions to people's problems.
Corey: 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 onto how do we create new problems?
Jess: [laugh]. Have you seen the—it's a product, I can't remember who has done it, but it's a watch that tells your employer your mood throughout the day?
Corey: I did see that. I forgot who was making that, but my comment was that I was introducing the ‘Amazon Fire Me.’
Jess: [laugh]. Yeah, as someone with depression, I was immediately thinking, my manager is just going to think I'm sad all the time and I don't think I want that. [laugh]. 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 learn over time, having empathy for your fellow engineers, or anyone you work with.
Corey: 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 00:23:20] great.” Like, an example of this is if we go back to the Glengarry Glen 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 about 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.
Jess: Oh, yeah. That's a very good point that financial and food security, and housing security, all 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 is an aspect of empathy that still needs to be fostered in the realm of connection among other humans when we're talking about those kinds 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 ten 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.
Corey: 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 ten years old—when you use git blame. [unintelligible 00:25:38] ‘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 codebase 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. And I'm not trying to sound preachy, I'm not trying to get [unintelligible 00:26:21] 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.
Jess: Yes. I think perfection is generally antithetical to the human experience. Like 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.
Corey: When people say they want to start a company to change the world, like, that's really what I'd love to see the actual answer be. Like, “How are you going to change the world?” “I’m going to make people's lives easier.”
Jess: Yeah.
Corey: 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?
Jess: Yeah.
Corey: It's a problem.
Jess: 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.
Corey: Yeah. It's optimistic for the future and 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?
Jess: I am on Twitter at @jessica_schalz. Warning, I am vaguely feral on that account. But if you're into hot takes and bad takes, I'm right there.
Corey: Excellent. And we will of course throw links to that in the [show notes 00:28:28]. Thank you so much for joining me today. I appreciate it.
Jess: Thank you. Thank you for letting me share some optimism and some joy with you.
Corey: It is refreshing to have, and it also just highlights how infrequent it is. Jess Schalz, 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.
Announcer: 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 HumblePod production. Stay humble.
