In this episode, Brian chats with Tony Campbell, Vice President of SRE and Platform Engineering at iManage.
In this insightful episode, Brian chats with Tony Campbell, Vice President of SRE and Platform Engineering at iManage. With a career spanning Google, Microsoft, and HubSpot, Tony has spent years at the intersection of AI, robotics, and software engineering—bringing a deep understanding of what it takes to build and scale modern technology.
The discussion explores the evolution of software development, the role of pull requests in team collaboration, and why the best developers often think like musicians—constantly iterating and refining. Tony shares hard-earned lessons on mentorship, effective code reviews, and what the industry must do to bridge the AI-driven talent gap. He also unpacks his thoughts on the future of robotics and whether AI is truly a game-changer or just another tool we haven’t quite mastered.
Then, in the Post Fix, Harriet makes an unexpected analogy between coding and music that makes perfect sense!
Time Stamps:
--------
Solving for Tomorrow is sponsored by Geisel Software. We help you create products that seamlessly automate the physical and virtual worlds using robotics, machine learning, and so much more. Find out more at geisel.software.
--------
Links
Follow Brian Geisel on LinkedIn
—----
0:00:02.6 Brian Geisel:. Hello and welcome to Solving for Tomorrow, Tales from the Tech Frontier. The show about tackling the biggest problems in the universe with technology. I'm your host, Brian Geisel, CEO of Geisel Software. We're here today with Tony Campbell, who is an awesome friend of mine, and I'm so glad that I was able to cajole him into doing an episode with us. And Tony and I meet regularly for lunch and we have these amazing conversations about how to scale large corporations and why they suck and why no one can code very well and why we love Python, but it's stupid and I don't know, whatever else. Tony's had a storied career. We worked together a million years ago at Company on a research project that was super interesting, super high pressure, quick deadlines, awesome, awesome stuff. It was a lot of fun and then we both kind of went different ways. I ended up starting a company and Tony went off and became a muckety-muck and has worked at Google, Microsoft, HubSpot, among others.
0:01:29.3 Brian Geisel: And so I thought we have these super cool conversations about life, the universe and everything, and coding and robots. And I thought we'd just have one of those and share it with you, the audience. How's that? Tony, thanks for coming.
0:01:43.5 Tony Campbell: Thanks for having me. I appreciate it. I hope I can live up to that introduction.
0:01:48.7 Brian Geisel: Is your arm okay after all the twisting?
0:01:51.5 Tony Campbell: I didn't fight. Come on. I didn't fight. I may have not been outgoing with my schedule as much, but I'm glad to be here. I listened to the show and I hope I can live up to the hype.
0:02:08.5 Brian Geisel: Yeah, well, okay, so let me continue. The hype is one last thing about Tony is if Tony produced content or chose to do conference speaking or whatever, everyone would know his name. He's one of these people who's influencing the industry and the culture in the industry in lots of ways. So the one last thing that I will add as an addendum to my introduction of Tony is that if Tony chose to publish and to speak at conferences and stuff, you would know his name. He's been influencing the industry in all kinds of ways but Tony's maybe a little introverted and I'd like to get him out a little more because just got amazing depth of information and I hope we can get a little bit of a dip into that depth today in our conversation. So we'll dive in from there.
0:03:06.9 Tony Campbell: Sounds great. I'm at your disposal.
0:03:09.6 Brian Geisel: So I'm thinking about a bunch of different things and I hope for the audience we can jump into some things that are highly technical and why this thing that we do as developers is terrible. But also we'll try to give some explanations so that if you're not a developer, you're not highly technical, you'll at least get a sense of how the thing works or why we're doing things a certain way, or why we're trying to solve problems in a particular way. And I think one of the things we talk about is the future and where the future is going from the different perspectives that we see. Let's jump into that in a little bit, but let's first start about. Why don't we start with ConnectAR?
0:04:05.2 Tony Campbell: Okay. Okay. That was a part of a line of projects to get telepresence going. It wasn't the first. It wasn't at that particular company. It wasn't the most advanced. It was, you know, after mobility in the home, the next challenge was manipulation or presence and stuff. And so that project was an exploration of how do we add something new to the mobile platform or the consumer. Robotics, space and manipulation was years, decades away at the time. This was, I don't know, 17 years ago, something like that.
0:04:53.2 Brian Geisel: And you're talking about robotic manipulation.
0:04:55.6 Tony Campbell: Robotic manipulation, sorry, yeah, it was decades away, presumably for cost effective, at least in the home. We're seeing a lot of buzz around that. But our compute budgets were much smaller back then. And so presence was another functionality or affordance that we could use to bring value to the consumer home. It was an easier problem to tackle than manipulation. Telepresence and the world now with the prevalence of video communication and stuff, that was something that we were trying to explore. We had interesting problem. How do you gesture when you're remote, things like that? Because it really added to the experience and the sensation that you were somewhere else.
0:05:51.0 Brian Geisel: What do you mean by how do you gesture?
0:05:54.9 Tony Campbell: That thing over there. Like what I just did. I was referring to that box over there. But when you have to describe it in words and stuff, it takes you out of that magical experience of being somewhere else in terms of telepresence. And so, you know, could we have done it with a pointer or an arrow on the top of the robot that just said that, that thing or this card, you know, one example was I want to play card cards with my kids. And so we would put it out in front of you and like I need play go fish or something. And you wanted to manipulate this card. You couldn't. We couldn't manipulate it, but we might indicate to the person on the other side like, hey, could you pick up that card? And that was relative and requires a gesture, requires that emoting.
0:06:45.6 Brian Geisel: But it was sort of a 1978 Camaro, red.
0:06:52.9 Tony Campbell: Yes.
0:06:54.7 Brian Geisel: Toilet seat shaped sort of Robot based on iRobot's Roomba platform so low to the ground circular robot that we're talking about. That was the telepresence. So imagine this donut trying to point at things. It can spin a lot, but it doesn't really show you where the thing is that you're supposed to be looking at or.
0:07:18.5 Tony Campbell: What the other person on the other side of that connection is looking at because you don't get eye contact. There was no sort of emotive capability on that thing. It was an early design of some of the things we were trying to experiment. It was small enough that you could put it on a tabletop, for example, and play a card game or do something like that. But in a lot of ways it was still early in sort of that product category, like a lot of the unreleased products from then.
0:07:45.5 Brian Geisel: Yeah. And we were just talking about it a minute ago, funny enough, because we have a Meeting Owl in our conference room and I don't know for sure that the two founders of Meeting Owl worked with us while we were there. And what we found while we were, we, we didn't find a lot of uses for this robot. So as a tech company, this was one of the interesting things is the company started with the technology and then went looking for a market for it. And, I think that was part of Colin Angle's. You would know this better than me, but I think he kind of had this philosophy that telepresence is going to be an important thing in the future. So let's figure out how to build telepresence and there will just be a market need when we get there.
0:08:36.0 Tony Campbell: Yeah. I mean the early solutions would lead to practical uses, like something that early in its sort of development as a product category, you're not going to have the, the end solution. Like we didn't know about gestures, we didn't know about moving. We had papers that we had read and sort of done the research on it. But those interactions would unlock it's oh, like, oh, I didn't realize that pointing was important for people for that sense of immersion or the lack of eye contact from the outside. The robot. You're staring at this donut, you call it this donut. And like that's not very, that's not very exciting or compelling feature set. You need to iterate, fail a few times and sort of understand what combination of those things leads to sort of a compelling consumer experience. And so, yeah, yeah, I mean it had great ups and downs. We did struggle at times to find a compelling use case. But it was also an untapped category at the time. The competition. It was. We're still trying to feel it out. And so the first few iterations were going to be a challenge no matter if we got it right the first time. Like, we would have second guessed ourselves a ton.
0:09:55.0 Brian Geisel: Yeah, yeah. So here was one thing that I thought was interesting is one of us got sick one day. I don't remember it was me or somebody else. I think everything was me. You remember why we got sick?
0:10:06.5 Tony Campbell: Yeah. Because paper cups that we would drink the Arizona iced tea out of.
0:10:12.9 Brian Geisel: Yeah. We would alternate which one of us brought the gallon of Arizona iced tea that day. And then all of a sudden our throats were closing shut and we couldn't figure out why. It's because we were using the hot coffee cups and the glue was leaking into our throats. But one of us didn't come into the office sick. And so the glue may have led us to what was. We figured out if we put the connector on the table. It had cliff sensors. So the Roomba sweeping your or vacuuming your floor, it does both. Wouldn't run over stairs and tumble down the stairs. It was really good at that. So if you put it on the table, it wouldn't run off the end of the table. So it turned out to be a really good conference app where we could, as developers, we're using it to like, oh, shoot, I can sit in the meeting and I can spin it to turn and face Tony. And then a couple years later, there's the meeting aisle, which uses a 360 degree camera. And I don't actually know if it was just a direct thought or a side thought that maybe Mark and Max kind of got that they went and started the meeting owl.
0:11:24.6 Brian Geisel: But I was like, that was one of the... That was the only thing to me that like hit me as a consumer, like, oh, this is really useful.
0:11:32.0 Tony Campbell: Yeah. That was actually one of the interaction models early on, before we had the prototypes and the robots itself was the portability of it and being able to you know, we had this use case of a father or parent away or sick and wanting to visit in with their kids and having something that the kid could pick up and lug to their room to show them this thing that they built or whatever. And so it would be like dad in a box almost or parent in a box kind of thing where they would bring the robot. That was one of the earlier advantages of it. I don't know if it was the limitations of our tooling that required it to be in a certain form, factor, but that was one of those features that we thought would be compelling.
0:12:20.2 Tony Campbell: An important thing I found in my career and understanding why engineering, why mechanical engineering, why not chemistry, why not physics kind of stuff was, you know, the maturity of the field at the time. And so like if you look at chemistry, it's a different point in the maturity that the discoveries that can be made versus physics. And I knew myself well enough and what my strengths were or had an inkling at that time what my strengths and weaknesses were. And I understood, I started to gain more understanding of where consumer robotics and robotics in general was. And I wasn't the right guy for the next 20 years. Like the next 20 or so years. I felt that it was a different, the industry was at a different phase from the kind of things that I like to do. I'm much more of a tinkerer and experimenter. The compute budgets, the maturity of like.
0:13:16.5 Brian Geisel: Do you think it was still too much in the R&D phase at that point?
0:13:19.8 Tony Campbell: A little bit. And a little bit of the market defining phase where what does, you know, we...
0:13:24.7 Brian Geisel: We didn't know what to do with it.
0:13:26.4 Tony Campbell: We didn't know what to do with it. We had a lot of this.
0:13:28.5 Brian Geisel: Robotics was a vertical. It's not anymore.
0:13:32.3 Tony Campbell: It's not about two decades. I was right. But for me anyway.
0:13:35.8 Brian Geisel: Yeah.
0:13:36.3 Tony Campbell: But you know, we had this like, we wanted to make Rosie from the Jetsons and everybody was like, this is the future that I'm buying into. But there were enough technical hurdles between like practical in the home kind of robotics and that future that there's going to be some time of grinding it out basically. And I wanted to get more iterations, more experiments done in my career. And so I instead shifted to something else that was becoming hot and exciting. This thing called the Internet kind of stuff. And I thought that that was going to become a more prevalent part of our lives. This was early 2000s part of our lives. And I saw a lot of advantages of how to leverage it in sort of the network enabled robotics to offset some of the challenges with local compute and battery capacity and stuff. And so wanted to understand how the Internet worked. And so shifted a little bit more to that so that I could bring it back when the opportunities in the robotics vertical, as you call it, were there and could benefit from somebody like me that I could get excited.
0:14:48.1 Tony Campbell: It's not exciting. Excited is the wrong word. Activated. Leveraging my strengths to build a useful career to make the world better, you know, and have a positive impact. And I could see just like I liked physics better than chemistry because of the relative maturities of the worlds. What are the fields, what are sort of axiomatics axioms for each of them and what are the assumptions of each. I could sense that it was too early for me to be excited in the ways that I wanted to be excited in my career. So I went and looked at something else temporarily. I bounced back and forth between different fields all through my career and just following the hard problems. But it just happened that there was enough depth in the Internet thing to really sort of figure.
0:15:37.3 Brian Geisel: It's just funny because your college was in mechanical engineering, right?
0:15:41.5 Tony Campbell: Yeah, yeah, yeah. I did that because I didn't feel that I loved Physics was my thing I loved.
0:15:49.5 Brian Geisel: But then you went to software. You're one of the best software engineers I know. How do you go from mechanical engineer to really good software engineer?
0:15:57.6 Tony Campbell: My first job actually I mentioned this before about cycle times, iterations, learning and I'm sort of a self learner and the best way to learn is to make something and mess it up and fail or succeed and go through this process of iteration. My particular way of thinking isn't very textbook linear. First off, I jump around a little bit more and I like to be a little bit more hands on. Mechanical engineering was too slow. It would take us three years to build a product, to build a bracket in my small component. I could release software back then very rapidly and learn and hone my craft of building applying science to the real world problems a lot faster and get that feedback and that dopamine hit of shipping something and the cycle times were too long between nothing against that kind of stuff. But I was more addicted to the hits of like launching something and seeing the effect of it and going oh, that wasn't quite right. Let's again let's gesture, let's add something in learning from that. I was in a rush a little bit to leave a mark on the world.
0:17:23.0 Tony Campbell: So I wanted to make sure I had enough cycles or iterations in my career to do that. And I found software to be a little bit more convenient way to rapidly grow in maturity as an engineer, not necessarily software or mechanical. And I was always sort of a hybrid anyway. It was an arbitrary decision back in college. Anyway.
0:17:47.8 Brian Geisel: Yeah. So, okay, I want to jump us around a little bit. So you went. Not long after we worked together, you went to Google and then.
0:17:56.5 Tony Campbell: Yeah, I didn't actually go to Google. I went to another place in Cambridge and we were acquired by Google. It was sort of...
0:18:07.9 Brian Geisel: I'll count it.
0:18:09.4 Tony Campbell: Yeah, okay, we'll count it. But it wasn't. I didn't like...
0:18:12.3 Brian Geisel: Direct... Yeah, yeah, sure, sure, that's fair. But you ended up working at Google, but then you went on for the mechanical engineer. You went to write software to make software.
0:18:22.1 Tony Campbell: Yes. Platform stuff, reliability stuff.
0:18:27.8 Brian Geisel: You went to GitHub.
0:18:28.8 Tony Campbell: I went to GitHub, yep.
0:18:32.1 Brian Geisel: I'm going to dive us down a rat hole because we've been talking about some things in Git recently.
0:18:38.1 Tony Campbell: Yes.
0:18:39.1 Brian Geisel: And we had some challenges on our team where we got stuck in pull requests. So let me try to do this quick for folks who aren't software developers. One of the things that we do as software engineers is we hate to make progress and then lose it. And you're constantly iterating, you're constantly changing things all the time. And so what we do is we use these things. Like Git is one of the tools that we use where we have a common repository and we'll be working on the same code base and Tony might make some changes and I'll make some changes into this common repository. And we now have sophisticated tools where Tony's change can go in and my change can go into the repository and maybe I'll have you pick it up there on what a pull request is then.
0:19:24.2 Tony Campbell: Sure, sure. I mean, you can. Also, something that might be more familiar is like a Google Doc where you have multiple people typing at the same time. This is a similar, more static way, but it sort of underpins how collaborative software is written. And as you can imagine, you might both be editing the same section of the document. You might be deleting stuff that somebody else wrote. It's a collaborative, shared exercise. But in this, in the case of Git and other software development, it's in writing software that needs to function on some form of computer or whatever. Although people Use Git for all sorts of things, not necessarily just code. A pull request...
0:20:02.2 Brian Geisel: That sounds like somebody who worked at GitHub.
0:20:05.7 Tony Campbell: I did. A pull request is a way to stage these changes and so think of a set of source code to your software application or shared that shared saved state of source code. It's rude or difficult to collaborate with you and me on this shared code base if we don't communicate as people as well. And so like, well, that code I wrote yesterday is gone. What happened? It turns out it was junk and you rewrote it or wrote it differently or had a better understanding of it. And so the pull request is a way for us to batch up changes so that our shared repository, our shared view because you might have your own copy of it, I have my own copy of it and we sync up every now and then. It's a way for you to share that change with me, for me to review it, to understand it, to ask questions, maybe to make suggest changes for us to. It's form. It's part of the collaborative.
0:21:09.1 Brian Geisel: It's a form of communication.
0:21:10.8 Tony Campbell: It's a form of communication. It goes to not just GIT but other source control systems that predate that. And it's not a solely for Git, but it's a way for you...
0:21:20.4 Brian Geisel: SVN CVS, RCS. Yeah, yeah.
0:21:25.1 Tony Campbell: Like all the source control systems where it's basically we are editing text files together but we're not in the same room perhaps we're not in the same time zone even and we need to. What are you doing? There's great videos of coding jams where they don't allow people to talk to each other and they just give them a problem and say you three go create software to do this. And it's fun to watch because they can't talk to each other so they don't understand the shared state.
0:22:00.3 Brian Geisel: Are you allowed to put comments in when you push?
0:22:01.5 Tony Campbell: No, no. It's like blind coding and it turns out differently than they all.
0:22:07.6 Brian Geisel: Well, C's self documenting so if you do it in C that make that easier.
0:22:12.8 Tony Campbell: But anyway, request is a way to bundle a set of changes and offer it for peer review. Almost like you would. We're acting as editors of each other's writing and it lets us write with the same voice, the same style, the same mental models in it. And it's an educational thing where you may be more familiar with the code base than I am and I'm making a bunch of assumptions that you could then say hey, you know what? We already have a library. We already have code that does this. You don't need to do this. Or in our project, we tend to do it this way as opposed to the way that you're suggesting here. Take a look at this. Or I didn't see this. That's very interesting. I didn't realize that we could do this in this code base. This is educational for me. In our relationship as collaborative editors, we have this shared responsibility of maintenance of this code. We don't own the code really. We're maintaining it, storing it. But for either of us to be effective at it, we need to understand basically how it works. We might be experts in some sections, but this also lets you and I, outside the code base, outside of comments, to talk about design decisions, why I'm making this change, why I think it's important that we do it this way or that way.
0:23:31.1 Tony Campbell: Not quite design docs, but like, hey, look at this change I'm about to do. It's going to be not backwards compatible, but I think it's important because the following things, and this is what I'm thinking, what do you think? And then that becomes a separate conversation. You can do it on GitHub or whatever. Your mailing list or you know, your kernel mailing list or whatever. Like there are different examples and different tones and cultures for collaborating. And a pull request is one way to both indoctrinate people, to train them up, to get them to learn the voice of that code base as well as traceability. Big companies, you probably need more than one person to look at any change for malicious actors or mistakes or culpability. You would want to have two sets of eyes on every change. And so I would issue a pull request, but wouldn't be able to take those changes and apply it to our shared repository without you saying yes.
0:24:28.5 Brian Geisel: Without someone else approving.
0:24:29.6 Tony Campbell: Approving it.
0:24:30.2 Brian Geisel: So I want to double click in a second on a thing you said about like the shared mental model.
0:24:36.5 Tony Campbell: Yeah, hugely important.
0:24:38.3 Brian Geisel: Yeah. And I think there's an evolution there. But the one that I want to just step into quickly because we had a discussion about it. I thought it was really a tactical, useful thing was we had this issue, do you remember the old. I think it was a Budweiser commercial where they're like, tastes great, less filling, tastes great.
0:25:00.4 Tony Campbell: Less filling.
0:25:02.3 Brian Geisel: Tastes great. So we had an issue on our dev team. We were like, you should use a for loop and you used a while loop. And then the other Developer was like, no, this should definitely be a while loop. No, this should be a for loop. While loop. For loop, while loop. And you had this great, like listen, this is what a pull request is supposed to be for. That just made that. How do I manage this repository with the developers just, it just melted away. The problem melted away.
0:25:33.3 Tony Campbell: You know. Was that the turnaround or was it the one letter grade?
0:25:39.4 Brian Geisel: Yeah, yeah, yeah.
0:25:41.1 Tony Campbell: The point of a pull request is not for you to be a gatekeeper of my changes. You might be the tech lead of the project and responsible for its overall quality in a business sense or you may be the primary maintainer, but it is not, it's less healthy when you are trying to. I need to code exactly like you. Instead where pull requests are very helpful is like you're helping me get better at the craft of writing software. And so the goal of a pull request would be from in this situation, help me get my code one grade better. It's not going to be perfect. Code is a living thing. That's one of the benefits of writing software is that it evolves over time and you get into these rat holes of tastes great, tastes great. I remember suggesting limit the turnarounds to three back and forth. Because if you keep telling me my for loop is wrong, I should use the while loop or whatever. Do it three times and I'm gonna feel pretty crappy. I'm not gonna, I'm not gonna want to work with you and like I'm gonna, I'm gonna be gun shy the next time with my changes.
0:26:47.5 Tony Campbell: I'm gonna second guess myself. The point is not for me to write code that you would have written. It's to mentor me so that I can write better with the voice or for us to discuss that voice. And like what is the proper, the mental model, the let's ban all four loops. Everything's a while loop. Like it could be that, that might be part of the.
0:27:08.8 Brian Geisel: Right, sure, yeah, yeah.
0:27:10.0 Brian Geisel: But what happens is, especially with the responsibilities of your peers in a shared repository, you get this like gatekeeper thing going on as opposed to.
0:27:19.9 Brian Geisel: I like that.
0:27:20.7 Tony Campbell: Yeah, you're not a gatekeeper. It's, it's healthier to think like your shared collaborators on a project. You're trying to make everybody around you better. You're trying to code in one coherent voice is better. It's easier to follow, it's easier to read. So I would say like the non functional requirements of that makes it a better Code base. And so that means you and I, when I collaborate with you on a project I know I have to use while loops, I might, that might be something that's not an absolute in an industry or something at another place or...
0:27:55.4 Brian Geisel: I have a friend who has a religious obligation to write while loops.
0:27:58.4 Tony Campbell: The thing for me is when I collaborate, especially from an open source perspective, when I collaborate in your open source project or your repo, can anybody tell that I wrote it or that it's just the voice of that code base? So pull requests really help with this and like the back and forth like you're not going to win. There's a lot of stuff on like how to write effective pull requests. One of them is like two, three back and forths to do it. If it's still not there, break it up into smaller pieces that are unobjectionable. So I can make progress this week or I can get some bit of functionality, have an offline conversation, discuss it with them or defer to the author. Like I put a lot of energy and you trust me as an engineer that I'm doing it for a certain reason. This is a way for you to extend trust and vulnerability. It doesn't have to be exactly the way you wrote it. Because you know what? I'm not a clone of you as a software. You don't want me to be a clone of you as a software engineer.
0:28:56.2 Tony Campbell: And so you let a little bit of that. I think a for loop here is good your perspective. I don't think so. Blah blah, talk it through and then like, okay, we need to get this code in. The point is not to like gatekeep your this pull request or these changes. The point is for us to move this code base forward or to add some feature or something that people want to use out of it. And okay, get it in also. And then if you really are sticky about it, make another pull request and change it to a while loop and have that as a separate conversation or a separate issue. That can either be like that doesn't make any sense. You're just nesting in the familiar constructs that you're used to. You get to learn all the different ways that I use or abuse for loops in my code. You get to pick up through us. We both get better.
0:29:49.0 Brian Geisel: There was a great use case of this in a recent project. I jumped in to do some code and I've done Python for a long time, but not recently.
0:29:55.9 Tony Campbell: Yeah, yeah.
0:29:56.7 Brian Geisel: And so the team started using type hints. Are you okay.
0:30:04.3 Tony Campbell: Yeah. Oh yeah. Snarky comment on that.
0:30:10.3 Brian Geisel: There is a pythonista thing about you shouldn't have to worry about what the type is in Python. You shouldn't ask what the type is. You shouldn't need to know. But in this code base, to your point earlier, right, the code base was, we're starting to use some type hint stuff. And the way that I inserted the type hints, because that's new to me, was wrong. And so in the PR somebody said, hey, type hints don't go here, they don't go in the init, they go on the class itself. And I was like, I learned it wasn't just like change the code, you're stupid. I learned how this new feature that I haven't used before works and how to do it the right way without having to go study on it for eight weeks. Like one of the other developers was like, hey, in your code. Because I can touch and feel that so I can learn faster from that. Here's how you do it there. I thought that was a great comment on a PR.
0:31:03.2 Tony Campbell: Yeah, I think you know software in at least professional people who code for to pay the bills kind of stuff. It's a very still very much an apprenticeship model of learning. Yeah, because you have to learn both the code base, but you learn on the job coding from people who are more experienced than you. There isn't a formal curriculum. Writing software professionally is very different from school or from open source. The constraints, the non functional requirements on the code base are very, very different. And we don't have a way to effectively formally train somebody. So it takes an apprenticeship model. You have a lead who gives you, who's more experienced in the code base or in the language or the technology that gives you these little hints and nudges from it.
0:31:50.0 Tony Campbell: But they need to see your code, they need to review your code in order to do this. And it works both ways because we're always learning. But it's an important part of this apprenticeship style that the software industry is in. There's a lot of like going to learn it on myself, going to figure it out kind of stuff. But in a group, when you're on a team, you have a shared code base. You're all at different points in your career or expertise with this technology. You're all learning. Ideally you want to structure this team so everybody is learning something new and mentoring each other on the code base.
0:32:21.6 Brian Geisel: Let me ask you on that. So you've been at Google, at HubSpot, at Microsoft. I don't know they need to know what percentage it is. But how often are they hiring people with a degree in computer science versus they don't. Or it's in something totally different or they don't have a degree at all. Like how important is that at those companies? And not even those specific.
0:32:46.6 Tony Campbell: But I don't think it's super relevant in these larger companies. There's a pipeline that you go through that as a hiring manager, I wouldn't even have like they've already been vetted through something. So I don't have the widest pool of candidates to evaluate. These people have already gone through a couple of sections of the funnel. In smaller, maybe smaller companies, maybe GitHub, before it was Microsoft, we would have a little bit more flexibility and be able to see somebody more holistically based than sort of their education or the companies that they've worked at before. Open source is a great way to show, to perform, to do that. I've looked at people's repos when considering hiring them. It's like, I just want to see. A sample of your work. You get good at reading other people's code and understanding, you know, is this person a jerk? You know, you can tell from their, their, their voice. In a lot of cases you can see a lot in someone's work. I would weigh. And there have been people I've brought on that didn't have degrees but had an open source presence or did that and it was a big win to convince them to work with us because we got to learn from them. They clearly could do the job, but they didn't come from the conventional 4 year degree boot camp. Me personally, I don't care.
0:34:16.8 Brian Geisel: How many times have you gotten a GitHub repo that they put on their resume that you thought, don't show me that. Just lie. Tell me you don't have one.
0:34:26.6 Tony Campbell: Never.
0:34:27.6 Brian Geisel: Really?
0:34:28.1 Tony Campbell: Never. Never.
0:34:28.8 Brian Geisel: Come on.
0:34:31.3 Tony Campbell: A lot of people, not enough people put that as part of their thing. And like, don't show me.
0:34:36.7 Brian Geisel: We get so many.
0:34:38.2 Tony Campbell: Give me a project that's relevant. Yes.
0:34:39.8 Brian Geisel: Right.
0:34:40.1 Tony Campbell: Give me one of your repos that you think is like, this is where I flourished with for loops. This is why I'm so excited about that. And like show me the, the interest in that. And like point out the code. Point out like a, PR that you found that was interesting to me. That's signal boosting to the important stuff. I can read that and Interpret that without knowing the problem that you're trying to solve. I can see if that fits in well with One of the existing teams that are looking for somebody to join them. Like, don't send me your, you know, slash username. Yeah.
0:35:14.7 Brian Geisel: Sometimes so many times. I get that. And you have five repos in there of all broken code from college. That doesn't.
0:35:21.1 Tony Campbell: No, there's other ways. Show me a PR where you made a suggestion to an open source project and it got shot down and how you handle that.
0:35:33.5 Brian Geisel: Yeah.
0:35:33.7 Tony Campbell: And like that's just as relevant because that happens in business all the time. Like, let's not do it this way. Or show me a pet project and not the whole pet project. That's great. Show me how you documented it. If that's what you're trying to emphasize. Signal boost. The important things of like working as a peer and a fellow stakeholder in a repo. Show me...
0:35:52.6 Brian Geisel: Don't show me how you added a period or a semicolon.
0:35:55.3 Tony Campbell: Show me as how you convince that other person to use for loops instead of while loops.
0:36:00.9 Brian Geisel: Boy. Yeah.
0:36:01.2 Tony Campbell: And like convey that. And like you were polite.
0:36:04.1 Brian Geisel: Because it's not just how good your code is.
0:36:05.9 Tony Campbell: Right.
0:36:06.4 Brian Geisel: It's this communication and working with others to get a thing accomplished.
0:36:11.0 Tony Campbell: As you go to your section of the code versus my section. I worked in code bases where it was. We have worked in code bases together. Very obvious. Who wrote that bit of code? And it was jarring. You could jump.
0:36:22.9 Brian Geisel: Do you remember the 2400 line switch statement?
0:36:27.6 Tony Campbell: Yeah. Wonderful engineer. Brilliant engineer. I mean, yeah, I've been guilty of some really bad, bad code. But like being able to write code is. If you don't write the bad stuff, you're just reinforcing your own self image that I'm a superstar or whatever. It's like, no, if you're not failing, if you're not writing something that like later you go, ooh, that's kind of gross. Then you haven't grown anything since you wrote that code. And so like, you need to see that trail of missteps. Things I wouldn't do today. And like you have, I'm sure you have a bunch of coding examples like, oh, I would never do it.
0:37:10.0 Brian Geisel: That. Oh, they're in repost.
0:37:11.1 Tony Campbell: Yeah.
0:37:11.3 Brian Geisel: Yeah, you can go read them. Yeah. In fact, that one, It's a really good point. That one that I'm mentioning was specifically an experiment. Yeah, it was trying to do yields and stuff in C code. That was. Okay, let me shift this because I wish we could do this for another hour and a half but I want to ask a couple of last things is like we're talking about the software development process. I think one of the things we used to do is even really big projects, it was best if it was written by one person because they had the whole architecture in their head. It meant the number of bugs you wrote was so much less.
0:37:56.2 Tony Campbell: All right, you great career protection. It was...
0:38:00.8 Brian Geisel: There was that as well. There was that as well. But this shared mental state that you mentioned on like as you're doing PRs and stuff and I don't know if that's it, but what's the next step of evolution of software? And you know, we didn't get into the SRE side of things where like part of is keeping this stuff up and running and...
0:38:23.4 Tony Campbell: And the code you write with that in mind is very different than you would normally or that most people are trained with distributed systems are very different from the kind of classical education software that we all write. And that's one of the challenges of being in that field is that it's non intuitive when you're thinking about all the different parts that can fail.
0:38:43.6 Brian Geisel: Can you tell people what an SRE is for 10 seconds.
0:38:44.4 Tony Campbell: Site Reliability Engineer they keep the Internet up.
0:38:49.7 Brian Geisel: There you go. There you go.
0:38:51.1 Tony Campbell: That's probably the best way. Everybody wants to write reliable software. That's an aspiration to edit. Everybody writes. Turns out it's non trivial, it's a hard problem. It's non obvious how to do this, how you know the software above you or below you can fail. And so there's SREs are something that Google came up with and has sort of proliferated throughout, you know, sort of the cloud centric software industry as a way to increase the reliability of services that run in on the Internet.
0:39:27.4 Brian Geisel: So let me shift this to one final what as we talk about solving for tomorrow on the podcast. What as you looked 20 years ago you went the robotics industry is going to take too long to get where it's interesting to me. Where do we sit today? Could be robotic, software, there's a comma robotics or software. What do you see 20 years from now? Or what do you. I guess maybe if I ask it this way, if you had a magic wand and you could fix one thing, what's the thing that you would touch.
0:40:01.6 Tony Campbell: How magic is this wand? I've heard you talk about breaking the laws of physics. Like political regulation, landscapes. I mean I think power generation is an important one. I would love to, if I had magic room temperature superconductors that would be something that would transform power transmission and like we're consuming more and more power. And this whole centralized power creation facilities, these long transmission lines that consume it. Magnetic levitation. Like there's a whole bunch of stuff that in a video games tech tree that would be a technology that unlocks a whole bunch of new options for you to place on the map. That would be one, I think you know, you were talking a little bit about AI and stuff. I think next decade maybe. And I'm saying this so it's gonna, it's gonna come back and haunt me. I feel in my experiments and when I play around, I've got a new tool, I've got a new jig in my workshop.
0:41:11.4 Brian Geisel: Yep.
0:41:11.8 Tony Campbell: I don't know. I got no instruction manual. I don't know how it's supposed to Be used or whatever. But it's that I build stuff and I may be using it upside down or not in the way that's really effective. But I think in the software development flow we need to figure out and figure out what to do with this weird shape to build stuff because we know that it can do stuff.
0:41:35.7 Brian Geisel: Yeah, it's a really useful tool. But what's it for?
0:41:37.8 Tony Campbell: I haven't figured it out yet. I'm trying to use a hammer as a screwdriver with the nail remover side. You know, I'm like this doesn't feel right. It's awkward. The code quality, the resulting code quality isn't there. But at other times it has such broad context. I can ask it about my code base and suddenly get an answer that would have taken me eight hours to figure out. I think the next phase is, or the future thing is figuring out what to do with this new tool that just showed up in our code base. And then the real human ramification parts of that is like it eats out a lot of the bottom of the software industry that seems to like junior devs that it makes it harder for them. How do we... We need to shift to that other tool, how to use it and then how do we get it so that we can have a sustainable field by letting these newcomers to our field hit Escape velocity and cross break through what the tool can do to be on the other side.
0:42:46.9 Tony Campbell: Those two things are I think are the challenges that I tried to figure out how to do that and then how do we make sure that there isn't a 20 year gap in software engineers because you know the industry or the business tries to commoditize basic knowledge around that and then it turns to us like as members of this field like how do we you know, reach through that being on presumably on the other side how do we get that escape velocity again for other people so that they can become experts in something so that they're not competing against the AWS cost to run the LLM for you. And so those are the two things that I would sort of fixate on a little bit in terms of software development for it. And a lot of this tool is very versatile. It's going to change like the way we use pull requests today might change. It may be very different. The way we talk about the software outside of the software may change. So there's a lot there. But I would stick to those two things. I would love it also I would love to delegate a little bit like if more of that wand shaking a little bit of that extra fairy dust on there is...
0:44:00.6 Tony Campbell: I don't like the chat interface. We run out of time. I would like a stateful agent on the other side suggesting things to me. A long running agent that talks that I can talk about the code base and suggest changes. Not how do I do this loop. What's the protocol for here? Implement the socket. Implement the network programming for this part of the code base. Instead of doing that it'd be like what should. Where should we optimize? Where do you see is the worrisome parts or the bug ridden places of this code base? I think those kinds of questions again that feels like a better use of that tool rather than generate the convert all my for loops to while loops.
0:44:43.9 Brian Geisel: Yeah, I think it's going to be fascinating when we solve that piece of it as we get better at that.
0:44:49.7 Tony Campbell: Thanks a lot for watching Solving for Tomorrow like subscribe connect on all the social medias if you like more of this more to come.
0:45:00.0 Brian Geisel: Hey, you're not Tony.
0:45:00.6 Harriet Koramoah: I'm not. I kind of still Tony C.
0:45:04.1 Brian Geisel: It was nice to have Tony in person I thought.
0:45:06.4 Harriet Koramoah: I feel like of course the conversation you guys talk all the time. I'm aware of this because of your Wednesday meetings but I feel like having a friend here for a while now that probably was a change of conversation. Right?
0:45:23.4 Brian Geisel: Yeah, it was nice. Both that know a little bit about what Tony can dive into, but also he thinks such deep thoughts about so many great things that it's always interesting. And that was one of the reasons I wanted to have him on the show is like with his amazing talks at lunch about all sorts of things that we all learn so much from. And I thought that would be cool to kind of share with the audience and let other people learn from some of those things and from the, some of the experience Tony has.
0:45:58.6 Harriet Koramoah: Before I give my takeaways, I want to know what your takeaways were. Like, I know you mentioned you guys were talking a little bit about the pull requests, and I know you mentioned that that's a problem you are having. So I kind of want to know if. Because it feels like when he came here, you actually got something out of it too, like not just a great conversation, but you had a problem solved. So that's the feeling I'm getting. You can correct me if I'm wrong.
0:46:29.6 Brian Geisel: Yeah, no, and we had Tony actually stick around and do a tech talk here after, after or before whatever, however the timing worked out, which was really great. And we talked about, I don't know, a bunch of Python stuff and a bunch of Git stuff. And I think the things around those things. If we don't know how to use Git in the software world, we can use ChatGPT or Gemini or Google to just answer some of that stuff. And how do I use this in Git or whatever? I don't necessarily need to ask another developer that. But sometimes a way in which people use the tools and sometimes you get these things where you're like, oh, I never thought about solving the problem that way, or I never thought about using that tool to solve that particular problem because isn't it for this other problem?
0:47:20.0 Harriet Koramoah: Yeah. You know what's so crazy? And maybe because I'm not in the software development world like that. I mean, I'm kind of in that world, but I'm not a software engineer, so I wouldn't really know what goes on. But I really do feel like this was kind of like in any job they give you pro tips on what to do and not to do. And that's what I got out of this. Like, oh, as a software engineer, you're familiar with your tools already.
0:47:45.5 Brian Geisel: Right.
0:47:46.0 Harriet Koramoah: But like, here's a little bit of an advice from somebody who's been in the field for a while. Kind of like a mentor who's, like, guiding and training you. And I felt like that's how the conversation felt like. And I truly enjoyed it a lot because I was like, oh, that's really cool, because. And maybe this is a stereotype of mine or this is my own assumption, but I always feel like software development is a field that people in there are smart enough, they have a lot of interest and they know what they're doing. That's like the number one thing. Like, mostly with doctors usually. Sometimes a parent tells you to do it or you get into it. A lot of software development stories start from. I just started picking something up, picking it apart, and then I decided to be a software engineer. So it feels like a field where you actually have to have interest. And so there's a lot of people who already know what they're doing. So I don't really see it as a field where you can have a mentor that corrects you on what you're doing. So it was really nice to see that side that Tony brought out that there is.
0:48:49.3 Harriet Koramoah: It is still a field where you can still take something from somebody who's been in it for a while. Right. You can take something from a veteran. So, yeah, that's what I got out of it.
0:49:00.4 Brian Geisel: And in a weird, like, tangent I was thinking about this the other day is how often coders who are really good musicians are really good coders. I can't think of a time where I met somebody who is a coder, you know, who writes software for a living, who's a very good musician.
0:49:23.1 Harriet Koramoah: Yeah.
0:49:23.7 Brian Geisel: But a crappy developer can't think of that case. And one of the reasons, I think, is how similar they are. One thing is in music, and this is a whole other public service announcement is in music. People who don't play music think it's talent.
0:49:40.4 Harriet Koramoah: Yeah.
0:49:40.9 Brian Geisel: And people who play music know that it's effort.
0:49:43.4 Harriet Koramoah: Yeah.
0:49:44.6 Brian Geisel: It's just how many hours have you spent working on that thing? And there's only so many people in this world that have the. This additional talent piece that is Yo-Yo Ma. It distinguishes it from just the work. But how far you can get with effort is so far, even if you don't really have great talent in it. And so people who are very good at music, talented or not, have put a ton of time and effort into it, and you have to do it independently. Like, you have to practice 40 hours a week or 60 hours a week or whatever. There's no music teacher that sits with you 60 hours a week. You have to practice on your own. And that's the same thing is if you just go to school for software development, man, the best you're going to be is a mediocre software developer. You have to do it outside of that, just like you do music. And so I think about that corollary, but it's similar in the way you're talking about the mentorship. Because if you watch great musicians comment on one another's music or mentor each other, somebody plays a piece of music and it's beautiful. And then somebody who's that next level.
0:51:00.0 Harriet Koramoah: Yeah. Can see what's like what's going on. Can help you tweak it a little bit or give you a key where you didn't think. So I don't know if people know this, but I kind of want to share the story. There was a story of Kanye west saying that he's a good producer, everybody knows that. But he had to go to Timberland like a veteran producer, because he was trying to do this, just trying to produce this song and it just wasn't working. And he had to go to the guy that knows a lot more about how to like do the beats and do everything. And whilst he's good at his craft, he was able to like tweak it in a way where he would have never thought about. So what you're saying, like, that's the first thing I'm thinking about, like that is true. There's a lot of veteran, like musicians that say, oh, I couldn't play that note or I couldn't play this key. And somebody said, why don't you play like this?
0:51:49.7 Brian Geisel: And it's. They can play the note right, but it's like I had a friend who's a great musician and he said his mentor asked him one day, why did you play that note? And he was like, what do you mean, why? Well, figure out why you played that note. Or there's this great clip of Benjamin Zander, who's like the conductor of the Boston Symphony Orchestra, I believe maybe emeritus now, but there's this great clip where he's helping this amazing 15 year old cellist who's playing one of the Bach pieces. And he says, okay, play that again. And he plays it great. It's great. It's not moving, but it's great. All the notes are perfect.
0:52:36.8 Harriet Koramoah: It's not moving.
0:52:37.7 Brian Geisel: No, you didn't feel it emotionally.
0:52:39.7 Harriet Koramoah: Right.
0:52:40.0 Brian Geisel: But he played all the correct notes.
0:52:41.9 Harriet Koramoah: Yeah.
0:52:42.5 Brian Geisel: And Benjamin has him go play it again. Like this, like this. And at one point he says to him. Why don't you play that D on one buttocks? And you can see him kind of look at him like, what? And he goes, as you play the note, don't just play the note, but play it and lean into it like this. Harry, when he does it, it sounds better. You are emotionally moved by the note because all of a sudden he, the musician is in that note and he's feeling the note. And as funny as that is that he says, try it on one buttocks. But as he.
0:53:20.3 Harriet Koramoah: The public service announcement, he just said this. So he can say that word, by the way. So Just a PSA for people listening.
0:53:29.2 Brian Geisel: It's just a great example. Harriet. I looked in my bag of great examples and this was one of the best.
0:53:36.5 Harriet Koramoah: It was not. I'm sorry, but I'll just. We'll take it.
0:53:39.4 Brian Geisel: It didn't have two buttocks.
0:53:40.4 Harriet Koramoah: We'll take it. We'll take it.
0:53:41.8 Brian Geisel: It was just the one.
0:53:42.8 Harriet Koramoah: But, yeah, speaking.
0:53:44.1 Brian Geisel: But it sounds different. And just by just moving his position as he played that note, he put more emotion and you felt more emotion in the note. And so that's the kind of thing like we were talking about, like, how do I do a Git commit? Well, dude, go look it up on Google. Don't ask me that. That's your fault. That's the easy thing to find out the answer to. But, like, one of the suggestions Tony was talking about is when you do a code review, do it. Your goal is to help improve the code one letter grade. And I thought that was such an insightful way to think about what you're doing with a code review. We all know how to do a code review, but how do we do it well, and what do we really do that elevates the code of all of us. Because if we do it mechanical, like the guy played that D note and we just do a code review, because we're supposed to do a code review and I'm supposed to criticize you now. So I will criticize you purpose and it becomes negative value. But if instead we can go, oh, my job is to look through this code and help improve it one letter grade. Now I'm in a different mental state when I do that. And I'm going, how can I help you make your code better? And you know what? If you don't like my suggestion, then you don't use it. But if you do and you go, and this happens to me all the time, somebody says, oh, well why don't you Use this library for that.
0:55:23.5 Brian Geisel: Or, why did you do it this way? You could just do this. And I'm like, I never thought of that. Or, I had no idea that library existed. Yep, I'll go change that. I'll go use that. That sounds way easier than the way I did it. And so then we all better that.
0:55:39.9 Speaker 4: Hey, I just want to let you know commit broke my code.
0:55:45.0 Harriet Koramoah: That was perfect. I did not expect this.
0:55:48.7 Brian Geisel: I think we should do it again. We have to unbreak Harriet. No. And those are things that in my code, developers have said, hey, in a code review, there's a library for this. Or, why don't you consider doing it this way? I'm like, oh, yeah, that is a shorter way to do it. I hadn't thought of. Or, no, I didn't even know that library existed. And so then all of a sudden, I change my code and my code is one letter grade better. Which is exactly what Tony was talking about. And I think...
0:56:18.3 Harriet Koramoah: You have to like.
0:56:20.5 Speaker 4: Hey, sorry for the interruption, but your last commit broke my code.
0:56:24.4 Brian Geisel: What?
0:56:26.1 Speaker 4: Yeah.
0:56:27.9 Brian Geisel: What are you doing in here?
0:56:32.5 Speaker 4: Sorry. You broke my code. I just need to.
0:56:32.5 Brian Geisel: I don't think I did.
0:56:33.9 Speaker 4: They have proof. It's failing to run now.
0:56:37.2 Brian Geisel: Right now is when we have to talk about this. We're in the middle of shooting a podcast episode.
0:56:42.1 Speaker 4: I mean, it's fine. You just, like, cut it. Fix it in post. You like.
0:56:47.1 Harriet Koramoah: I feel like the producers are tired of us.
0:56:49.7 Speaker 4: We were kind of in a flow. I thought we were in a flow.
0:56:53.0 Harriet Koramoah: We were in the flow. Yeah.
0:56:53.0 Speaker 4: You just cut it. It's fine.
0:56:58.3 Harriet Koramoah: Can we do this later and get back to the podcast?
0:57:03.8 Brian Geisel: And that, ladies and gentlemen, is an example of a bad soft skill. Thank you, Jonathan. You're welcome.
0:57:12.9 Harriet Koramoah: Thanks.
0:57:13.7 Brian Geisel: We'll use Jonathan to transition ourselves to soft skills in developers. Segue. Segue. That's all, folks. I love Jonathan. That was awesome. And a great segue into soft skills.
0:57:35.6 Harriet Koramoah: Yeah. I have an article here that our producer sent to us, and it talks about, like, I had a question to you at first. I remember I asked you this, like, maybe a couple days ago or whatever, but I was like, do engineers. When you're hiring engineers. I know you look for the hard skills, which are like, you know.
0:57:56.6 Brian Geisel: Can they code?
0:58:00.7 Harriet Koramoah: Yeah. Can you code? And then the soft skills, which I've actually never thought about that. I've never thought, like, what do you really look for in soft skills? So I do have what I believe, like, the... It says five soft skills. Every developer should have this is IEE Computer society.
0:58:15.5 Brian Geisel: Yeah, you read and I'll judge.
0:58:17.1 Harriet Koramoah: Yeah, I'll get. We can have the link there in case somebody wants to read it. But the first one is safe awareness which I thought that was interesting. It's so the description is it's essential for software developers because it helps them understand the emotions, behavior and knowing your strength, being honest with your skills and much more. So I don't know what safe awareness is. Have you heard of that?
0:58:45.6 Brian Geisel: I have no idea what that means.
0:58:47.1 Harriet Koramoah: I don't know what that means either. It's just an important skill to have. Supposedly communicating well, managing emotions, recognizing your limit. That's what safe awareness means. Okay. Okay. How about critical thinking and problem solving? Do you look for that?
0:59:06.0 Brian Geisel: That's huge. It's in fact it's probably a hard skill.
0:59:09.7 Harriet Koramoah: Really?
0:59:10.5 Brian Geisel: Yeah. I mean I would think.
0:59:12.1 Harriet Koramoah: I figured a lot of them are problem solvers. Don't you code to problem solve?
0:59:16.1 Brian Geisel: That's exactly right. Is coding is solving problems. We just happen to use software to do it an awful lot. So that's the job. Problem solving is the whole job.
0:59:25.7 Harriet Koramoah: Yeah. Shouldn't you have it in general?
0:59:27.4 Brian Geisel: Yeah, absolutely. Absolutely.
0:59:29.1 Harriet Koramoah: But it's still something you look for. What about open mindedness? Open mindedness.
0:59:34.6 Brian Geisel: In fact it's something we test for in our interviews is you might give us the right answer. We might tell you we don't want that answer. We want it a different way. And you will see some people who cannot come up with another way to answer the question. And sometimes the way you came up with that you're so sure is the best answer is not the best answer because of context. Maybe it's the team is better in a different technology. So even though that's not the perfect technology for it, maybe we should solve it in this other technology, anyway. So given context that might not be the best answer. What else could we do? And some people will just get stuck in a rut and can't break out of that. That's huge.
1:00:16.9 Harriet Koramoah: Adaptability is important. The next one they have is time management. This one I don't need to ask you because I 100 agree. I am the... This is the reason why I work here. He cannot manage his time. Maybe he can. I won't say you can't. He is cutting my check. So he does. He can manage his time. So I'm not going to say yeah.
1:00:39.0 Brian Geisel: And I'll turn that one into a little bit a medium hard soft skill. I don't know, medium.
1:00:46.9 Harriet Koramoah: Medium.
1:00:47.6 Brian Geisel: What's. What's between hard and soft?
1:00:49.3 Harriet Koramoah: I'm sure is medium.
1:00:50.6 Brian Geisel: A doughy skill? Something. Anyway, one of the things is like, I don't know how much time management but knowing how long something's going to take.
1:01:01.8 Harriet Koramoah: Yeah.
1:01:02.6 Brian Geisel: Really, really difficult for developers. It takes effort, it takes experience to understand how. No one's ever done this before. So how long is it going to take? That's a really difficult.
1:01:14.9 Harriet Koramoah: You're not talking about time management just to do your work. You're talking about being able to like assess if you have a project, if you be well, how long that takes you to do it.
1:01:25.5 Brian Geisel: Yeah. And I say it because the time management. I like this because it's interesting discussion points. The time management standpoint, I don't know, Some days I code 12 hours. That day I didn't really need to manage my time. I just sit in front of my computer and work.
1:01:40.2 Harriet Koramoah: Right.
1:01:41.2 Brian Geisel: So in that sense, the time management, in the way you manage time or me being CEO, I have to manage my time. That's important to CEO. Yeah, it's important to developers. But I think in a different way now somebody's going to comment on this and have a great way that everyone needs to manage time as developers. But.
1:01:58.8 Harriet Koramoah: True. But like, that's so cool. That's so interesting. I think this is why I like being in this field so much. Not that everybody here is so different, but it's like you take the strict things in the world that everybody's supposed to be doing and then you guys just flip it. I love that. I love the fact that time management means something else. It can mean something else here. Okay. I think the other one is communicate. The last one is communication. Actually, no, I have one more actually. I think that's interesting. But yes, another one they have is communication.
1:02:30.3 Brian Geisel: Communication is unquestionably huge and really hard because as developers we often that whole thing we're talking about music, we learn independently.
1:02:41.5 Harriet Koramoah: Yeah.
1:02:42.1 Brian Geisel: The way we learned it was by ourselves. And now I have to work with you. What are you crazy? Yeah, I do this by myself. So as you're building a big team, that communication, it's sort of built into us to not communicate.
1:02:58.5 Harriet Koramoah: Yeah.
1:03:00.0 Brian Geisel: And so that experience and that recognition that, hey, dude, you're going to have to communicate for this to work, that it's not only is it an important soft skill, it's probably the hardest one for developers to have.
1:03:14.0 Harriet Koramoah: Yeah. When I read the article, I remembered something you said once you're like, I don't like when you will touch my code. I was like, oh, I guess he has problems with that too.
1:03:25.7 Brian Geisel: Yeah.
1:03:26.2 Harriet Koramoah: So that's like. And I'm sure a lot of people don't like. And I can tell because the one time I did try, my hands are coded. And I was like, oh, why are we changing that?
1:03:35.5 Brian Geisel: Yeah, it's very personal.
1:03:37.5 Harriet Koramoah: Yeah.
1:03:37.9 Brian Geisel: Again, kind of like writing music, like, if you write a. It's very personal. I had somebody one time, lovely, lovely man, and this is the kind of communication thing. I come into my office in the morning. I haven't even sat down yet, and he is bouncing outside my office up and down. And this is what he says, I fixed your code. I fixed your code. I found a bug in your code. I fixed your code.
1:04:01.4 Tony Campbell: Yeah.
1:04:02.1 Brian Geisel: And I was like, if you Such a sweet guy. And he didn't have the recognition that someone else might be hurt that there was a bug in their code. Right. But. And I knew that about him, and I was just. In my head, I was like, if you were any other man, I would kill you where you stand. But he was so happy that he was able to fix the bug. And that's great. I was happy for him I was happy that he was happy. But that piece of, like, that's good for him to learn to communicate, that somebody else might not be that excited about it. But also important on my side to go, hey, he doesn't get that yet. And he's not being offensive.
1:04:39.2 Harriet Koramoah: Do you think that man will hear this podcast and say, he could. Why is he throwing shade at me?
1:04:46.4 Brian Geisel: Oh, I don't think he'd ever remember that was him. And if you do, I love you.
1:04:52.2 Harriet Koramoah: Okay, the last one we have is patience.
1:04:56.3 Brian Geisel: Yeah.
1:04:57.4 Harriet Koramoah: That's the conclusion of the soft skills Engineer Chef having patience. And I was like, what does that mean? Does that mean you guys are angry or something? Like, what is going on?
1:05:09.7 Brian Geisel: Yeah, patience is a good one. I think in life, patience is a really important one, and I think you can get yourself into trouble with impatience. And so I don't know that it's the most important one, because it's also important to have a sense of urgency. And, like, I got to get this done. And so you don't want to have so much patience that you never get the code written because you're like, oh, we'll get there. But also, you can move so fast that you put in horrible hacks instead of taking the time to write it the right way or you didn't, the communication part, you didn't wait for someone else to finish something that they should be doing. So, so I can see the patience one. But I would say on that list, like by far the biggest one is the communication issue. That's huge.
1:05:57.7 Harriet Koramoah: Yes, that, that was one I agreed with too. And before we close off, I just want to throw a question at you. If let's say you had a mentee who was a young software developer. There's a lot of young software developers out there. People know this field makes money now. So a young mentee come into this field, right. And just like Tony, they're seeing a new field in this or let me phrase it better, I kind of want to say something like if they're like Tony, they started with something they really like, maybe physics or chemistry as you said, but now wants to push into robotics or something. What are like the three advice or maybe two or one. What is the advice that you would give this person? You know, they probably have some problems with patients or they're probably proud of the work they do. They've never been told that they're wrong. You know, they've never been challenged. They've been the best in their high school, middle schools, college. They've been the best. They've probably a little bit looked down on people because you're so good or maybe disregarded people because you're so good and they're not good at working with others. What would be your advice?
1:07:14.7 Brian Geisel: So I actually, years ago I had a young woman called Calmy and say, almost this. I. They went to become a civil engineer and they were like, I was at a technical school. How did I not know software was a thing? And they started writing some software, realized they loved it. They said, how can I get into the industry? And so they're, first of all, I think on that side, I want to just hand you confidence and have that confidence that you can do it. The number of things I see where top tier developers do that less experienced or developers who aren't as sharp don't do is that they're afraid to go after the problem. They're like, ah, that's probably not a problem you can solve. And the top tier developers, like, then I guess I'll be the first one to solve it.
1:08:07.8 Harriet Koramoah: Oh wow.
1:08:08.3 Brian Geisel: And they'll try anyway. So that confidence, yeah, I don't, I don't know how to just give it to you, but I want to just give you that confidence. Go, just try stuff like what's the worst that could happen if you don't succeed. If you can't create it like just try, you already failed. If you didn't try, you might as well fail trying instead of fail sitting in a corner knowing you're right. So try, get, just give it a shot. There's nothing to lose. And that also will make you a better developer. If you're just getting into the field or whatever, that will make you an another a better developer. The other thing that I would add to soft skills that I think is crucial that they didn't have on their list over there is humility, which sounds like a funny contrast to the self confidence to go try things, but you need to have the self confidence to just go try stuff and instead of going ah, probably isn't possible to do that freaking try. And then when someone else says to you, hey, have you looked at this way to do it? Well, no, I have a way that lack of humility is going to hurt you.
1:09:20.0 Brian Geisel: I know immediately you don't know everything you need to know about software development because you're blocking great ideas. And that humility to go, you know what, there's people around me who have great ideas who can help me grow. That humility is a huge, huge soft skill and one that we definitely check for in interviews as best we can. That's so important. And have that humility to make... To grow from others and to learn from a mentor. Learn from, learn from somebody who knows less than you. If you can learn from people who know less than you, there's no stopping your career or your learning trajectory.
1:10:00.9 Harriet Koramoah: That's really great. I like hearing that. I think that can go for any high achieving field. Like anybody who's a high achiever. Like if you're really good at your craft, you probably need to practice a little bit humility because people might come in one day and see a problem that you never saw.
1:10:17.8 Brian Geisel: Yeah.
1:10:18.2 Harriet Koramoah: So definitely an advice I'll take for myself.
1:10:21.0 Brian Geisel: Yeah, that's right. Okay. One thing I want to interject for you that will let make fodder for all the comments is our set of priorities. This is in priority order on how we think about code reviews and what you should be thinking about code reviews. And I know we all have strong opinions about this, so I'm going to give you the things that we prioritize. So number one, architectural issues with other modules. Will the way this is developed be an issue for anyone else's feature modules, implementations, the code you wrote breaks somebody else's code. That's the number One thing I want to catch, number two bugs. Number two on our priority list is, are there bugs in the code? And this is one of those things where people will say, that's not possible to check for in a code review. I promise you it is. But it's way easier to assume that it's not possible. And it helps the final code if you can find bugs in it. Third, modularity, code reusability, good coding practice and consistency with surrounding code. Those kinds of stylistic things are third on our list. Fourth is style conformance. Are you complying with the coding standards at Geisel or the Python coding standards or whatever, Linux kernel coding standards, whatever applies to that.
1:11:45.9 Brian Geisel: Fifth, anything else of importance that pops out at you. And number six, after anything else of importance that jumps out at you. Grammar and punctuation. In fact, if we ever do a live code review with a bunch of people in a room looking at it, we have a rule. If your first two comments on the code revolve around comments or grammar and punctuation, you are invited not to speak again for the rest of the code review because we want you looking at the code. It's easy to go, hey, that doesn't have a period in the comment. We don't care. We want to make the code better. This is not a grammar test. And so the absolute last thing you should be looking at is grammar and comments. So those are the Geisel Software six priorities when doing code reviews. Hey, thanks so much for joining us, Harriet. This has been great. I like this episode. This is a lot of fun. And don't forget, click the like button right here or not here. It's here. Do you have it? Subscribe all that stuff. Check out Geisel Software if you want to see Open positions. We're hiring for it here in Geisel and we hope this brought you some value today. Thanks, everybody.