ARTY: Hi everyone and welcome to Episode 148 of Greater Than Code. I am Arty Starr and I'm here with my fabulous co-host, Jessica Kerr.

JESSICA: Good morning. And I am here with my friend, Chante Thurmond.

CHANTE: Hello, Chante here. And I am going to introduce our new panelist and guest of the day, Jacob Stoebel. Hello.

JACOB: Hi. Thanks for having me.

CHANTE: It's our pleasure. Thanks for joining.

JACOB: Okay. What do we talk about?

CHANTE: We'll kick it off with the first question that we always ask. What's your superpower?

JACOB: This is a little bit of backstory about me is a little less than a year ago, I found out from my therapist that if I were just a little bit younger, I likely would have been diagnosed with Asperger Syndrome. So while that's not an official diagnosis by any means, I do have a number of traits in my personality that sort of overlap with what you typically find in people who are on the autism spectrum. And one of my superpowers and like many superheroes also might in some ways being one of my super weaknesses, I can be really obsessive about specificity and I'm often allergic to when there's ambiguity sort of hanging in the air in a dialogue with the team that I really, really want to iron out and find out everything that can possibly be known. Or just to put it another way, like if there's something that I think there's a place where there could be a miscommunication or a potential for miscommunication, it's almost like an air bubble and I really want to just sort of smooth that whole thing out. Even if it's just to say like, "Hey, do we know about X?" And we can all say, "Nope, we do not know about X yet. It's an unknown." Then at least we can sort of call it the unknown ‘unknown’ and we can move forward. I think that's my superpower, in some contexts. In other contexts, it's a weakness.

CHANTE: I love that you started with this because it really kind of allows us to introduce this kind of concept that folks are now getting more comfortable talking about in the workplace. When we talk and we say, "Listen, I'm likely on the autism spectrum and this is my neuro-diversity and how I'm showing up in the workspace and how I might be interpreting or how I'm kind of functioning on the team and this is what I may need from you."

JACOB: Totally.

CHANTE: With that said, have you introduced this to the teams in which you work with?

JACOB: Yeah. I don't always. It's very situational. One thing that I know if you sort of do some reading, there's a lot of conflict among people in the autism community. Some people feel strongly, I would not count myself in this group, but some people feel strongly that self-diagnosis is problematic. Again, I don't really count myself within that group because there's a lot of reasons why a person may be on the autism spectrum and was not diagnosed as a child. In my case, it was age. I was just a little bit too old when Asperger Syndrome entered the DSM. In a lot of cases, it can be a factor of socioeconomic class, of race and also gender. All of those things can change you. If you're a white boy in a middle to upper class setting, you're more likely to receive that diagnosis. And if you're not, it's more likely that you're going to be labeled as just, you have trouble focusing or you have behavioral problems or any number of other things. The outside world sometimes doesn't fit for me. The outside world isn't always built for me. And to have someone just say, "Oh, I'm autistic without any formal diagnosis." They find that problematic. And again, I don't personally believe that, but I also want to be sensitive to that concept. I would consider myself from a place of privilege that I've been successful in my life. I've managed to sort of get by. I graduated from college. I've [inaudible] my parents and I'm married. And there's a lot of people that are on the spectrum that might struggle a lot more than I do and I want to sort of acknowledge that I have privileges that other people could say that they don't. So that's why I'm really careful about it. And you can tell from the way I'm talking about this that I still feel really conflicted about it or it's something I'm still learning about.

CHANTE: Yeah, it's a new thing and it's a new identity that you sound like you're learning to incorporate into your life. And I can totally understand. I think it's better to be cautious and to be mindful of other people and their sensitivities and the greater community and the need to tread lightly when it comes to self-diagnosis because we certainly don't want to necessarily endorse it or promote it but at the same time, you said something that was really key that the age in which this became an option is really from a diagnosis standpoint, that was like a big contributing factor. So for anybody who's listening, don't take it from us, go see a professional.

JACOB: It's true. And what I was told is that a lot of people may have been diagnosed when they were a child, but there's a phrase, I believe it's called masking, where you learn that there are certain behaviors that would not come naturally to you at all, but you just sort of learned that this is sort of what's expected to you as you go about your day and you just sort of learn to just, "Okay, this is how I need to behave," even though it takes a little bit extra effort than other people would find. Again, I can only speak for myself, other people, their experiences may be wildly different. And yeah, that is exactly why I want to just really tread lightly, like you said.

CHANTE: Now that you kind of have a name for this, has it empowered you not only at work but in the other aspects of your life?

JACOB: It has because now I have something I can Google. [Chuckles] There are books now that I can read. There was never a book that I could read before, which is like, "Why do I feel awkward sometimes?" Or, "Why are noisy bars just my idea of the worst thing ever?" Now, I can have some kind of framework that can explain like this is why you feel the way you feel in certain situations. And when you can learn more about yourself that way, you can sort of figure out how you can work better on a team.

JESSICA: Yeah. Because then you can do things like say, "Hey, I have this thing where I'm really good at noticing and not moving past ambiguity without explicitly acknowledging it. If I do that when it's a pain in the ass, tell me."

JACOB: Exactly. Or you can say like, "Yeah, it's ambiguous, but you know what? Don't worry about it right now and I'll trust you."

JESSICA: Right. That's super important because if you didn't have the ability to be like, "Okay, this is unambiguously ambiguous," then it would be a blocker.

JACOB: Yes. I think that really, really great supervisors have the ability to sort of just turn those too. They can say like, "This is a time when we need to nail down everything and this is a time where we're going to say, you know what, we need to punt on this because we don't have enough information. We either need to proceed or we need to just sort of pause and not spend time on this right now because there's not enough to know." But yeah, I think managers can really set that example really well.

CHANTE: So I know you mentioned -- I'm going to change the subject because I'm thinking about the workplace more specifically and I know that you've been a guest in the past but I never listened to that episode. So I'm wondering if it makes sense to tell the audience more about who you are and what you do so we can give them even more context about you.

JACOB: Yeah, yeah, yeah. I'm a software developer for a small remote company. I'm a Ruby and JavaScript developer. I'm what I call myself as a community-taught developer. A lot of people in my position would call themselves self-taught, but I've never really liked that label because there are just so many resources from a lot of other people that I've drawn upon.

ARTY: I love that.

JACOB: Yeah. I think that came up in some episode on this show a long time ago, maybe a year or more. But yeah, I didn't just inherit skills. I didn't just sit down at a computer and start typing and then just sort of like teach myself how to program just without reading or without talking to anyone or without any kind of reason. A lot of people invested their time to put resources out there. In many cases, for no money of their own and I benefited from them. So I think at the very least it's worth mentioning that I owe my current career to a lot of different people, including some on this podcast, I should probably say. So yeah, I was working in a job where I had a lot of sort of manual data entry that I needed to do, like typing stuff into spreadsheets. And I had just begun to sort of experiment with Python just on a whim and it sort of just occurred to me as like, "Huh, I wonder if I could use this to sort of be lazy at my job and sort of get all my work done faster." And it turned out that I could, and I was very, very lucky that I had a boss who was willing to sort of take a risk on me because what I said is like, "I want to sort of spend, rather than taking five hours to do all this data entry, I want to spend a whole week teaching myself how to automate that process so I can jam a bunch of data into the right cells on a spreadsheet. Instead of having to generate that report by hand every month, we can automate it and it'll take seconds." And what I said was, "I'll be honest with you, this would be a learning process for me. There'd be an investment in taking the time to sort of stumble through it and figure it all out." And my boss said yes. And I think her saying yes was one of the best gifts I ever got in terms of preparing for this current career. And sort of fast forward years later and I've pivoted into a career as a software developer.

CHANTE: Wow. That's pretty cool.

JACOB: Yeah. I think it's one of those sort of origin stories. Like, you know, a lot of people they get into it because they started with a WordPress site and they were really into graphic design or web design. I work as a web developer now, but I think it's sort of a similar sort of adjacent field, which was just sort of working with data, basically just an office job. And I think there's probably a lot of people out there and maybe you are listening to this podcast now, that if you are someone that just spends a lot of time with spreadsheets and data and that really clicks with you and you're wondering like, "Can I use software to do my own job better and more efficiently?" The answer is yes. And you should totally look into it because it would totally pay off.

JESSICA: So you got into development for reasons for something you wanted to accomplish with it?

JACOB: Yes. I cannot imagine how I would have ever been excited about this if it was just like, "Let's build a to do list." Or frankly other people are really motivated by like, "Let's learn how to build like a 2-D scrolling video game." Maybe that would have motivated me but not serious gamer that I don't know if that would have been enough of a motivation to sort of get me over the humps. But the possibility of (a) making my job less stressful, (b) getting to be a little bit more lazy at my job, and also (c) earning the admiration of my coworkers was a huge motivator. So yeah, I think you're right. If you can find a problem, that is a great jumping off point to teaching yourself something new, whether it's like the software or really anything else. Find yourself a problem to solve and see if you can teach yourself the skills you need to solve it.

ARTY: Admiration of your coworkers, did that work out?

JACOB: In some ways. There are some examples. Basically, there was this task that nobody likes. We were getting these reports and they were in PDF. And basically, there was no simple way that anyone knew of where we had to sort of synthesize a bunch of PDFs and aggregate a bunch of data and stick it into a spreadsheet, and then so everyone could sort of see this report in aggregate. And it was just this horrible topic, no one liked it. And I researched and I found a way, we're going to scrape these PDFs, we're going to grab the data and we're going to sort of do all the math. And suddenly this process that easily could have taken someone a day, like an entire day of sort of clicking around and looking for stuff and just like the most mindless job that no one would like to do if they could help it. It was something that you just press a button and it was ready. And yeah, it saves people time. It was this thing that no one wanted to do and it was just the most mind numbing thing ever. And everyone hated it. And suddenly I was like, "Okay, look, you don't have to do it anymore. You shouldn't have to, you don't have to. Done."

ARTY: I love this story because it's like what are the key ingredients to lighting this spark of falling in love with the magic of software. And I think about all these things that you've mentioned kind of coming together and that there was this problem that everyone hated doing this thing, this process that nobody liked. We have to take all these PDFs and manually aggregate them all into the spreadsheet is this awful dreaded thing. Then there was an idea and you can use this epic thing and figure out how to solve this problem and have a magic button that we can press and how amazing it will be. And you start dreaming about the magic cool tool and being able to push that button and it'll just automatically all happen. And then there was another key ingredient in that your boss created space for you to go down this path of exploring and learning and figuring this thing out and running with your passion. And so then you have that dream and that space to go and blossom down that path and that magic of pushing the button and being a hero for your team, slaying the monster and then also just inspiring everyone else to realize what you can accomplish with just a little bit of magic in there. That's so cool.

JACOB: Yeah, exactly. And I've heard of companies that are very liberal in terms of what they will let their employees spend time learning about. So if you say, "I've always wanted to learn about woodworking," they'll say, "Yeah, here you go, here's some money, go for it." And I think what I've realized is if someone just has this driving desire to learn about something, there's a good chance they're going to get something out of it, or at least they think they're going to get something out of it. Sometimes people learn something just out of sheer curiosity. But I think whenever I want to learn something, it's because I at least suspect that there's some kind of problem that can be solved, something that can be done better. And I might be wrong. It might turn out that I learned something and it's not really useful because not only are you learning, you're also learning about the field in which you are learning more and how would that applicable and how it's not. I just think you can never go wrong with giving some time to your people to learn what they're just really driven to learn about because there's always a chance they're going to come up with something that can solve some kind of problem with your team house.

CHANTE: Touche. Touche. I mean, what you're talking about, what you're describing is like what I would say is an issue that we talk often about in the future of work and re-skilling and up-skilling people. And I think at the end of the day, if you pay attention to people's passions and their desires and interests and the curiosities, that you satisfy something in them. And so let's say that it is woodworking and that you work in a software tech company where we have to look for the silver linings of what is it that you may learn from doing these things about yourself, about the process, about something else. It might inspire you. It might not be a direct kind of thing that people are yielding from, "Hey, we're going to go invest in Jacob to do woodworking," but I bet you that your happiness, like your level of happiness or engagement at work would increase because they allowed you to do this thing that kind of satisfied this curiosity or this desire in you, and they're going to see more out of you as an employee. So, I think that's such a good, valid point.

JESSICA: It's not like you're going to spend all your day on woodworking, but at SoundCloud, a long time ago, I got to see their office and they had a room that was like a maker room. The parts that I remember were the parts I care about with paper and markers and things that I could paint with. But they also had like some woodworking equipment and stuff that you could actually go there and make something. And being able to do that on breaks or in between things or at the end of the day or anything like that, God, that would be so expressive and mentally simulating.

JACOB: Yeah. And I can't cite it exactly, but there's just a lot of research out there that talks about how if you can sort of just get your body working in terms of drawing or in terms of moving. I'm speaking vaguely here, but it unlocks a part of your brain that you just wouldn't get when you're just sitting at a desk typing.

ARTY: I kind of love the idea of woodworking. Just imagining like a little woodworking [inaudible]. At home, I have my office set up and then when I'm thinking about a problem, I leave my paints out and I've got usually a mural or something I'm like working on on one of my walls, [inaudible] monster room and then all the different monsters have different faces and expressions and I'm going to make them all say different things and it's like totally this crazy thing. But my house is my canvas. And when I'm going between working and just needing to sort of switch gears and get my mind sort of flowing with something else, sometimes the best thing you can do is go for a walk or pick up a paint brush or do some other sort of creative activity. And then, "Oh, there's the answer to my problem," and go back to design problem or something you're working on. It's trying to get movement of your thoughts to happen. You kind of upload the puzzle there in your brain. You've got like some software puzzle or something that you're working on. You upload the puzzle in your brain and then you go for a walk or you paint or do something and then it sort of marinates in there for a while. And then Eureka! Here's like some kind of answer that strikes you and it's like you can get that thought flow going easier. Like you go and do something else.

JACOB: Yeah, I mentioned woodworking because I haven't worked with wood in any capacity since college and I was bad at it. But what I learned from that is that -- so one thing I'm really comfortable with working in technology is the command Z button because I can undo pretty much anything. And if I've got the right system set up, there's really nothing that I can do that I can't undo. And [inaudible] sometimes because I'll often find, especially like at a 3:00 PM in an afternoon on a Friday, that sort of my eyes glaze over and I'm clicking between tabs and I'm trying the same thing five times in a row without expecting different results and just sort of forgetting what I was doing. But the thing about working with a physical material is like say I'm building a shelf or something or a table. There isn't another table in a different tab over there. There's just one table in front of me. And if I cut a piece of wood short and it's too short, I can't just fix that immediately. So what it does is it really focuses me and sort of grounds me in a very immediate sense of like, "This is the thing, the canvas, like you said, like Arty said to me, that's right in front of me, and I can't forget what I was trying to work on. This is the thing, how do I want to sort of transform it from what I've got now and to what I envision it to be.

JESSICA: Yeah. Which with software, like you said, we have undo so we can just try stuff and move back, which is fantastic. And yet sometimes we still fail to put enough thought into how do I get from here to there because conceiving of the code in a new state is so much easier than getting that into production in a smooth way.

JACOB: Yeah. You're sort of tempted to think about like, "Can I just change it a little bit and then just see how we like it and then change it a little bit more?" And then you suddenly find that your journey has been this sort of roundabout rather than going from point A to point B in a straight line, you've sort of gone in like squiggles and gone a little over the place. Maybe you didn't even end up where you thought you were intending to end up in the first place.

JESSICA: And that can be great unless while you were squealing to the left, some other system got dependent on you being over there.

JACOB: Exactly. Or like you forgot what assumptions you were baking in because you did it in 12 steps instead of one.

JESSICA: Or you've left data in 18 different states and formats.

JACOB: Yeah.

JESSICA: Jacob, I have a question. You got into development in order to automate boring work. What kind of things do you do now to automate boring bits or any bits?

JACOB: I found that the deployment process and my work is pretty great actually. But what I found is that it had like all of these configuration options that you could sort of pass in. And what I found out is that I was spending all this time typing a whole bunch of letters to do almost pretty much the same thing every single time. What I realized is like, "Oh, there are all these sort of defaults that I wish sort of existed in our deploy process." Whereas there's four different options that you'll have to specify specifically. And I wish that I could just have a tool that's sort of like plug them in by default or sort of inferred them based on some common sense and state, something using common sense that I've sent for. So I built like a little tool that's sort of wrapped around our deployment tool and sort of just plug that in. It was just my little tiny little CLI that I could just literally type deploy and then sort of based on my current directory and a few other things, it would sort of just figure out what did I want it to do? And because I worked for a consultancy that has lots of different clients, I often find that I'm having to type that a whole lot of times a day. And if I'm trying to juggle three different projects at the same time, like keeps sort of jumped back and forth between them, I can just say like, "Hey, please deploy this." And I can just sort of switch over to the next thing really easily. We found that that was really saving a lot of mental energy.

JESSICA: Mental energy. Yeah. That's so much more than the typing.

JACOB: Yeah. I was saving maybe a couple of dozen keystrokes, which do I need to bust cash again? I can't remember. Which was it? Oh yeah. Okay. Then yeah, but just like all that stuff, you could teach a computer how to make an inference on that.

JESSICA: Yeah. Make an inference based on your context of the directory you're in, the branch you're on, stuff like that. And that's something that like personal automation works really well for because if you are using someone else's program, you might be like, "Ah, why did I do that? Ah, why did I do something differently over here?"

JACOB: Yeah. It was completely built for me. And there was another thing where I found that I would go to deploy something to our staging environment. And I will say, "I'm going to deploy this and I'm going to come check back on it later to see if I got it right." And then hours would go by and I'd probably forget that I deployed it, that I was supposed to circle back and check on it. So I just set up a little tool that it's like, I'm going to have my computer just yell at me like, "Hey, I'm done." Or, "Hey, I blew up." It's almost like a timer on my microwave that says, "Beep, beep, beep. Come back and look at me. And then there was a third which was everyone says like you shouldn't deploy on Fridays. Well, I forget when it's Friday a lot. So, I'm just going to say like, "Please blow up if it's Friday." Unless I class a specific flag and say like, "No, I'm forcing you to deploy it on Friday."

JESSICA: If I push to master in certain projects, it's like, "Uh-oh, you have to set no really equals true."

JACOB: Yeah. I have a GitHub that's like, "You may not force push to master. If you want to force push to master, you must delete this [inaudible]." There's no way around it. So, just little stuff like that. I'm a huge fan of sort of writing software that helps you write software better and sort of just helps you think about it less. And writing software, that doesn't have to be for your whole team. It could just be for you because it helps you sort of follow your own path of least resistance that makes sense only for you.

CHANTE: As a person who is nontechnical, what would we call that? I think that that's really important to kind of focus on, because I think this personal automation kind of conversation is really interesting to me because I'm all about finding ways to make your job more enjoyable and optimize your workflows so that the team's workflow and then therefore the company's workflow's better. What did we call that?

JESSICA: I call it personal automation.

CHANTE: I mean, is Google in that business because they're thinking about the future of work, they're thinking about how you as individual might work a little bit better and they're trying to bring in features that would make it more enjoyable for the personal workflow and therefore inform –

ARTY: Like what?

CHANTE: Like these different plugins that you can do with your own personalized calendar, with the team calendar. They're trying to do more features in Google drive where you have workspaces [inaudible] for you that you can invite others too. I'm just curious, so that people who are listening who maybe aren't as technical, there's a name for it.

ARTY: When I hear the word personal automation, the experiences that it brings up for me, I think about like, I used Eclipse for a really long time and then I would run into various things in my development workflow. Like for example, we were using MyBatis and we had these handwritten queries that were in XML and then we'd have an identifier somewhere in the code that would point to a reference name of a query. And then we were always like going navigating back and forth between the definition of the XML thing and the query references. And I watched myself go through this process of navigating back and forth over and over again. And so I'm like, this is kind of a solvable problem here, right? So what I did, I wrote a little plugin that parsed all of the configuration for the queries and then took the queries and put them in tool tips for when you hovered over any of the query identifiers, it would show you what the query actually pointed to and then you can hit a hot key and it would navigate where that is in the XML. And so then you can navigate back and forth. And it was so much easier and pleasant to use. And the personal automation though, it was like I saw a problem that was causing me personally pain. And I took it upon myself to look at what tools and things I had before me to be able to automate my way out of my own problem. So I feel like if someone else is building a tool for a market of people, it's fundamentally different than that mindset of taking ownership, of automating away my own pain and that personal automation isn't so much about the tools available such as that mindset of taking ownership, of automating our everyday workflows. Workflow automation might be another, but it's personal workflow automation. I don't know. What do you think, Jess? You kind of work in this tool space too.

JACOB: What about cognitive outsourcing?

JESSICA: Cognitive outsourcing. I love that. What does Tiago Forte call it? Building a second brain. It is very much putting your cognitive work into the computer, into the technical half of, each of us has a socio-technical system.

CHANTE: Another one that comes to my mind is like for instance, like tools such as 'if that, then this' or you can personalize your workflow. For me who has no technical background, "This is great." But my workflow is different than somebody else's. I was just trying to think of the name of that just in terms of the type of company, just so that folks who are listening to this podcast have a little bit more context. Like if that, then this [crosstalk].

JESSICA: [Crosstalk] definitely that for developers in particular. We make tools for development automation very much. You have to write code in them, don't click.

ARTY: It's kind of like a design direction for products to be more customizable to meet the more codable for end users. So more kind of power end user capabilities sorts of things, but specifically customizable to workflow as opposed to forcing people into 'here's the one way to do the thing' and everyone needs to conform to the mole that's trying to support products and a product direction that allows the user to optimize their own workflow of their own experience. I don't know what you call it either necessarily, but I see your point.

JACOB: Okay. Just like tools that are very complicated and inside them, there are a lot of assumptions baked in about how you want to use them and what problems you have and what you're trying to do. And then there's the opposite end of the spectrum, like a Google doc. We're just giving you a pallet to type some words into and you can do with it all kinds of different things. And on one hand, we have this really complicated system and baked into it are lots of assumptions about what you're trying to do. I really like is the happy medium between that. I really love Trello because it seems like it's this sort of happy medium between structure and not too many baked in assumptions about what I'm trying to do. It's just columns with cards. So I can just do whatever I want and there's all kinds of applications I want. And then you can use 'if this, then that' or 'if that, then this'. You can use IFTTT that can let me connect it to all kinds of different other things in the way that I want to do them. So I think that's the biggest challenge is how can you give people the ability to bake their own assumptions into the product you're giving them?

CHANTE: Yes. If I was a developer that's what I would be. I would be interested in working on things like that where it's giving people more ownership and more customizable options for personal optimization and eventually that would contribute to better workplaces.

JESSICA: It gives you paths for learning and paths for continual improvement that are directly related to your work. What I really like about it is it draws us into changing the system we're in instead of just existing in it. It lets us be people, like full participants in the system because fully participating in this system means changing the system, not just moving your hands in the way that someone else decreed you are useful.

JACOB: Yeah. My team recently, we still have the same task management software but we kind of overhauled the way we had set it up where we sort of had a talk and it's like, "Wait, you're doing it this way. And when I do it, I'm doing this way." And we sort of had this discussion of like, "Oh, we're kind of all using it a little bit differently." And then we sort of talked about, "Oh, it would be great if we had this workflow and we could set up the task management software with different columns that basically modeled the workflow that we think would be more or less appropriate for all of us." And then we sort of talked about what's the right balance between that? Because we don't want to try to get super detailed and sort of shoehorn everybody into sort of one very specific process that is going to work for everybody or that will work for one person maybe, and everyone else is sort of forced to, like you said, just sort of move their hands. But we want to have something where the common elements of workflow that everyone's going to do it that way. Almost like the public interface, right? Like this is what everyone's doing the same way. How can we model that in our software? So there's a really good mesh between the task management software we're using and what people are actually doing and actually want to do.

JESSICA: I like how you start with first observe what people do, observe the system as it is. That's such an important part of really understanding and then identifying the parts that you do want to change.

JACOB: Yeah, because we had no idea. I had never asked those questions with my team before. I didn't want to seem like a pest and being like, "Wait, there's this button here. I never use it. Does anyone use it? Oh, no one uses it." Does it signify anything in anyone's sort of actual cognitive brain? "No, we're all just clicking it." "Oh okay," as soon as that was said. Because I don't mind to click a button if it's meaningful for other people to sort of flag to another person a certain state about a project even if it doesn't really mean anything to me. But when it means nothing to anybody, then again that's like more cruft in sort of the cognitive load.

JESSICA: Exactly. If I have to think about, is this a floober feature or not? Not a floober feature. Oh, nobody cares whether it's a floober feature, then I can stop thinking about that.

JACOB: What's a floober feature?

JESSICA: This was a totally arbitrary word that I made up because I needed a concrete example.

JACOB: Got it.

[Laughter]

CHANTE: Like bug versus a feature? Kind of that type of thing?

JESSICA: That kind of button?

CHANTE: Yeah. [Chuckles]

JESSICA: Sometimes there's maybe someone working on a process change in how we store customer to IDs and maybe they need to know any features that are going to go in that hit the customer table because it's going to affect their work in progress. And maybe they make a button in JIRA for that and ask people to please flag any feature that affects customers so that they can go run a report and find out about those. But then six years later, nobody's running that report. They've left the company. Nobody knows why that button is there. [Laughs]

CHANTE: God, there's [inaudible] everywhere.

JACOB: Yeah, there is.

JESSICA: Now we know what that's called. It's called a floober.

CHANTE: [Laughs] How do we spell floober?

JESSICA: F-L-O-O-B-E-R. I'm sorry, Jacob. What were you saying? [Laughs]

JACOB: I think I heard it on this show that there was a research project where some researchers taught a group of monkeys to do some sort of random behavior. I think it was like climb a ladder.

JESSICA: Oh, yeah.

JACOB: And get some food. Or like climb a ladder for no particular reason and then get a reward. And then they started one by one taking those original monkeys out and replacing them with other monkeys. And they found that by the time that they had removed all the original monkeys, the new group was still continuing to do this bizarre behavior even though they didn't even know there was a reason for it.

CHANTE: Oh, that is just like, how do we get rid of that? Can somebody automate that out of our lives? Monkey see, monkey do. And then we adopt these old sort of like antiquated systems or kind of rules that don't really actually serve us or the companies that we work for. And this isn't just in companies, this happens even in families. There's like inter-generational things we pass on.

JESSICA: Oh, so true. So true. There was one that people would always, in this particular family, they would always cut off the front couple inches of the Turkey. And I was, "Why?" "That's how my mother did it." "Why?" "Well, that's how her mother did it." Somebody finally asked the great grandmother and she was like, "My pan wasn't big enough for the whole Turkey."

[Laughter]

JACOB: Love it.

CHANTE: You're cutting out the best parts. Stop it.

[Laughter]

JESSICA: Yeah.

ARTY: This is one of those things though that goes both ways and that when we learn things and we figure out effective ways to solve problems and then we can pass on the strategies and solutions for how to do the things such that you just do the thing and you don't have to worry about why you do the thing that way, you just do the thing, then it frees our mental capacity to focus on other things. And so we build up all of these technologies in the most abstract sense of ways to solve all these various sorts of problems. And our species has evolved to the extent that it has because of this incredible capability to pass on abstractions, to be able to mimic, to model, to mirror. We've got all these really cool social capabilities that on one hand have all these sort of like dysfunctional quirks and stuff that come with us where we get into these goofy patterns that are senseless when you take a step back. But at the same time, it's the same kind of dysfunctional patterns that are the same reasons and things that make life so beautiful that gives life the richness that it has too.

JESSICA: Yeah, that's true. And sometimes those things, they just become part of the beauty.

JACOB: I was thinking about legacy code. And I'm a more junior developer and I've been with my company for a year and a half now. And it wasn't that long ago that I was digging through a lot of legacy code for the first time and it was definitely the biggest code base I had experienced in my career. And the code almost is like talking to you. Like it's almost saying to this junior developer, "I'm right and the onus is on you to understand me." [Chuckles] And it's almost like a challenge. Like, "You need to understand me." And the really challenging balance is I could go on like a quest to say like, "This legacy code could be this. This bit here could be refactored." And I could go really far on this question and say like, "I want to refactor this and then I'm going to go upstream and reflector that and keep going." But each rung you go up that ladder and how much refactoring you want to do, you're potentially talking to more and more people. And either challenging, maybe they wrote the code and you're sort of challenging their way of doing it or you're just sort of trying to touch something that's closer and closer to sort of the foundation of the tower and you really, really don't want to knock it over. Where did this come from?

JESSICA: [Laughs] But that's exactly it, isn't it? That's exactly what happens. You start with why is this here and can I change it? And it just goes deeper. And then you dig deeper and then you're like, why is this under here? And then, Oh, that person left the company. But if you call them at this number -- [Laughs]

JACOB: Yes, that person left the company. Right. Yes, yes, yes, yes. That's why. Yeah, because again, it's code that was written by someone that isn't even there. And you hear people talking about like, "Oh well," I'll just use a fake name, "Greg wrote that code." "Oh Greg, he was great. We were sorry when we had to lose him." So it's like you look at the [inaudible] blame and says like, "Greg wrote this three years ago. Oh, I can't refactor that. Greg wrote it."

[Laughter]

CHANTE: And the same thing is true in families. You're like, "Why did we do this?" You're like, "Well, Uncle Greg did it." But you're like, "Who the hell is Uncle Greg?"

JESSICA: So there's a balance. I mean, it's easier to click the floober button than it is to do the investigation to find out whether you really still need to click it. So it helps to have those people who just can't stand the ambiguity maybe of why do we click the floober button. But also I think randomness helps because somebody's going to get lazy and, "Oh. No, I haven't clicked that button in years and nobody's complained." Maybe everybody stops clicking it slowly. There might be some selection pressure on these random processes.

JACOB: Yeah, I wish there was a tool. There's this new tool called CodeStream, which is basically like inline commenting in your code base. It lets you have dialogue that is mapped to specific lines in a specific file of your code base. And some other idea I had is like I wish that every commit, there was some way to sort of capture the committer's mental state.

JESSICA: Oh yeah, yeah. "Okay. Oh, you want to make a commit?" And then it takes a selfie of you.

[Laughter]

JACOB: Yeah, or it can ask you questions like, "How happy are you with this commit?"

JESSICA: "On a scale of one to 10, how likely would you be to recommend this commit to others?"

JACOB: [Laughs] Yeah, or like, "How long would you like to see this commit around? How long would you like to see this method here in this code base?" And the person said like, "I'd like to see this refactored in a month from now." And then that's a note, like someone else coming through.

JESSICA: If only Greg had left that information, you'd know that these lines of code did not need to be saved for his posterity.

JACOB: Yeah, exactly.

CHANTE: This can be a great idea for somebody next startup. [Laughs]

ARTY: I'm really curious how that ends up working in practice though. So I have a code base and then I cover it with little comments and stuff everywhere and there's some niceness about, okay now I've got all these things in one place. But it seems like that can easily become this whole new sea of cluttered information that now I have to sift through to find stuff and now I have to go through some random conversation threads to find. I can see that creating a whole new set of time sinks because we have a huge struggle these days with information overload. We're on this mountain of complexity that we work on top of where we depend on Google your way through it to be able to do your jobs or we depend on Stack Overflow and other people having run into these things a lot of times. And then when the world changes really fast underneath you and you've got all these new complexities with this world of automated infrastructure that takes some work to get set up. And I see a lot of places they get so obsessed with the challenge of faster, faster, faster. But one of the things that goes by the wayside is design conversations. When I started my career, we spent a lot of time talking about design. And I feel like a lot of that, we get in this mode of incremental change and we can only do one small thing from where we are right now. And so these longer term thinking friends, I feel like are kind of getting lost a little bit in the scrum of scrums in the constant urgency. I don't know. What do you think, Jacob?

JACOB: Yeah. Like people typing a few sentences here into some input and before you know it, years later, you've had tens of thousands of those couple of sentences in Slack and wherever else. And then it's a question of finding it all. This is maybe like a new career opportunity for people who are librarians and it's their profession to sort of figure out how do we organize data so that people can find it.

CHANTE: It actually reminds me of, I guess the analogy is like to health care. I have a healthcare background, so there's all these bits of information that are sparsed throughout a patient's record. And some of them, if you're old enough, have actual hard records. What we have done is we digitized those and we've made notes as we've digitized and downloaded and now we're iterating and we have new electronic medical records and what have you. And so we have all this disparate data. So there is AI and machine learning algorithms that are taking that disparate data and putting it all together and then making inferences and trying to understand what it means. So I just wonder like if there's a way, surely there is a way because they're doing it in that respect. So there's a way to apply that same kind of concept and thinking to what's happening in terms of code, on the backend, legacy code, because that's essentially what we're talking about here. It's really interesting.

JACOB: Yeah, it's a really challenging problem because I don't even know how to begin.

JESSICA: That's characteristic too.

[Laughter]

JACOB: Yeah. I don't know what heuristics I would even begin with about how do I decide what information should rise to the top or what information should be archived. I don't even know because there can be something super, super helpful that was said eight years ago.

JESSICA: Yeah. Historians do this work all the time.

CHANTE: Are there historians on coding, like on programming teams and the tech teams?

JESSICA: Informally, yes. There is that person you go to hear all the old stories.

JACOB: [Laughs]

CHANTE: Not it. [Laughs]

JESSICA: That person who's been at the company for entirely too long, but knows why some things are where they are and can talk to you about the manager nobody wanted to work for, but they're gone now. And now this person came in and so that's why this new bit is in this language and et cetera, et cetera, et cetera.

JACOB: Yeah. [Inaudible] must never extend such in subclass you have to use. Yeah, exactly.

ARTY: Interesting to me. It's come up a few times on the show before where we've talked about the story of a company and of its people, what's the narrative and putting effort into story crafting has come up a few times before.

JESSICA: Yup. But then programming barred.

ARTY: [Chuckles] And it's interesting to think about like if we imagine if we had sort of a formal historian/librarian type of role. Like let's say we've got the capacity and it's someone's job to help investigate information about what's going on, what things are useful, help to archive and tag those things in a way that makes it easy to use by the team, helps come up with -- how would you even do this? If you had somebody's capacity to do that role, what would you have them do?

JACOB: I think this is for a profession that is not mine because basically that's what librarians do. I know that librarians these days are learning about [inaudible], that they're trying to answer those. And because it's like trying to drink from the fire hose and again, like tens of thousands of one and two word strings or two-sentence strings that were just shot over in Slack and they were helpful to a person at that time but no one knows where to put them. And so they're just all stuffed into the closet and then you go open the closet and they all sort of come falling out because they weren't put in a shelf anywhere. I think another question is like how can everyone on a team take responsibility for that sort of thing and like how?

CHANTE: Coming from the organizational sort of I guess leadership and development in that realm of an organization. I think what I would call that is succession planning where I'm trying to think about those opportunities where there is something of a legacy that we would want to keep on, that we would want to have to inform us of the work we've done, all the things we've learned in the past project and like what's going to stay, what's not going to stay. But I think what I've seen happen in companies that are kind of newer or smaller, leaner, is that they have task force or committees set in place that kind of are taking the onus of succession planning. But if you're big enough, you have actual department that does that, so that if you leave your job and you go on leave or something should happen to you that we kind of know that we don't lose it. But yeah, not every company has that capability.

JACOB: And they're planning for an arbitrary person in the company to leave?

CHANTE: It could be that arbitrary person or a really important function of the team, like the legacy kind of role would be leaving. Like, "This old kind of administrator of this such and such database, we need to know because we're going to be changing in the next three years and adopting something new. So we're going to make sure that we basically document and keep up with everything that's really important for us to understand if you should die or leave tomorrow."

ARTY: I was like imagining that whole process of please prepare the manual of all the things this person should need to know and then you get somebody new and they look at this book of stuff and it's totally out of date and mostly useless information kind of thing. And I just, in practice, trying to take that tacit knowledge and transfer it to someone that it isn't even their job. Some other department that is supposed to be able to manage this seems an extremely difficult challenge that increases the likelihood of mutations [inaudible] game stuff. And then I think in general with respect to passing on knowledge to the next generation of people that will continue this company, this team [inaudible], we all have a role to play in nurturing that sort of knowledge information garden for both the people that are there right now. I mean, the things that happened yesterday can be things that are super useful and helpful today. Like the bug that Joe worked on figuring out how to fix, I just got an error message so it looks really similar to that one that he ran into last week. How do I find out what information he used to solve his problems so that I can quickly use it to solve my problem that I'm facing right now? There's like all of these little everyday links and things in the team. And one, there's like this responsibility that we all have to somehow kind of extract it from our brains and put it in a form that is useful for us, like be our own consumers of the information that we're building as opposed to building a database for someone else. I think we can just shift to a mode where we're doing the thing for ourselves. I wonder if you had a person embedded on the team in this sort of library and the archivist type role, how would we use this person? It's interesting to think about because I feel like if we get into this mode of this increasing difficulty with the amount of information that we have to manage and Jacob's like library and this is what this role is. It's the person that's got all the indexes in their brain that helps all the other people find the indexes. And whether those indexes are to code things or old stories or whatever those are, there's this role of librarian brain [inaudible] how do I organize little things? I think that's one of the key problems that we face in figuring out how to solve in kind of the next generation of software is this information management problem.

CHANTE: I have a question to ask about that. Does anybody here think that maybe super computers have the capability of doing that for us? Is that a task that we can outsource to a computer because they can move much quicker and consume lots of data and basically distill it down to like, this is what is most important or this is like totally not worth your time. And I'm just curious in terms of -- I keep going into the future of work and how this type of thing is going to free up people's time or not. Just curious about that.

JESSICA: So if you have really good search, you can get the computer to help you find the information you need. But constructing a story is extremely human.

CHANTE: Yeah. Greater than code, for sure. [Chuckles]

JESSICA: And bringing it back to the personal automation theme. This is a matter of collaborating with computers that computers are most powerful in conjunction with humans in a socio-technical system. And when we make them work with us, as Jacob has been talking about, smoothly in ways that they get to do the tedious work and we get to make the decisions and tell the stories. That's when we're all the most powerful together.

JACOB: Yeah, but not too many decisions and not too few. We want to make high decisions. We want to say I'm deciding that I want broadly speaking this and I'm going to rely on you, the computer, to use common sense that I'm going to define broadly.

JESSICA: Ha! Common sense.

JACOB: Yeah. And I'm also kind of a fan of systems where we don't try to make them do it perfectly. We try to make them do it 99% of the way and then be smart enough to flag the things that they think [inaudible]. And then so you can say like, "I archived all of this and then I don't know where this one goes. What box does this go in? You tell me."

JESSICA: Right. Yes. So part of that collaboration can be consult to human when you don't know. But often from the context of what directory you're in and what branch you're on, the computer can figure it out. And the other thing -- well, whatever. I have a whole talk about this. [Chuckles] It can present you with these are the things that I think we should do and let you override them.

JACOB: Yes.

JESSICA: Is this a good place to move to reflections? I feel like I just did mine.

CHANTE: I actually like the term that you brought up, socio-technical systems. I had never thought about that and that is something that I'd want to explore more of. I think that this conversation could be a segue into another one. I guess the other takeaway from this is just thinking about personal automation versus for the greater team or for the family or for whatever and how those of us who are not technical might be thinking about that and take some lessons from the technical community and apply it to our lives.

JACOB: I was just thinking about how since code-based librarians is a profession that doesn't exist yet, that I know of. I was just thinking about what can I do not as a librarian, but as someone that has information to organize about a code base and about a team's function. What can I do in my own capacity to better organize and that way, I can leave a positive legacy, not just in the code base, but in terms of a story about [inaudible].

CHANTE: I love that.

ARTY: Yeah, and a conscious story.

CHANTE: A coherent story.

ARTY: My takeaway from this episode was the whole discussion we had about what are the ingredients to light your spark and your fire about software and how that makes such a difference when you're on fire to loving what you're doing and having fun, and all the coolness that comes with the experience of being able to build that little magic button that automates away the thing that drives everyone crazy all the time and stuff. Software really is magical power.

JESSICA: Yay. This has been yet another lovely episode of Greater Than Code. Jacob, welcome to the panel officially.

JACOB: Thank you.

CHANTE: Yay. All right. We'll do it again next week.

JESSICA: See you there.

CHANTE: All right. See you there.

JESSICA: In the meantime, if you miss us, you can contribute to our Patreon at Patreon.com/GreaterThanCode. And then if you like, you can join us on our Slack where we chat about such topics and are very nice to each other. The end.