03
05.29.2020   /   duration: 47 min
The Experience Lab
Architecting a Developer's Journey

Architecting a Developer's Journey

On today’s episode, Rob is joined by Solution Architect and veteran developer Josh Brown for a fascinating conversation about life as a developer, modern approaches to software solution architecture, and some twists and turns through the cosmos. Josh peppers the conversation with important wisdom from nearly two decades of experience building software and leading other developers. Note: this episode was originally recorded in April, 2020, in the midst of the COVID-19 shutdown.



Hosted By

Rob Hall
senior director of product

Special Guest

Josh Brown
solution architect

Episode Transcript

Josh Brown: When you are born, we want to know what the constellations were in the sky at the moment of your birth, right? And the one that’s just on the horizon is your rising sign. And so that’s kind of going to color everything about you in this life. Kind of. It’s like a tint that you see everything through.

 

Rob Hall: This may not be the conversation you expected to hear about bugs, writing code, but a conversation with Josh brown rarely goes as one might expect.

 

Josh Brown: The sky is split into 12 sections 12 houses, and each house refers to different aspects of your life. Each house is essentially going to be assigned an astrological symbol, and then the planets and the sun and the moon are all going to be in different configurations within those. 

 

Rob Hall: Josh is the solution architect at Digital scientists. He is the consummate philosopher. Always looking beneath the surface, seeing what others rarely see.

 

Josh Brown: If you’re working on software that’s not put together by someone who’s very disciplined is like a true Virgo at heart, and who has everything organized and has all the systems set up, then it tends to just be kind of messy. Because people come in, they’re given a task. They accomplish that task, and they’re not really trying to leave it better than they found it.

 

Rob Hall: Today, I accompany Josh in a meandering journey, where we talk about bugs, how they happen and how to minimize them, code patterns and standards and good developer practices, and among many other things, maybe even the meaning of life itself.

 

Josh Brown: Pro tip.

 

Rob Hall: This is the experience lab, the official podcast of Digital Scientists from Atlanta, Georgia. We’re an experienced lab that explores and builds digital products. My name is Rob Hall, and I’m the Senior Director of Product at DS. Thanks for listening.

 

How’s your day been? 

 

Josh Brown: Busy.

 

Rob Hall: Yeah. What have you been up to?

 

Josh Brown: The Coronavirus quarantine.

 

Rob Hall: Oh yeah. I’ve been pretty busy with that too.

 

Josh Brown: I mean, it’s just weird. You work from home and like other things just come up. It’s just different. It’s like it breaks your normal flow. And so

 

Rob Hall: Have you found yourself being more productive or less productive?

 

Josh Brown: I’ve actually kind of found myself having more stuff to do. 

 

Rob Hall: Really? 

 

Josh Brown: Yeah, like drastically. I feel like I’m twice as busy as I was before quarantine.

 

Rob Hall: It’s interesting you mentioned that. I was talking about this with some folks yesterday and today. It does feel like on the whole we’re busier. 

 

Josh Brown: Yeah.

 

Rob Hall: I know, like, I’m starting work around the same time as I normally do, but I don’t feel this urge to stop as early as I normally do. So I’m not trying to beat traffic to get home or whatever. But I feel like my actual working hours are also busier.

 

Josh Brown: They’re busy. Yeah. And there’s kind of a there’s like a weird, there’s just some weirdness where I’m not I’m not like a work from home person. So I don’t have a bunch of experience with it. 

 

Rob Hall: Right.

 

Josh Brown: But you need to step away from your computer some. 

 

Rob Hall: Yes. 

 

Josh Brown: And so I feel like I have a little more guilt with that at home than I would at the office. 

 

Rob Hall: Yeah.

 

Josh Brown: So something about that is not  exactly honest yet. 

 

Rob Hall: Like, what do you mean by that?

 

Josh Brown: I mean, like my, my relationship to it, it hasn’t like hasn’t fleshed itself out. Like my emotional response or whatever, right? 

 

Rob Hall: Uh huh. So would you say you’re just becoming aware of it as a thing.

 

Josh Brown: Oh, no, I mean, I think I’ve been aware of it. 

 

Rob Hall : Okay. 

 

Josh Brown: But I don’t always know how to deal with it just because you’re aware of it doesn’t mean you know what to do. 

 

Rob Hall: Right. 

 

Josh Brown: Just means you know it’s there. 

 

Rob Hall: Yeah, exactly. 

 

Josh Brown: Oh, it’s like, now what. Yeah. It’s like, I had an interview to listen to for the CRM today. I had a bunch of them to listen to for the CRM today. And they’d sent me some, like, a bunch of videos to go over for the design sprint process. All that stuff takes time. I’m also putting a bunch of time working with Biff, you know.

 

Rob Hall: Right. 

 

Josh Brown: And then it’s like, well, I need to get my emissions done. 

 

Rob Hall: Are they still doing that? 

 

Josh Brown: Turns out I can answer that and the answer is yes. At least for me for today, I’m not sure that it’ll what’s gonna happen tomorrow. I’m not sure if that’s an essential services or not. I mean, not a it’s good that we have like emissions test. It’s good that the cars don’t pollute as bad they used to.

 

Rob Hall: Yeah. 

 

Josh Brown: But uh,

 

Rob Hall: I think it is important. We don’t use leaded gas anymore. 

 

Josh Brown: Yeah. Although car engines love leaded gas, so I’ve heard. 

 

Rob Hall: Yeah. So, it’s funny you mentioned that. Like 20 years ago, we were on a mission trip with my family in Africa. We were in the lower part of Zambia. And it may still be this way over there. I’m not sure. But at the time, all the vehicles that weren’t running on diesel, were running on leaded fuel. 

 

Josh Brown: Yeah. 

 

Rob Hall: And so if you were to ship an American car over there, you had to remove the catalytic converter.

 

Josh Brown: Right.

 

Rob Hall: From every car. 

 

Josh Brown: Yeah. 

 

Rob Hall: So that it can run unleaded gas. But I could understand why it was such a pollutant. I mean, just from the smell of leaded exhaust, it’s awful. 

 

Josh Brown: Yeah, and I mean, you don’t want led around people for the most part.

 

Rob Hall: No.

 

Josh Brown : It destroys the nervous system. 

 

Rob Hall: Correct. Or if you’re Superman and your X ray vision.

 

Josh Brown: You can even get into a little, little conspiracy about that stuff if you want to dive down there. 

 

Rob Hall: I figure with you, we could get into conspiracies about many things.

 

Josh Brown: Probably.

 

Software exists in two domains. It exists, you could say like esoterically and exoterically. So there’s, there’s the software that the developer sees, which is the esoteric side is the inner workings of it. 

 

Rob Hall: Okay. 

 

Josh Brown: And then there’s this the external aspect of the software and the UI and the interface and what the user is seeing

 

Rob Hall: The user experience

 

Josh Brown: Right. You know, bad software is very generic thing to say. And you can really, you can cut across that and so many different ways. You could consider software bad if no one uses it. 

 

Rob Hall: Right.

 

Josh Brown: You could consider a bad if it has a bad UI, if it has a bad architecture. If you open up, look under the hood, and it’s full of exceptions to the rule, or patches or kind of fixes for things, I would consider that to be bad software just because it’s difficult to work with. 

 

Rob Hall: Right.

 

Josh Brown: Difficult to work on. So on the esoteric developer side, like that’s the part that is going to be a red flag for me. That’s typically I think, when you start talking about bugs, like I think that that kind of plugs into the buggy nature of a system. It’s like the more complicated it is, the more cognitive overhead there is. The more hidden dependencies you have between things, the more likely you are to end up buggy.

 

Rob Hall: So you’ve used the leaky dam analogy before with me and talking about bugs. And I feel like in past projects, you and I’ve experienced that where you’re, you’re chasing down all these bugs. And then you realize another one’s popped up over here, because you’re in this rush to try and fix things.

 

Josh Brown: Yeah, yeah.

 

Rob Hall: It almost like creates this anxiety.

 

Josh Brown: Of course.

 

Rob Hall: The product experience side versus the developer side, as well. We’re here trying to manage expectations and keep everybody calm and extinguish the fire whereas you’re on the background going, “Okay, I need everybody to calm down.” 

 

Josh Brown: Right.

 

Rob Hall: Let’s breathe for a second. We’re gonna get it fixed. But if I push this fixed now, I don’t know what it’s gonna do somewhere else.

 

Josh Brown: Yeah, that can happen. So these systems that we work on, get complicated, and we just have except the fact that like the systems get too complicated for one person to fully comprehend. Most systems are that way. Like the economy is too complicated. Nobody. you know, nobody understands it. Sorry, but nobody does. Nobody accurately predicted all the time or even a little bit of time, apparently. So it’s like that the system gets too big, you have unrecognized relationships between things. Or you have coupling that you just you didn’t account for or don’t know exists. So you make a change, and it has a has an effect that you didn’t perceive. And that’s kind of the idea behind the leaky dam is like, the dam cracks. You put your finger to plug one hole, and then another one pops out somewhere else on the dam.

 

Rob Hall: So how do you when you when you’re stuck experiencing that? How do you mitigate it? How do you mitigate the leaky dam? Do you have to just bust it open and drain the lake and hope for the best and then rebuild or do you call in backup and get more hands to plug in the holes? 

 

Josh Brown: The industry is really has answers for this, and has had answers for this for a while. So you want to have a set of automated tests, if you have to have some user testing to back that up, you can do that too. But that’s really the best way. People don’t often talk about this. This is like, you know, people talk about regression testing and integration testing and unit testing and whatever. But there’s actually another class of tests that exists called characterization tests. And you can actually leverage other tests to be characterization tests. But the idea behind a characterization test isn’t to check that software is returning the correct data value, we’ll say. It is to make sure that the software is returning the same data value that it was returning five minutes ago before you made your code change. 

 

Rob Hall: Oh, interesting.

 

Josh Brown: Right. It’s like the characterization is checking the integrity of the system to make sure that certain aspects haven’t haven’t changed their output as the result of what’s going on. So out of a lot of your testing, you actually get a little bit of characterization tests just by default. But to me, that’s kind of one of the things that’s going to help, like shield you against pushing things up that are going to be buggy.

 

Rob Hall: So it seems like if you have reached the point of the leaky dam scenario, you’re in trouble. You kind of have to make your cross and pray and hope for the best or be willing to blow it up and begin again. 

 

Josh Brown: Yeah. 

 

Rob Hall: Whereas the approach that you’re talking about with test driven development seems more like a prevention measure. 

 

Josh Brown: It is you.

 

Rob Hall: That you want to build in and plan for ahead of time, rather than after the fact.

 

Josh Brown: It is, it is, but like if you are in a situation where you didn’t practice TDD on the way up, or maybe you inherited some software that doesn’t have a bunch of tests written for it. And you need to push up some code, you have to push up a change, like you can write characterization tests. You know, at any point in time, that’s actually, that’s where characterization tests come from is when you work with legacy code. That’s what that’s how you have to write tests around it. Right? Because you don’t always know and you don’t have the time, or even the know how to go back and like, check all the math everywhere. 

 

Rob Hall: Right .

 

Josh Brown: You can’t go back and comprehend every line of code and in something you’ve inherited. But you need to make sure that what you’re doing isn’t, isn’t messing it up.

 

Rob Hall: I’ve also heard you talk about cognitive load. What does that mean? 

 

Josh Brown: Yeah.

 

Rob Hall: I mean, to me, I interpret that at least as a product manager, I interpret that as I’ve been switching contexts, and having too many phone calls in a single day, and I need a beer.

 

Josh Brown: Right, right. Right. Yeah. I tend to think Cognitive Load is like how many things you’re trying to keep in short term memory at once. Like you can only keep like seven things in your short term memory at once, like, geniuses can keep like 11 things or something. I forget the numbers. 

 

Rob Hall: Yeah 

 

Josh Brown: Yeah, that’s a different type of memory. If you have a million details you’re trying to manage in this place, it’s hard to think it’s hard to think and a little bit bigger picture. Yes. When you have too much to think about, it gets difficult to work with. 

 

Rob Hall: What can create that scenario? Is that, for example, too much abstraction? 

 

Josh Brown: Well, yeah, for sure. Too much abstraction I think I can do that. Doing, like when you have a system that oftentimes you’ll see you’ll work with software. Maybe the dev was just bored with old code, or maybe there were a bunch of devs who worked on it, and they didn’t want to follow the patterns of the previous coder. So they’ll do the same thing and fix different ways. 

 

Rob Hall: Right. 

 

Josh Brown: And now you have to keep track.

 

Rob Hall: Or cleaning up their messes.

 

Josh Brown: Yeah, well.

 

Rob Hall: Like legacy code that’s not used, but it’s still there.

 

Josh Brown: Yeah. And unfortunately, there’s a deficit and coders who want to clean things up. 

 

Rob Hall: Why is that? 

 

Josh Brown: I don’t know, I guess, you know, in some respects, I don’t really think that’s a quality that I don’t think it’s really cultivated. It’s not really fun. It’s kind of like cleaning your room. You know, if you are someone who enjoys organizing things, then I could see, maybe you’d enjoy that. But a lot of people don’t. A lot of people are kind of itching to just get the next thing to get their next feature out the door or implement whatever they’re working on. You know, to go back to these ways up

 

Rob Hall: Do my thing, get it done faster. 

 

Josh Brown: And I think sometimes, it could be that they don’t really see the value in it. I like convention, because it reduces cognitive load.

 

Rob Hall: And by convention, you’re referring to creating a consistent set of standards that you’re coding against.

 

Josh Brown: Yeah, basically, yeah, consistency, things that you can rely on, you know.

 

Rob Hall: Right. 

 

Josh Brown: It’s nice to kind of be able to guess, where something is like, “Oh, I need this, you know, to kind of guess where it’s going to be. And it is there.” That’s a nice feeling. 

 

Rob Hall: Right, absolutely. 

 

Josh Brown: Like early on in my career, I would get really bent out of shape. And when we pushed up a bug or something was wrong, like it would affect me emotionally. And I would feel like it was my fault. And I would feel like a bit panicked. And I just remember this one time where that was the case. The software was broken. And we were working on it, we hadn’t fixed it, and we went to lunch. And the dev that I was working with was just completely unfettered, like just unbothered by the whole thing.

 

Rob Hall: It did not affect him whatsoever that a bug had been pushed up.

 

Josh Brown: No. And, you know, I talked to him about that, like, why he just seemed so calm and placid about it, you know? And he just, he kind of just brought to my attention the fact that like, well, you’re not going to, like you’re not gonna solve it any better if you’re emotionally worked up about it. 

 

Rob Hall: If you’re frustrated about it, right?

 

Josh Brown: Yeah, it’s not gonna make you concentrate harder, think clear or act faster. 

 

Rob Hall: No. 

 

Josh Brown: And so that kind of opened up a whole world of possibility in thinking about that topic and the necessity to stay calm and relaxed in the face of things like that. Especially when your managers are worked up. You need to come back to them with calm composure, and just handle it.

 

Rob Hall: So it’s, it’s like a practice of acceptance. 

 

Josh Brown: Yeah.

 

Rob Hall: And it’s funny because we even call them we call it acceptance criteria. 

 

Josh Brown: Yeah, right.

 

Rob Hall: But even I mean, from my perspective, as a product manager, there is a level of acceptance that we tried to set expectations with, “Hey, Joe, Mr. Customer, there are going to be bugs.” 

 

Josh Brown: Yep. 

 

Rob Hall: “We’re going to do our very best through our process to avoid as many as we can. But they are going to happen, and here’s how we’ll handle it when they happen.”

 

Josh Brown: Absolutely. In it, that you know, this whole concept of like relaxed composure. I mean, this is like this is like ancient wisdom. This is an all the martial arts and all the soft arts. You know, being tense is not what you want. You want your opponent to be tense, right? You want to be relaxed, so that you can respond. That’s really like a desirable state. For a human in general, all the time. Just composed, collected, relaxed.

 

Rob Hall: Almost dispassionate in a way?

 

Josh Brown: Perhaps, no comment. Don’t know.

 

Rob Hall: Is there a type of personality that seems better suited for development work than others?

 

Josh Brown: So I don’t really think so. I think that I think that you, you have to have some, like mental horsepower to be a developer, because it is kind of like this analytical, you know, you’re thinking inside of a thought inside of a thought sometimes, like you have to be able to kind of – 

 

Rob Hall : Inception your brain 

 

Josh Brown: A little bit, you know, it’s definitely challenging. So if you’re not, if you don’t already have like, like I said, like some mental horsepower, you’re gonna need a strong interest in programming. Like, you know, I think that could work in its place. I think, just about anybody can learn. It is just you have to have the personality types interested in it. That’s really it. 

 

Rob Hall: Right. 

 

Josh Brown: But that’s kind of with anything like, if you’re not interested in something, and you try to do it as a career, like you’re going to suffer a bit.

 

Rob Hall: You’re going to be miserable either way.

 

Josh Brown: But there’s a lot, you know, the field is really varied these days. There’s a lot going on. So you can really have a lot of different personality types take on a lot of different roles.

 

Rob Hall: It seems like in the old days, you had a very clean line between back end development and front end development. And not a whole lot of muddied water in between.

 

Josh Brown: Right. 

 

Rob Hall: Whereas now, you had this huge shift towards JavaScript, and everything’s in the front end, and the back end was kind of more minimal, but then now we’re, we’re dealing with all these machine learning technologies and building learning models. So now, back end developments really turned into this whole other thing involving data science.

 

Josh Brown: Yeah, there’s that. And then like your, your real, real weird people go into DevOps. 

 

Rob Hall: Yeah. Are you into DevOps? 

 

Josh Brown: I mean, I enjoyed it a little bit. And then I feel like the the field has got to be a bit too much for me. It started moving too fast. 

 

Rob Hall: Yeah.

 

Josh Brown: Like some of that stuff needed to happen, but I also feel like everybody was a bit too quick to start implementing these things, or for projects and things that really didn’t need them. For smaller scale stuff that doesn’t really need an automated server farm that’ll load balance itself and whatever, like, you know, it’s just a WordPress site for somebody’s restaurant. Like, but then you know, you got all the way down on the other end. You had your used to just be like front end developers or whatever doing CSS and HTML, and they all do JavaScript now. But you can push past that. You can push past that to designers. And look at the prototypes that designers make. Right, compared to what that was 10 or 15 years ago. Oh, yeah, for sure. Just working in Photoshop files within 90 layers. 

 

Rob Hall: Yep. 

 

Josh Brown: Right, there coming in from that other side, and add more definition, which is really, really pretty good. And I think everything’s starting to speed up. I think development in general is speeding up.

 

Rob Hall: Yeah. What’s nice to see too, from the design side of things is is the ability to quickly articulate user interactions with just small animations and things that that took a lot of time to visualize for a developer. Even when we were starting to do all these things through CSS a couple of years back. It was still very time consuming, just to say, you know, just how to articulate motion. And the fastest way back then was was animated and After Effects and and hold on duplicate it. 

 

Josh Brown: I don’t know if this is true, but it really feels like you could almost take any, like, above average designer today and send them back 10 years ago, and they would be the best designer in the world. As far as, as far as like UI interaction goes? 

 

Rob Hall: Absolutely. 

 

Josh Brown: I feel like that whole areas come along so much. This is good. This gets a little weird. But there seems to be this like, relationship between humans and information. And we needed to start ramping it up. With the advent of the Internet, that kind of kicked off even more. So early on, it was like, well, we need to increase the bandwidth. Right. And once we kind of solved that problem.

 

Rob Hall: I need to buffer my videos faster. 

 

Josh Brown: Yeah, right. Right. Once we kind of solved that problem with broadband. Yeah, we’ve I mean, at least we solved it well enough for the time being. It wasn’t so much an issue of waiting on the dial up connection anymore to get your information. It was like the informations here, how do we speed up getting it to the human. And we had to switch sides and go to the UI, right? and smooth out the UI as much as possible, so that people can easily see they can easily visualize the data. Data visualization is a really big thing right now still, you know. And it just has sped up. And you can kind of see this across the board, like even like the concept of a meme is really dense with information. You know, it didn’t exist before in the same way. So kind of like SMS and text was affecting the language. It was shortening things like things are getting compressed. 

 

Rob Hall: Right, exactly.

 

Josh Brown: This is another place where you see that and like yeah, It’s so we’ve really worked on the UI. I consider like the first real big step in that direction was probably like, the Apple’s iPod Touch. Right? That was kind of the precursor to the smartphone UI.

 

Rob Hall: It is funny like the smartphone space is undergone like this whole parallel development. Because you had the old palm trios and the blackberries where everything was very button driven. And the screen was just there for feedback. 

 

Josh Brown: Right.

 

Rob Hall: It wasn’t your input device, and then the iPhone and the first iPod Touch, turned all that upside down? 

 

Josh Brown: Mm hmm. 

 

Rob Hall: I remember Steve Jobs in his keynote, introducing the iPhone was like, castigating everyone for using pointers, and stylus, you know, because we have the best pointer and God gave us five of them or 10 of them right?

 

Josh Brown: Right.

 

Rob Hall: It’s your finger is your finger. Now, there’s an irony there that now you know, Apple has the Apple Pencil and they just introduced trackpad pointer capability to the iPad and stuff –

 

Josh Brown: Yeah, right. 

 

Rob Hall: years later. But the point is it was a new mode of interaction for a particular set of use cases, that was far more efficient than what the trio and the BlackBerry could could do. But then the argument is still there. Well, that might be good for certain things on a small device, but you can’t replicate the power of a keyboard and a mouse.

 

Josh Brown: Right. But then it but at the same time, it opens up other things. Because you have swipe, you have two finger swipe. So you end up with a few more gestures. And then you have the other added benefits of the phone with the accelerometer, the camera. So they started to kind of reach out in different ways and give you a little bit of a different view into into that UI. And the smartphone now is I mean, that’s the most used computer in the world, right? People’s smart. 

 

Rob Hall: Yes. Well, and if you think about it, most of our smartphones are more powerful than the most powerful desktop computers were 10 years ago. 

 

Josh Brown: Yeah, right.

 

Rob Hall: And they’re only getting faster.

 

Josh Brown: Yeah. Because we’re spoiled.

 

Rob Hall: What would you say differentiates a good developer from a not so good one.

 

Josh Brown: The developers that I don’t like are ones that get projects into trouble. Right? And that’s usually means that they are not. I like if there’s going to be a big decision or a difficult decision. I think those need to be communal. I don’t think they need to happen in a vacuum. So in my opinion a bad dev will make a big decision by his or herself and not communicate it. They will not seek help, because they’re afraid of looking stupid. And so when that happens, they’ll continue to grind on a problem and make a mess out of it. 

 

Rob Hall: Mm hmm. 

 

Josh Brown: In my, in my experience in my career, those have been, it’s not like they’re it’s not like people are frozen in that state. I mean, everybody kind of needs to pay their dues and do this a few times. It’s just a more of a typically more of a junior level dev attribute is getting projects into trouble that way. 

 

Rob Hall: Right. 

 

Josh Brown: I think.

 

Rob Hall: If I just keep working, I will make it better.

 

Josh Brown: Yeah. Yeah. And they just like they’re avoiding that light. You know, they don’t want the light shined on them unless it’s positive light. And they’re just thinking too much about themselves, and they’re not they’re not thinking about the project itself. So the project is the goal. Not you being a star. Right?

 

Rob Hall: Right. 

 

Josh Brown: Probably what I would say I don’t really like devs that are heroes either. I think.

 

Rob Hall: Step aside, I can take care of this.

 

Josh Brown: Yeah, like, Oh, I worked. I worked overtime for seven months. It’s like “Oh, he said he or she is dedicated.” It’s like, “No, you’re just messing up the expectations of what our job is for everybody else.”

 

Rob Hall: I mean, I would I would make that argument for a product manager, designer, 

 

Josh Brown: Right.

 

Rob Hall: as well as the developer.

 

Josh Brown: Right. But it goes back, It’s an ego motivation, right? It’s a self, and we’re all we all have egos, and we are all self serving to a degree but.

 

Rob Hall: I guess

 

Josh Brown: But you know what I mean, like, it can, it can work against you.

 

Rob Hall: Yeah. So something you’ve said Brown is developing a sense of non urgency. 

 

Josh Brown: Yeah. 

 

Rob Hall: You know, it’s funny because we always work overtime, it seems, to cultivate the opposite in product managers, or anybody who’s customer facing. You want to develop a sense of urgency so we can be on our feet and responsive and exceed expectations. 

 

Josh Brown: Yeah. 

 

Rob Hall: And now you’re prescribing the opposite of that. Why is that?

 

Josh Brown: As a dev, I think you want a sense of non urgency. And that goes back to just being relaxed and composed. So if you’re relaxed and composed, I mean, the best developer or the best development team is relaxed, composed, they make decisions, and they make important decisions together. And the project moves in one direction, which is progress. Like, that’s what that’s what I want out of my teams. So if you have a sense of urgency, you’re more likely to make mistakes or have to go back and redo things. Right? But I like I want everything to be clear, calm, moving forward in one direction. And I think ultimately the turtle wins the race.

 

Rob Hall: Slow and steady wins.

 

Josh Brown: Yeah, I don’t really think there’s a problem with speed. I think this is kind of another thing that’s a little bit of a misnomer. If you want your project to happen fast, you don’t need a sense of urgency. You don’t need to crack the whip. You don’t need overtime. You need very clear descriptions of what’s required. You need good, good acceptance criteria, good user stories that show you actual detail. You don’t want your developer picking the color on your button, or whatever.

 

Rob Hall: Let the designer handle that.

 

Josh Brown: Yeah, it should be done. Right? When the developers know what’s expected of them, they work fast. 

 

Rob Hall: Right.

 

Josh Brown: They enjoy it. And so you’ll have projects that don’t have good definition to make up for not having good definition, the managers will attempt to crack the whip either in in, in an overt way, which is less common or in a passive aggressive way, which is more common. That’s just how it is. I mean, I don’t I don’t, I don’t think I managers are special in that way. I think most people, at least in our culture are tend to be more passive aggressive than active aggressive. And that’s okay. We should just try to not do that.

 

Right.

 

I’d like to go back in time, talk about how you got into software development to begin with. And then fast forward. Talk for a minute just about how in your experience developers can best be supported by product managers and designers because you’re coming at this from a breadth of experience, and a variety of experiences that a lot of developers, especially if they’ve only been doing it for a few years have not have not experienced. But you’ve also come at it from the perspective of someone who has seen technology move a lot over the last decade.

 

Josh Brown: Yes. 

 

Rob Hall: Or longer.

 

Josh Brown: Sure. 

 

Rob Hall: You are an old man now. 

 

Josh Brown: I’m old. Yeah. So I got in development. I was real good at math as a kid. And I was like, exceptionally good at math for my high school, I guess. And so I thought that that meant something. I thought, Oh, “well, I’ll go, I’ll get like a math degree.” I didn’t know what that meant, or where it would go, right? But I just assumed that like, everybody hates math. If I do math, I’m sure that I’ll get a degree and get out of college and they’ll just handing money. Right? It’s got nothing. 

 

Rob Hall : Yeah. It will make you indispensable.

 

Josh Brown: Yeah. Right, right, right. I went I did a four year degree in applied math. And it was a complete waste of time, honestly, like, I hated it. And I thought that, I thought math was different from what it was, I guess. And when I finished the four year degree, I was so disillusioned with the whole field. I thought it was just a huge waste of time. 

 

Rob Hall: Why is that? 

 

Josh Brown: I think for me, it’s a waste of time, because a lot of it just doesn’t relate back to the real world. Right? 

 

Rob Hall: So a lot of theory. 

 

Josh Brown: Yeah. And, you know, even if you do have things that kind of relate back to the real world, like getting somebody to explain how it relates back to the real world, like they don’t really understand it either. You know? And I was kind of finding that with my professors. I’d go, and I’d ask him some questions about how some of these concepts related back. And you know, they’d say, “Oh, well, you know, you can use this to describe electron orbitals for blah, blah.” And it just, it just wasn’t enough for me. You know, it just seemed like, it seemed like some smoke and mirrors. I don’t know. It didn’t, didn’t feel real. And I liked it with computer science, well, I did like the math involved with computer science. I like discrete math. I think it’s just more fun. And I liked with computer science, that when you work on something, you actually get feedback. You know, you’re making you’re creating something. 

 

Rob Hall: Right. It talks back.

 

Josh Brown: It talks back, like with math, it’s like, I remember having a test. It was a take home test. And there were like four problems. And they were proofs. And you could go home and you could work on a proof for like 10 hours and not be any closer to the finish line. At the end of 10 hours.

 

Rob Hall: Yeah, no, that’s demoralizing.

 

Josh Brown: Yeah. You know, so I demoted myself to computer scientists. And I went, and I got a master’s in computer science and did my thesis in AI, actually in a taboo search. And I gotta be honest, like, I thought that whole process was kind of a joke as well. I’m really not a big fan of academia. I think that there’s just a lot of people kind of patting themselves on the back there. And I did not publish my thesis. I had people reach out that wanted me to, to fix it up for him to publish it, but I just wasn’t proud of it, honestly. It just it didn’t really feel. I don’t know. It just didn’t really feel all that useful, really. So I finished. I finished grad school and you know, I needed a job. Instead of going out and getting a job, I started answering Craigslist ads for programming work. Just kind of weird, but that’s what I did. Right? 

 

Rob Hall: Yeah. 

 

Josh Brown: And I worked in a worked kind of just like weird contracts for people doing SMS. Back in the early days. This is like 2006. Five-six. 

 

Rob Hall: Yeah. 

 

Josh Brown: And they were doing shortcodes that was like it just come out. And they were doing like these campaigns and like, like sports stadiums and stuff like that. So I was kind of working on that stuff. And then I got paired with designer and we worked on a CMS together that we used for some kind of, I guess, pretty high level entertainment industry people back in the day.

 

Rob Hall: Did you meet any famous people?

 

Josh Brown: No, I didn’t ever meet famous people, but I logged in on their servers. That’s something.

 

Rob Hall: Yeah, congratulations.

 

Yeah, whatever. There really kind of are some inbuilt stereotypes about devs, about developers, about developers not being social, and about developers kind of being like a bunch of Spoks. And it’s not really the case, especially with the variety of the types of development now. You can really have people, especially a dev who’s been doing front end work for 10 years, is going to have good input into UI decisions. You know, yeah, just goes without saying, like, there’s just no way they can’t. Like, I don’t care if they have a degree in it. That doesn’t mean anything to me. You know, they have actual hours on it. I think that that’s, that’s part of it. But the, you know, the company that everybody works within has to really cultivate and find ways to get people communicating in order to kind of loosen up those restrictions, I think. Right? People need to be able to communicate freely and will say in a friendly way. 

 

Yes, respectfully. 

 

Josh Brown: It’s like if you do have people in your organization in your agency that, that have a hard time communicating with other people, there is a good chance that they’re going to be on the dev side of things. I get that. But it’s not the case that most devs are bad at communicating. I don’t think that’s the case.

 

Rob Hall: I think it’s just the weird DevOps guys that you keep talking about.

 

Josh Brown: Yeah probably, I don’t know.

 

Rob Hall: No, I mean.

 

Josh Brown: Like you never know. You really never know.

 

Rob Hall: No in truth though, you bring up an interesting dynamic that I’ve observed with some of our clients in the past, where you will see the head of their technology group. So, CIO or a CTO depending on how they distribute the role can be very isolationists, annd protectionists over the things that they have built. And I one hand you can relate to that. You can go, “you have these complex systems that you have built and you have refined over many years. You’re literally the train conductor, and you’re doing a great job keeping the lights on. Without that infrastructure operating the way it does, everything would fall apart.” Then on the other hand, I think that attitude or that disposition can fall into complacency and a resistance to continuing to move the product forward to answer new challenges that the market is demanding. 

 

Josh Brown: Yeah.

 

Rob Hall: So a lack of innovation. A lack of cooperation and collaboration, I think are the effect of that attitude, that disposition. 

 

Josh Brown: Yeah. 

 

Rob Hall: And I think it takes a unique individual to be able to to balance both priorities. Yes, we still need the trains to continue running on time. But we also need to continue evolving the quality of the seats on the train.

 

Josh Brown: Yeah. What’s not always the case that one person can do that. You know? I think, I like to think in terms of, I think that people just have different qualities that they’re good at. I think everybody should kind of be aware of what their qualities are and what other people’s qualities are, you know? And maybe you are the type of personality that’s really good at building foundations and maintaining that structure. You know, maintaining stability, but you’re not, you’re not the type of person who’s bringing in winds of change. You know? So maybe you need to seek out somebody who brings in winds of change, or you need to tap into somebody within your organization, who’s that person and lean on them to help with that. You know, so I think it’s like, especially if you’re gonna be in charge of things you’re gonna have like real responsibility. Like you got to be self aware. You got to know what your limitations are and what you’re good at.

 

Rob Hall: Good leaders always surround themselves with people that they perceive to be smarter than themselves.

 

Josh Brown: Is that a? Is that a Trump quote?

 

Rob Hall: Absolutely not.

 

Four steps to building a good developer and avoiding building bad software. Step number one?

 

Josh Brown: Do I have four?

 

Rob Hall: Pairing? 

 

Josh Brown: Oh.

 

Rob Hall: Yeah, you gave me four. 

 

Josh Brown: I did? 

 

Rob Hall: Yeah.

 

Josh Brown: Oh, good.

 

Rob Hall: Step number one pairing. 

 

Josh Brown: Pairing. I don’t know if these steps are in order. These are just, I’m more of a more of a bullet list person than a

 

Rob Hall: That’s okay. 

 

Josh Brown: numbered list person. So yeah, pairing is invaluable. Pairing has a couple benefits, like one of the huge, huge benefits to pairing is that you can’t get into a flow state while you’re pairing. And I think that’s really important. You don’t want to be in a flow state while you’re working and you want to be in flow while you practice coding, not while you’re at your job.

 

Rob Hall: All right, hold on real quick. Just to clarify for our listeners, pairing means two developers working together at the same time.

 

Josh Brown: Yeah, I’ve actually done it with three people at the same time. But yeah, sure two.

 

Rob Hall: Okay typically two, I guess you can do it with three but okay. Now, what do you mean by flow state?

 

Josh Brown: Flow states like when you’re in the zone, you’re kind of in this light meditative state, where the world falls away and you’re immersed in what you’re doing. In that you also can lose some of your higher order decision making functionality, I find.

 

Rob Hall: Because you are grinding away.

 

Josh Brown: Yeah, yeah, you can kind of get lost there. So it’s like a good, fun state to get in. It’s like, I think it’s a healthy state to get in for a certain amount of time every day for a human. It probably helps just psychologically speaking to get into the flow state a little bit. 

 

Right. 

 

But if you want to write good software, I would argue against flow state, I would say you probably want to be a little slower, a little more precise, a little more conscious. Right? So pairing forces you to do that, which is good. You also learn a ton of things while you’re pairing.

 

Rob Hall: So you’re benefiting from the collective IQ of the pair.

 

Josh Brown: Yeah. And, you know, no two coders code the same. Right? 

 

Rob Hall: Right. 

 

Josh Brown: They just don’t. Like you can give everybody the same problem, and you’re just gonna get that many different answers. So that’s cool to see. You learn a lot of things that way. And I’m a huge fan of pairing for the collaborative decision making you get out of that. So it really reinforces the advantage of you know, when you have a big decision to make of talking it out with somebody can really, really help out. 

 

Rob Hall: Second point on Brown’s list of building a great developer: repeat yourself on important points. 

 

Josh Brown: Oh yeah, you should totally be a broken record. People are afraid to do that. I’m not sure why. You should not be afraid to repeat yourself. Especially if you’re a senior, and you’re responsible for someone who’s a junior. I don’t think that you can tell them something once, and they get it. It’s just not how it works. So 

 

Rob Hall: Continual reinforcement .

 

Josh Brown: you need to brainwash them via repetition. It’s just what it is. I’m sorry. 

 

Rob Hall: Yeah, no.

 

Josh Brown: I know that sounds weird, but

 

Rob Hall: Not at all. Number three: Cultivate Curiosity.

 

Josh Brown: Yeah, I mean, this is Ideally, you want people to be curious about their job. That’s how they learn is through curiosity. Like any way that you can cultivate that curiosity is good.

 

Rob Hall: I love this one because it’s also one of our core values as a company.

 

Josh Brown: It’s difficult to do because the field changes so much it kind of grinds you down over time. Because as soon as you think, you know, something, it’s, it’s kind of been pulled out from underneath you and, you know, to kind of look at things with fresh eyes all the time is a challenge.

 

Rob Hall: Last point: Don’t give them too big of a rope to hang themselves with.

 

Josh Brown: Yeah, this kind of goes back to like, you asked me what a bad developer was. When they’re, they’re kind of isolating themselves, and they’re kind of running amok on a project and making a mess of things. So you don’t really want to allow that to happen. It’s gonna happen some, and you should let it happen a little bit because people need to learn through their own efforts, not just through you telling them. But yeah, I think you don’t want to let it go in excess.