Skip to main content
PodcastsThe CTO Studio

Ep.122 Doing Work As A Means Of Discovery

By April 15, 2021September 5th, 2021No Comments

Are you a technology professional looking to connect with like minded people?

We have a thriving community of CTOs discussing these episodes and more.
Click HERE to set up a call and learn more about becoming a member.

About The Speaker:

Check out the latest CTO Studio featuring Aaron Longwell. Aaron is the Director of Engineering, INL Justice Sector Support Program and is building the app that hosts all of the Afghanistan Legal System.

Episode Resources:

Check out https://7ctos.com/

Episode Transcription:

 

Nickolai Walker: [00:00:08] Hello. Hello, this is Nick. This, of course, is the CTO Studio. Welcome, welcome I’m on the mic and in your ear. My favorite place to be. We are back with another episode for you. We are joined in studio with Aaron Longwell, who’s the director of engineering and the man in charge of building the app that’s going to host all of the Afghanistan legal system. A daunting task, if ever I’ve heard of one. So we’re going to let Etienne take over from here and start to ask a really poignant question, albeit longwinded.

 

Etienne de Bruin: [00:00:39] You know, the brain’s fascination that comment you made about where there’s a gap for me, but there’s this other place I need to go to to find the answer. And that really there’s then a a mystery around that or a wow, you know, how do they know it? Like even if you look at talks on Ted or, you know, when someone expounds knowledge, there’s the brain is fascinated with that and kind of goes into a bit of a frenzy, like, how do I relate to this? Why haven’t I learned this? What are the dots? Where’s the other line? Oh, this fits neatly into this other thing I learned, so now there’s a different conclusion. And it’s like there’s a frenzy and maybe it’s just my head.

 

Aaron Longwell: [00:01:32] No, I think it’s everybody’s I think I mean, I think one of the things, you know, working on a book around this topic and one of the things I’ve struggled with is like how much to make this a personal story versus, you know, a more non-fiction, sort of impersonal, just tell the facts sort of thing. Because I went through this transition personally. I remember when Ruby on Rails first came out and I sort of was like, wow, this this David Heinemeier Hansson guy. He’s just like working on this project and he decides to use this language that has no good Web tools, but he sees the language, he likes it. And he’s like, I’m going to build this thing. And Basecamp I think was what he’s building and he’s like, I’m going to build this in Ruby. Even though there’s no tools for that. But I’m going to make them right. I’m going to I’m going to make a framework in the process of building Basecamp, just like the thought, like, oh, I could never do that.

 

Aaron Longwell: [00:02:38] He must be a special kind of person, et cetera, et cetera. And what I’ve kind of come to realize over the past couple of years is that all that really is is literally doing it. He didn’t know how to do it when he started. He literally figured it out as he was doing it. Nobody knew how to make Ruby do Web frameworks. And it could have been a terrible idea and he could have failed. He didn’t fail, which is why we talk about him. But it doesn’t mean that he shouldn’t have tried. He had a passion, that he really liked Ruby and he would prefer to work in that language for his Web project. So he did. And that’s kind of it. It’s not, you know, like, oh, if there’s not a book out there, it’s not possible, you know? I think too often we sort of view like, oh, I’ve got this hinge in my brain. I just open up and plop some new information in.

 

Etienne de Bruin: [00:03:39] Well, I think the challenge is when DHH then does that. How do all our brains relate to that type of. Doing. And then what mental image do we create not only about him in this case, but about ourselves and how we relate to knowledge? Because they must be a part of all Ruby people now saying, some variant of would DHH have done this. What would DHH think about this? And DHH is like, dude, I just want to code and and do the Le Mans and and I’m good. I’m happy.

 

Aaron Longwell: [00:04:24] Right. Exactly. Yeah. You don’t need his approval to to do something like I think. I think the thing I guess one of the ways I would put it that I’ve realized is that, you know, the completed thing is its own argument. You know, I’ve worked on teams before where there’s people who just talk and talk and talk about, oh, we should do this thing, I think we should do this thing, and they can’t convince people and they’re doomed. If you just do it like whatever in whatever form, just go, you know, take some time, code something. And so I did this thing and now look at it. That’s a completely different kind of argument because all of the fear and uncertainty are gone with oh, that’s not possible. Now, you know what it looks like. I think we’ve actually been on a project in Afghanistan introducing poll request based development. And I think one of the things that has come out of that is the realization that, oh, I can do work in a way that might get thrown away, but in a way that demonstrates, OK, I think we should do this. And I’ve I’ve tested it out.

 

Aaron Longwell: [00:05:36] Here’s how it works. And the combination of automated testing and poll requests are kind of trance. I mean, this is for a lot of our audience, probably is not going to be as eye opening. But it’s like those two things in combination enable you to do experiment, like evolutionary experimentation, to try something and say, OK, it failed, but the impacts of the failure are zero. We can just close the poll request and there’s no problem. We don’t have to put it in production and see that it failed or whatever. And I think, you know, the taking that a step further, maybe more for our audience, like the chaos engineering type approach, takes that even further further and says, OK, put everything in production, but make sure you monitor production so well that you know precisely when and where it’s failing and you can undo it as quickly as possible and is even more empowering, because then you you don’t see it in a lab, you don’t see the poll request, how it’s going to work in the lab, you see how it works in the real world and experiment with it. But yeah, that’s a whole other level. We’re not going to teach that yet on our project.

 

Etienne de Bruin: [00:06:58] I love that statement. The completed thing is the thing or what did what did you say? That is a theme. It is its own thing. You’re right. Completed work is its own… I was in a conversation this morning with with people about value stream mapping and all that. And just taking a process, taking a dry erase marker and going to the whiteboard and document and just drawing the steps from beginning to the end. Just is its own thing. It’s like, oh, OK, so yes, there’s all these blank boxes and yes, maybe I couldn’t get to the end. But you’re allowing that brain of yours to say, let me lean into the unknown, the things I can’t explain to create this thing that becomes its own.

 

Aaron Longwell: [00:08:04] Oh, it is its own argument. The completed justification, I guess. Yeah. Yeah. I think that I mean, so much of the challenges we actually solve are really boiled down to communication and code is communication. So like the PR example I’m talking about here. You have this vague vision in your brain about how we could do something differently. It would be better if we use this component or this library, the SQL driver or whatever. And I know it would be better. I just feel it. But if you do it, if you just lean into it and code some, you know, I’m a huge fan of code spike based development. You just go try it for four days or whatever. Take the time. Leave gaps in your your schedule to allow to do this and then go experiment with something and just be totally OK with throwing it away. If it didn’t work and if it did work, then make the time to figure out how you integrate it into the world. But that’s essentially that code spike is you communicating with the system and with the team some other vision of the world. And I think value stream mapping does the same thing in terms of how the business works. We all think we work at the same company, but that company looks completely different from everybody’s views and value stream mapping as a way to get everybody. To communicate about how they see things different.

 

Etienne de Bruin: [00:09:46] Yeah. Like I’m working with a team right now around alpha testing. Beta testing, customer migrations and then go live. And I’m just amazed. I consider myself a good communicator in the C suite. I’m an experienced CTO type. But I can just see the unraveling of what I’m trying to communicate and what I’m saying, it almost happens in slow motion. Where your brain just says this shouldn’t be happening. I thought this was an easy thing to explain. And the more you explain it, the more it doesn’t land and the more confusing it gets. And then then it’s almost like that mess then turns around and looks at you and is like, well, you are a horrible human because you couldn’t explain something that was supposed to be simple. Right.

 

Aaron Longwell: [00:10:52] What do you do to get past that? I mean, that’s a challenge we all deal with. Like how do you learn from those situations and what do you do next?

 

Etienne de Bruin: [00:11:08] So I have two answers to that. The first answer is and my wife just recently accused me of this. It was a very hurtful moment, brother. Kath, if you’re listening, you know how hurt I was. She’s rushing to download my podcasts. No, no. This is actually a super private moment that the whole world can hear and she won’t.

 

Aaron Longwell: [00:11:39] It’s like there’s an old Ninety-seven song where he’s talking about some emotional moment. And the song lyric is I won’t tell a soul except the people at the nightclub where I sing.

 

Nickolai Walker: [00:11:50] That’s really, really funny. This is between me, you and the planet. It’s what you’re doing right now.  Thanks again for joining us here in the studio. And thank you to Aaron Longwell, who is the director of Engineering INL Justice Sector Support Program, Afghanistan. Please go check out his LinkedIn. Also, go check out 7CTOs.com. And while you’re at it, subscribe to this podcast available in iTunes. We will see you next time with another interview with Mr. Aaron Longwell.

Are you a technology professional looking to connect with like minded people?  Sign up to get connected with 7CTOs!

Please rate and review our podcast!

Click Here for iTunes