Crafting Code Podcast

~/podcast

$ cd episodes/015-starting-over

~/podcast/episodes/015-starting-over $ ls -1a
. .. episode-summary.txt references.txt themes.txt transcript.txt get-mp3.sh
~/podcast/episodes/015-starting-over $ cat episode-summary.txt

Starting a new job can be a nerve-wracking experience. There's a lot to learn if you are going to be effective in your new position. Sometimes change is forced upon you, but there are reasons to voluntarily start over. It can be an important part of our personal or career journey.

~/podcast/episodes/015-starting-over $ cat references.txt ~/podcast/episodes/015-starting-over $ cat themes.txt ~/podcast/episodes/015-starting-over
$ cat transcript.txt

[00:00:16] Allan Stewart: Welcome to episode 15 of the Crafting Code podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been thinking about how to instruct others in the patterns needed to break up a monolith.

[00:00:33] Dave Adsit: I'm Dave Adsit, a CTO, and I have been thinking lately about working through influence.

[00:00:40] Allan Stewart: Today we're missing our friend and co-host Matt Baker due to the difficulty of scheduling around the holidays, but we're going to press on and talk about the topic starting over. Now, this topic isn't about rebooting a project. Today we're going to be talking about starting over when you're making a shift in your career or moving to a new position or even to a new company. To kick things off, Dave, what do you do when you find yourself in this position that you're starting a new job or even it might even be in the same company, but there's something new about what you're doing? Maybe you moved to a new team or you took on a new role. What are the things that you need to do?

[00:01:24] Dave Adsit: I've been in business many times, perhaps too many times. I was just looking through my work history and I have worked for about a dozen companies as a software developer. And so I've had a couple of opportunities to learn. And the first thing that I like to do is gain context. That is essential to doing good technical work. You got to jump in there and find out, what the team's doing, how the team works, where the team is headed, what is the product or project that you're even building? I have struggled from time to time with gaining context. Instead, I'll just jump in and say, you know, I just read Monoliths to Microservices and I've got a solution. And they're like, that isn't a solution to any problems that we face. And I'll be like, nope, I know it's a solution. All the problems. It is also the cause of a whole new set of them. So I would say that the most important thing to do in a new position is gain context.

[00:02:37] Allan Stewart: I haven't started over quite so many times as you, Dave, but I would agree. Gaining context is so important because coming in new, you don't have the history of the company. We've talked in a previous episode about the storytelling aspect of a company. And those stories are really important. You don't know why things were done. You're just kind of hit with the current state all at once. Probably things are different than you expected or knew, especially when you're completely shifting, right? You're going into a new company and you don't have any experience even with who the people are. When you change positions inside an existing company, that can be a little bit easier because you carry some context over. You know, a lot of the people, you know, how the company operates generally. You might be moving into a different team with people you haven't worked with. But when you start at a new company, it's all fresh. If you don't spend the time gaining context, it can be really easy to go off on a tangent that just doesn't make a difference. That doesn't matter. You pick your personal soapbox that you're going to jump on and say, Hey, this is a thing that we have to do. And it might not actually be the most effective way to make a difference. It might not be really you started at a company where you started at a company where you started at a company where you started at a company where you started at a company where you started at a company where you started at a company where you started at a company where you started at a company where you started at a company where you started at a company where you started at a company where you started at a company where you started at a company where you started at a company where you started at a company where you started at a company where you started at a company where

[00:04:24] Dave Adsit: One of the things I like to do in that phase of a new job is to give people the benefit of the doubt. I do believe that everyone is doing the best they can with what they know at the time. I have never worked with someone who is actively sabotaging the team, the project, or the product. You may not like the way things are, and you may think, well, they hired me to fix the things and improve them. Obviously, that's why I'm here. But remember that everybody did the best they could with what they had at the time when they did it. And that context changes over time. And so understanding the decisions that were made is super critical. You mentioned getting the stories. There's usually someone on the team, like the team shaman type of a person, who can tell you the stories of why it is the way it is. Why they chose PHP instead of Python. Why they chose Python instead of Java or whatever. There's reasons why the system is in the state that it's in. And those reasons may not seem like good ones in retrospect. But I expect that they did feel like the right choices in the moment. If you're lucky, there's going to be stuff to help you gain context, like source control. Not every job that I've started did I walk into a team that had source control. But if you have source control, which you should, then that is something that's going to be helpful in understanding the evolution of the code. There's also hopefully things like ADRs, architectural decision records, that tell you explicitly what was decided when and why and what evidence was used to support it. And also what evidence we would consider to change it. There might be wikis. There's hopefully someone who is operating as a product owner, product manager, scrum master. Someone in the product space. Who can help you come up to speed on where the product came from and what the direction of the project is. I can tell you from personal experience, it can be hard to come in and be humble. First of all, you can be really excited about this new job. Sure, these people have all been working here for five years, but you just got here. And you are excited to not be going where you were going before. And you're excited to come here instead. And you've got all these new ideas that are new to this. This group, maybe. You can assume that they are because they aren't doing them. And that's good. Bringing that beginner's mindset into a new context and questioning. Question, question, question, question, question. Can be a really good way for you to understand the system. But also for other people to consider the system that they're working in, in a different light. There's a balancing act there between learning and also doing things the way that you think. Yeah. Yeah. To be done. For example, I would bring test-driven development into teams. And not every team was in the same level of readiness for that kind of a paradigm shift.

[00:07:36] Allan Stewart: You don't want to capsize the boat with all of your changes. That's one of the keys as you're coming in. Yeah. You're going to see some things that you want to do differently. If you change too much all at once, then it makes people fear. What's happened to their job? What's going on? Why should we listen to this new person? Because things maybe were fine before or so they felt. So you have to be really, really careful. And I liked what you're saying about people. You really got to get to know the people because we work in socio-technical systems. And if we just go in and we're like, oh, technology, we need to change the technology because that's where we have expertise. And that's where we have a lot more knowledge that transfers easily. It's a lot easier for me to say, oh, I know about this. I know about test-driven development and I can apply it in a multitude of different languages. And here are some of the benefits and things that I've seen. And that transfers over really well. But it's really hard to transfer over to new relationships, to new people and understanding what kinds of social structures are in place. Like, why have they organized the people the way that they have? There's what the org chart says. And then there's what is actually important. Those aren't always the same. In fact, they're almost never the same. Because there might be somebody that you just need to get to know who has some important information for you. Or you need to watch out because there's some kind of a political situation that you are just unaware of that's going on. And you don't want to step right into the middle of that. So I really like the idea that you suppress your own ideas. Yeah, you've got some valuable experience. And that's part of the reason why you moved to this new job, most likely. I mean, it's pretty common in our industry. People, when you're starting over, to do so to get a raise, to try a new opportunity. Or sometimes you start getting recruiters reaching out and saying, hey, we want you to come work with us because you're good at what you do. And that's great. And you need those ideas. But you've got to kind of suppress them at first and say, nope, I'm going to just put this in the back of my head for now. And that might be a while. Depending on your position and depending on what you're doing, you might pick a few things early on. But a lot of this stuff, you're going to be putting on the back burner for probably months before you're really going to be ready to tackle some of those big changes. So you don't want to forget your instincts. You don't want to forget the things that got you to the level that you're at. But also you need to just stop and ask questions. You say, okay, what is actually going on? Why are things the way that they are? Discover what those needs are. And then you can start thinking about what the options are. Because you're not going to go off half-cocked and cause a bunch of disruption that isn't necessarily helpful. But you actually understand a particular business need that you're solving with the changes that you're bringing in.

[00:10:37] Dave Adsit: So you mentioned instructing people on patterns in your intro. I'm thinking about that here. What is the solution to a problem in a context? You need to know what the context is. And that takes time. It takes time to learn and absorb and to ask the right questions to the right people and figure out what's going on so that you know if this pattern applies here. Sure, it's a solution to the problem we have. But does it work in the context that we're in right now? If it doesn't, what do I need to do to move forward? What do I need to do to move this organization closer to the context where this pattern applies? Or what pattern do I need to select and apply instead? There's a lot of things that I would think are pretty much basic, gimme, every team should be doing them, etc. And that's going to include things like source control, test driven development, continuous integration. These types of tools. I want those to have a place in my mind. I want them to happen on all of the teams that I work on. I want to see regular deploys. But I've worked on teams where we were very, very far from that type of an environment. And trying to push for that environment would have very likely caused a fight or flight response with some of my peers and subordinates. I'm reminded of Linda Rising's book, Fearless Change. Where the patterns in there are around. Fearless Change. A lot of making change happen effectively is about understanding where you actually are right now. So let's talk a little bit about reasons why. You know, we've talked about what you would do when you first jump into a new position or company. But why would you even want to do that? Why would you leave your comfortable developer cave? I assume all developers work in caves.

[00:12:46] Allan Stewart: The most obvious one is when bad things happen. Most startups fail. And so you could get laid off. Big companies also do layoffs. Or, you know, sometimes we make mistakes. It is not uncommon for technologists to get really passionate, especially about technology and the way that we think that things should be. And that can sometimes get us in trouble. It can lead to us stating these strong opinions. And even if we're having strong opinions that are weakly held. The way that we emphatically go about telling our strong opinion can sometimes land us into trouble. Directly, if we're confrontational about it. But also sometimes it can be pretty subtle. Where, just for, you know, political reasons essentially. Somebody decides that you are in the way of their ambition or steering things off course. So that's, you know, the obvious reason to start over. Is because you were forced to. But voluntarily, I think that there's also a lot of interesting reasons. Career progress is one I see a lot. And that may or may not include getting a raise. Sometimes that's the only way that you can really get a raise after a while. You've been at a company and you've been growing and you've been demonstrating value. But you just can't keep. You've been getting your annual 3%.

[00:14:06] Dave Adsit: Getting the raise. Yeah, exactly. Until you hit the salary cap for that band. Yeah. At which point you get 0%. Yeah.

[00:14:14] Allan Stewart: But more than that, I think. Are you learning and growing? Is there something that you want to do that isn't available in the position that you're currently in? And that can be a good reason to voluntarily start over. That's one that I've seen a lot of people cite as reasons for starting over.

[00:14:31] Dave Adsit: One of the common tropes that you hear over and over is that people leave their boss. If you have a boss that you don't get along with or don't work well with. There's some kind of conflict there. Personality or style or even technology. Conflict with a boss. People will leave that boss. In my own experience, it's been that. But also the grand boss. Your boss's boss. Like you may get along just fine with your boss. But maybe not so well with your grand boss. Or your grand boss has a vision you're not aligned with. That puts a lot of responsibility on people in management to know what's going on with their team. And to make corrections around anything that is not aligned with their team. Or not going well with the team and the team members. So if you are in a management position, that's a pretty heavy responsibility. And we don't always get it right. Or sometimes we also see that there isn't a resolution to the situation without drastic change on one side or the other. So those are situations where I've seen people voluntarily leave. And also where I've seen people leave not so voluntarily. You can use whatever euphemism you want. But people do get fired if they cannot get along with the rest of the group.

[00:15:51] Allan Stewart: Definitely. Another good reason to start over is burnout. Sometimes you can just get tired of what's going on. It's emotionally draining. It can be physically demanding at times. I think sometimes we underestimate how much knowledge work jobs impact you physically. Because you're just sitting at a desk. Or you go to a conference. And you get wiped out. And you're like, how can I be so tired? And all I've done is sat around listening. Your mental state has a lot to do with your physical state. And so burnout can be very impactful. It can cause stress. And it can cause other problems. It can also just kind of leave you feeling this weight of responsibility that you can't quite manage. You want to keep working. You want things to be working out. And you wish your impact was making more of a difference. But it's just not. That can be a good reason to start over. To put yourself into a new context. Sometimes it feels like we bounce from problem to problem. And we're just reliving these same issues over and over again. But the truth is that going into a new context gives you new opportunity. It gives you these times to change. And so if you're starting to feel burned out, even doing the same kind of work in a new context can really lighten that load. And prevent you from having problems that carry over into your personal life, into your physical health as well.

[00:17:19] Dave Adsit: We could do an entire episode about burnout. And I think at some point we should. One of my wife's good friends is a psychologist. And so talking about burnout and how that presents in the workplace, it is very similar to a depression, a clinical type depression. And I know that there are certain things that we can do. Like talking about trauma or talking about stress or talking about depression. These are all things that have clinical definitions and then social definitions. But there is something to the idea that burnout is a type of depression. And it's a contextual depression that is created by the quote unquote trauma of the environment that you're working in. And sometimes there isn't a sense of There isn't anything you can do to fix it. You just have to extract yourself from it. That's one of the things that we talk about in changing your personality, changing your habits, changing your behaviors over time. You have to take yourself out of the context where these things become a problem. So sometimes I like to think about the mental patterns of burnout being similar to the habits or patterns of alcoholism. So if I've got this pattern where I go to work and I get frustrated, that can be similar to the pattern of an alcoholic. I go to the bar and I get a drink. And if you say, well, I'm just going to go to work and not get frustrated about the lack of progress in this area. That's like being the alcoholic who says, I'm just going to go to the bar and not have alcohol. I'm just going to hang out with my friends and it's going to be fine. It typically doesn't work out super well. You are feeling any of the symptoms of burnout. If you're feeling lack of motivation, overeating, under eating, if you're feeling angry all the time, if you're feeling fatigued all the time, if you're feeling any of these symptoms, there is no shame in going and talking to somebody about it. We're not sponsored, but man, we could be better help.com online clinical therapy. Just do it. I know that sounds like a joke, but is dead serious. Yeah. As you go. As you go. As you go. As you go. As you go. As you go. As you go. As you go. As you go. As you go. As you go. As you go. As you go. As you go. a company where I thought we had nailed all kinds of technical practices and the team was doing super, super well. But as we introduced new leadership that didn't have the same context and the same history, the direction that we were going changed. Did we do all the technical practices I like? Yes. Were we starting to slip away from some of the things I thought were important? Also, yes. So which is more important psychologically? Is it the position or is it the direction you're headed? Is it more fun to be on a team that has no idea how to write code and you're helping everybody learn how to do it and every week you're writing better code? Or a team that's doing great, but every week is doing slightly less great? What do you think, Allan? Have you experienced those two extremes? Yeah, definitely. And it's hard sometimes

[00:21:04] Allan Stewart: because... Yeah. Because I've worked at places that were great to work at in so many ways. They were financially stable or they were doing a lot of the practices that I thought were important or other things like that. So I kind of gauged it. We're really high on the chart. This is like a nine out of 10 company that I'm working at. But that feeling that it could be going from a nine to an eight is really disturbing. Or an 8.9. Or an 8.9. It can really preoccupy your mind where you're just like, wow, but things are getting worse. And even though it's like way better than that job that you had at some other point that you hated, still you get into those same kinds of thought patterns where you're like, oh man, I don't know if I want to be here anymore. I think it's important for us to consider both aspects of it. It's not worth throwing away a good job because you thought that things were going downhill. You need to ride out the storms a little bit because no matter where you go, you're going to have trouble. They call it work. They don't call it fun. I'm not going to fun today. Although hopefully you enjoy your job, but it is work and it is difficult. And so you don't want to put too much stock in your perceived directionality. But on the other hand, it can be really enjoyable to be at a place where you're like, hey, this job is only a five, but it's on its way to be a six. Yeah. Yeah. The impact that you can have there, the enjoyment of seeing things improve can really affect your morale, can really be an exciting place to be. And it can look really good on your resume too, to be able to say, oh, I was at such and such company when this transition happened, when we broke up the monolith and built out a distributed system or when we IPO'd.

[00:22:56] Dave Adsit: Mm-hmm. Yeah. So when I think about position versus direction, I think about it in terms of times and seasons in our career. Kim Scott is the author of Radical Candor and does the Radical Candor podcast. And recently she's talked about the difference between rock stars and superstars. Rock stars are those people who are the solid contributors coming in, doing their job, getting it done. And it's great. And those people are super awesome to work with, but they're not necessarily pushing you to the next level, taking you on that rocket ship, right? Like the superstars would be. And so depending on what phase of your career you're in, position versus direction, you'll weigh them differently. So if you are in a rock star phase, then position is probably more important to you. And if you're in a superstar phase where you're looking for growth, you want the next thing, you want to achieve greatness, you want to get that promotion, you want to get this system into 2,000 microservices, you want to do 100 deploys a day, whatever it is that you're aspiring to as a superstar, direction may be more important. If you're on the rise, rising from a lower position is easier. We say sometimes that when we calculate the uptime of a system, each additional nine costs you 10 times as much investment. I think context matters a lot there. I personally feel matters a lot there. I think context matters a lot there. I think context matters a lot there. I think context matters a lot there.

[00:24:48] Allan Stewart: I think context matters a lot there. I think context matters a lot there. I think context matters a lot there. I think context matters a lot there. I think context matters a lot there. I think context matters a lot there. I think context matters a lot there. I think context matters a lot there. deserves. The person giving me this advice was trying to get me to come and join their company. And the irony is that I didn't stay very long with that particular company because they didn't deserve my loyalty. But it was good advice nonetheless. In these times and seasons, you need to consider how do you extract your own personal identity from the work that you've been doing and the company that you work at? Because sometimes we get those all wrapped together. I will say though, that it's important for us to remember that starting over is hard. And so you want to be sure, right? Like you don't want to just do these things on a whim and be like, oh, today was a hard day. Most days are great and I'm happy and I love coming into the office and everything's good, but today was a hard day and so I'm quitting. You got to be careful that you maintain that context of where are things generally and not just let a particular season dominate your thinking, but also sometimes you legitimately need changes.

[00:26:10] Dave Adsit: So one of my friends, somebody that I participated in a lot of meetups and discussions with over the last several years has advice that I distill down to ABQ, always be quitting. doesn't work super well, but it's, it's the idea that this particular person is always looking for the next opportunity. And I think one of the things that he would say is you can either change your company or you can change your company. Obviously someone who's much more focused on the directional aspect than the positional aspect of where a team is and its progress. I've thought about that advice a lot over the years. And, and I've applied it in times when I felt like I've been more loyal to the company than they were to me. I've also applied this advice to people who are early in their career. I think that there is an important journeyman phase of a software developer's career where you should be working at a job for 12 to 18 months, and then a new job for 12 to 18 months and a new job for 12 to 18 months. When you are young in your career and you are learning a lot because, because getting exposed to all those contexts is going to provide you with a huge bump, a huge boost in your ability to onboard concepts, understand different ways of working, learn which ways work effectively for you. And there's nothing sadder to me than seeing someone who has been stuck for 15 years in the same job with virtually no progress and no learning. And they have equivalent skills to someone who's three years out of school, because the company that they've worked in has had them churning out widgets as opposed to using their abilities as a software developer to produce bigger, better things. And we don't always know, right? Like we don't know that we are not making progress in our career if we are stuck and seeing a new context and working in a new environment can really open up a lot of opportunity. It's very important for us as software developers to be learning and growing. And if you are not learning or growing in your team in some way, then it's probably time to move on.

[00:28:30] Allan Stewart: I regularly read books with my son. We try to take some time where I'm sharing with him books that I like. I try to read books that are a little bit over his level to introduce new concepts and vocabulary and things. And we've been reading the Chronicles of Prydain, also known as the Black Cauldron series. And we just finished the fourth book in which the, you know, reader reader reader reader reader reader reader reader reader reader reader reader reader reader reader reader reader reader reader reader reader reader reader reader reader reader this person's so good at weaving I want to learn how to weave my own cloak and he does and just like when he made his sword at the blacksmith shop he's like yeah this was cool but this isn't this isn't what I want this isn't me and then he goes and he wants to be a potter and he thinks that that's just this is going to be the amazing thing look how how much beauty you can create in this and he just he can't satisfy himself with that work and so he goes through a lot of hardship through this because he's like I can't figure out what I want to be when I grow up essentially and I think that we need those kinds of experiences in our jobs we need to have some of those bad things you need to build up some war stories that you take into new contexts because it gives you perspective and because you learn something about yourself as you go through these things I totally agree with what you're saying Dave when you stay in one place so long that you become stagnant it's hard to tell that's happened but it's also very very sad you don't want to get into that point where your pigeonholed your skills have atrophied and it's not just technical skill right like that happens a lot we see that with people who very niche technical skill because they just kept doing the same thing over and over but also it can be understanding well how do I work well with different kinds of teams how do I work well with different bosses that have different personality types all of those things can help us to grow

[00:30:45] Dave Adsit: and give us more opportunity yeah I'm reminded of a whole bunch of cliches like what you see is all there is or it's better to be a big fish in a small pond than a small fish in a big pond and these are ways that we can basically convince ourselves to stay loyal and stay stagnant versus moving on moving forward creating opportunities for learning learning and growth are painful because you have to start by accepting that you don't know how to do it and you have to start by knowing where you stand where you stand where you go where you go where you go where you go where you go where you go where you go where you go where you go where you go where you go where you go where you go where you go where you go where you go where you go where you go where you go where you go where They took fewer YouTube breaks or coffee breaks or whatever it is, whatever kind of breaks people do. So I don't know how true that actually is, this Hawthorne effect. I know that I feel more productive when I'm starting something new. Maybe that's the greenfield effect. Anything is possible at this new company, unlike the old company where everything was rigid and fixed and I couldn't make any changes.

[00:32:10] Allan Stewart: One more reason that I think of where you might want to voluntarily start over is a lack of influence. Sometimes in a job, the situation, the context that you're in, you can end up in a place where you just aren't making the impact that you want to have. Or you can't convince people of a change that you think is necessary. And you're just kind of at odds with the company. And that can be a good time to start over as well. Even though you might be good at what you're doing. You're still learning. There's still new things to accomplish. If you can't actually make traction on those things, it gets frustrating.

[00:32:48] Dave Adsit: Yeah, most of us want to have a positive impact in the space where we're working. That is one of the things that characterizes knowledge workers is the desire to have a positive impact. And so if you feel like you're having a lack of impact or have a lack of influence, then that is definitely one of the reasons. Why someone would move on. And that doesn't even necessarily have anything to do with the team specifically that you work on. The context of the business around you could have changed. Maybe your department got moved under another leader. And that new leader has a different way of working than your previous leader or someone else leaves or something. So there's a lot of reasons why you might not have the same influence or impact that you once did. It's certainly easier to have a bigger impact. You might have a bigger impact in a smaller organization. And if your organization is successful, it's growing. And if it's growing, your impact is diminishing. And so for entrepreneurial personality types, that can be frustrating. But it's also a sign of success. You have done well enough at the early phases that you've built something you no longer want to be part of. So take your win and go start somewhere new and do it again.

[00:34:10] Allan Stewart: So to summarize our discussion today, when you start over, there's a lot of things to do. But I think the key to it is patience and humility. Asking a lot of questions and learning why things are the way that they are in your new context. Starting over is hard. Starting over is definitely scary because you're jumping out into the unknown. But that can also help you to grow. Help you get out of the funk or get a raise. Or just have a better opportunity. To try something new. As always, we recommend that you join a community of professionals by attending a Software Crafters group or meetup near you. The Utah SC group at utahsc.org meets the first Wednesday of each month virtually. Maybe we will talk about starting over with you there.

~/podcast/episodes/015-starting-over $ cat ../../copyright.txt

Copyright © 2026 - Crafting Code Podcast