What Does a Software Developer Do?

About this Episode

A discussion about what software developers actually do and the skills required to be successful.

Transcript:

MIKE: Welcome to another episode of our podcast that we will hopefully soon have a name for. We're a number of episodes in; you'd think we'd get that covered. But I guess we're focusing on the material. Today we have what I think is a great topic. We're going to be talking about what software developers actually do and what skills are required to be successful as a software developer. I think this is an interesting one. We've got several of us here this morning. Sam, do you want to introduce yourself?

SAM: Yeah. My name is Sam. I've been with Acima for five years, moved into application support about six months ago. Basically, my role is to just identify any issues in production and relay it over to our engineers.

MIKE: This is a good topic to have you on, and Damon, who I'll introduce in a moment because you're wanting to maybe move into engineering, so this is a good topic where to put your focus. Damon, do you want to introduce yourself?

DAMON: Yeah. So my name is Damon. I've been with Acima for about a year and a half, also been in the application support role for about seven months now. And just like Sam said, we basically identify issues, troubleshoot, and then report over to the engineers to try to get those resolved as soon as possible.

MIKE: Right. Thank you. Dave, do you want to introduce yourself?

DAMON: Howdy, howdy. My name is Dave. I'm in the development team over on Atlas. And my job as a software developer and my role on this podcast is to serve as an example of what not to aspire to probably, perhaps, serve as a warning maybe to others when possible.

MIKE: Noted. [laughter] And I'm Mike. I'm also an engineer here at Acima. I've been here for some years. And I've been a software developer for quite a bit longer than that. And I'm excited to talk today. I'll lead into this conversation.

I think that through media, people sometimes get a misleading impression of what a software developer does. They might get an impression we spend all of our days at blackboards writing obscure Greek symbols or perhaps coming up over and over again with the great, new idea that's going to change the world. Maybe they think that we are alone at a computer all of the time with a great deal of caffeine and trying to bang out that next great thing.

And there may be a little bit of truth to all of those things. But all of them are, I think, fairly misleading. They don't really capture most of what we spend our time doing. And I also think they don't necessarily capture what are the most important skills that make a person successful as a software developer. And I might start this conversation with some suggestions about what software development actually is.

If I were to say one thing, and this is something that's fairly different from what happens in school and also from what happens in media, is that software development is, in most cases, a fundamentally social activity. We build software together as a group. That may seem surprising, like, you know, how do you write code together? Well, there are actually a lot of ways you can write code together. There's a common practice in the industry of pair programming where you literally have two people sitting at the same desk.

There are a lot of other ways to collaborate as well. People plan together. They remotely pair together so somebody who's just kind of watching your screen and chatting with you as you go. There are code reviews. There are discussions that come up about the code. There are probably a number of other collaboration channels that I'm not even thinking of. I do want to point out that software development, software engineering is very much a social phenomenon. And the people who tend to be quite successful are people who work together with other people.

The second thing I think is important to understand about software development that sometimes people don't understand going in is that nobody knows how to do it. I'm overstating a little bit, but -- [laughter]

SAM: Only a little.

MIKE: Yeah, exactly. [laughs] You're talking about a field that is so vast, that is changing so quickly, day to day.

DAVE: And so young.

MIKE: And so young.

DAVE: There’s a whole group of people in the software development community who vehemently react to people claiming the title software engineer because the next youngest field of engineering study is chemical engineering, and that's 700 years old.

MIKE: [laughs]

DAVE: And they're like, yeah, go learn all the best practices, and then bake on them for half a millennium and then come back and talk to us.

MIKE: And to that point, we're not very good at it yet. I am maybe talking a little bit tongue in cheek but not as much as you might think. There are a lot of things we just haven't figured out very well. The best practices in the industry are still evolving. And none of us really know in great depth what we're doing. There's no set of standards. So we're figuring it out as we go.

I know Google is a verb now referring to a specific brand, but search engine of your choice, which is usually Google, is a primary tool for developers. We spend a lot of time just searching, figuring out how to do something, or we ask somebody, or we read up on how to accomplish something because we don't know how to do it. And that is not a sign that we're doing something wrong.

Acknowledgment that we don't know what we're doing is actually one of the most important things I think it takes to be successful as a software engineer because once you are aware of what your limitations are, you know where to put your effort. You know that developing search skills and the ability to work with ambiguity to be able to operate even though you don't know everything, which is uncomfortable, is a big deal.

I would say there's one other thing that I think is fundamental for software development. And I've said this a number of times over my career to people who are aspiring software developers. And this doesn't just apply to software, but it very much does apply is that writing software is largely an exercise in frustration management. If that sounds scary, it shouldn't.

My kids...my daughter is learning to play piano, and she tends to be a bit of a perfectionist. And when she makes a mistake, she just has a really hard time with it, and she wants to shut down and cry and say, "Oh, I made a mistake." And I tell her...well, there's a phrase that we say all the time; mistakes are proof that you're trying. And learning to recognize that, learning to know that you're going to be frustrated a lot of the time because that's what it takes to accomplish something new that you don't know how to do.

And being okay with that, being able to live with that frustration, knowing that yeah, this is hard; it is beating me down, and I don't know how to solve it, and I'm going to keep banging at it anyway until I figure it out, is a fundamental skill and perhaps the most important skill in being a software developer because we're here to solve problems. Sometimes we think we're here to solve code, but that's really not the answer. We're here to solve problems.

I started out with quite a bit of material there for us to chew on for a bit and discuss. Hopefully, that sparks some discussion. I have other thoughts as well.

DAVE: Oh yeah. I've got five pages of rebuttal, and if I may take the first topic. No, you're bang on, bang bang on. I can't remember the show. It's a meme now. But I want to say the show was Adventure Time, and there's like a dog with glasses. I'm not sure if it's Adventure Time. But the character is this dog who wears glasses, and he's a meme now. If you just search for being bad at something, you will come up with pages, and pages, and pages of this. And it's just him.

It's a cartoon. And this is like serious life advice. And he says, "Look, sucking at something is the first step to being sort of good at something." And that is absolutely true with software development. You're going to sit down, and you're going to have people on one side of you that are saying, "Oh, there's a right way to do this. We're going to get this nailed down." There are going to be people on the other side of the spectrum that will be like, "Oh, there are 17 different ways to skin a cat, and you need to know all of them." And they're both right; there's usually a best way to do something.

And sometimes, the best way to be a great software developer is to spend ten years forgetting stuff so that when somebody shows you a problem, you have forgotten seven ways to solve that. And so you have instincts. You're just like, oh yeah, this is just that, we'll just go do that thing. But when you're starting out, yeah, you're like, okay, if I add this to that, I'm going to get this value. I can make a computer do math. Let's make the computer do math, and then we solve the problem. And that is essential.

I have individual tips and ideas. But I would say the most important thing I think you've said, Mike, is that software development is a social endeavor. It's almost a bait and switch because I definitely got into computers because they were the only rational human beings in my childhood. [laughs] I grew up in a crazy part of the world. And it's like, computers didn't bully me. And if you've ever worked with a computer, you know they're absolutely tyrannical, and they refuse to work. The computer always did what it was told, and I loved that about computers.

And it was much, much, much later in life that I realized that wait a minute, having a career in this great big raft of monkeys called humankind, boy, yeah, everything is a social endeavor. If you want to go off and solve a math problem, you can do that in your own time. But if you want to have a career, people are more important. They're always going to be more important. I learned that way late in my career, and it definitely influenced the trajectory of my career.

MIKE: If I could add on to a little bit of what you said there, you talked about going and solving math problems. I read an article I don't remember exactly where it was sometime in the last week talking about Albert Einstein, who is the kind of the canonical icon of the myth the lone genius that went off in a corner and came out with modern physics. He was working at a university with other physicists, and he wasn't even the first one to derive some of his equations. The math he used was based on what other people were working on around him.

Basically, nothing that he came up with was as radical as he's often credited for but was largely a group effort. Now, that's not to diminish the fact that he did have novel ideas, and he was able to make a leap that others, his peers, didn't make. But, and this is vitally important, he could never have made those leaps if he wasn't surrounded by that network of peers who brought him to that point where he could make the leap, brought him to that precipice where you can jump across the other side.

DAVE: Yeah. You can't integrate five different people's ideas if you don't go hang out with five other people.

MIKE: Absolutely. Absolutely.

DAMON: I think that makes a lot of sense. For you guys personally, do you feel like you guys have evolved a lot more whenever you started working with a team and became more team-involved?

MIKE: Myself? Absolutely. I was somebody who did coding by myself as a kid back in junior...well, actually, elementary school, I did a little bit. I didn't have a computer at the time. That was in the days before everybody had a computer before they had a computer in their pockets. But I did a little bit when I was quite young, and then in junior high, we had a computer, and I wrote BASIC programs in the BASIC computer language. And it was fun. I loved it. I was all alone. I had a manual that I'd pull out examples from and then try to tinker with them.

And then, in school, I largely worked alone as well. And then, in a career, suddenly, it was all with other people all day. And the amount of progress I was able to make while collaborating with other people was remarkable. And it also changed the character of my work. One thing that you do when you're learning typically is you start from scratch. You build everything from scratch because they want you to learn the fundamentals. But professionally, it'd be really foolish to build everything from scratch.

There are many decades of computing that have happened, and people have built code that is open source or has a dedicated library within the company you're working on. There is other code that's been written that you can use. And if you're doing everything yourself, you're doing it wrong in many, many ways. That's another very important thing that we should learn about software development is that it's mostly about plugging together components that other people have written because the community together builds things that are really good, and then we use those.

The novel things that we do is we take those pieces, those components, and put them together to make something happen that we want to happen. But most of the work has already been done. For example, most of us work in high-level languages, and we don't write assembly code for device drivers; there are people who do. But most of us are writing in higher level languages that are resting on interpreters and compilers all the way down that other people have written, and we probably will never modify. So it's using other people's work that we use all the time, and learning that was an important thing to me.

DAVE: Along the same lines, I remember my first full-time programming job; they left me alone in the corner of a basement. And I just cranked out code, and it was exactly like you would think, you know, just had the lights turned out and had my monitor in dark mode and all that stuff.

MIKE: [laughs]

DAVE: Yeah, I would write software the way I had always done it as a kid. I would spend hours, and hours, and hours typing code before I ever hit the compile button. And I left that job after a year and a half. And I went to a video game company, which I thought was my dream job. It turned out to be a nightmare job, but for a while, it was a dream job.

And I remember sitting down with another programmer who was a senior at the time, and I said, "Hey, can you help me with this problem?" He said, "Sure." And I'd been working on it all morning. And he came over, and he sat down, and he was looking over this. And there were obvious typos in my code. And he's like, "Have you compiled this?" And I'm like, "Oh, no, I'm not ready yet." And he's like, "Dude, yeah, no, stop. Make this compile right now. Stop what you're doing and make this compile."

And so we spent two minutes fixing typos, and we got it to compile, and it didn't work. We were ready to make the next piece of it work. But I was ready to dive into another two hours of writing stuff, grinding stuff out by hand. The point was that I had been writing all this stuff just out of my head [inaudible 14:33] And this guy was just like, no, we need to make this work, and then make the next thing work, and make the next thing work. And that was something that I did not get until I sat down with another human being who was a programmer who was familiar with the craft.

And I remember my compiler when it failed, I had tied in this little sound, this little funny, you know, oh, [vocalization] kind of thing, and it played this long sound. And we hit compile, and it didn't work. And my computer made this big, long noise, and the guy that was sitting next to me in a blink of an eye, he figured out the only way you're playing that long of a song on a failed compile is because you're only hearing the sound twice a day because you're only compiling your code twice a day.

He heard that sound, and he's like, "Oh yeah, yeah, that's got to go." Just immediately, "That's got to go." And I'm like, "Oh, really?" And he just says, "Yeah, you need to be having failed compiles 20 times an hour." And I'm like, oooh, I mean, like, I was genuinely shocked at that, something I couldn't learn from a book. I had to learn that from another human. I mean, I could have if somebody had written down compile your code five times in a row. But I'm like, but why? I had to be next to this person to see that.

MIKE: Reminds me. My son was modding Minecraft. And he'd written a tremendously large function to do something, and he went on to say, "Can you help me with this? It's not working. It's not compiling." And I looked at it. And all the indentation was mismatched. And it was just formatting. The formatting was really bad. And usually, that sounds like a nitpicky thing, but I said, "Honestly, I can't help you with this because the formatting is so inconsistent that I can't tell what's going on just by looking at it," because he'd been writing a lot and writing inconsistently.

And I said, "Please fix the formatting. I'm not trying to be nitpicky. I'm not picking on you. I literally can't help you because I can't understand this because it is visually so distracting." So he went away for an hour or two and worked on it. And he came back to me with kind of his tail between his legs and said, "Yeah, it works now."

DAVE: [laughs] I cleaned it up, and I made it work while I was doing it.

MIKE: Just fixing the formatting made him aware that there were some mismatched curly braces somewhere. And he hadn't even deliberately fixed something. But just in the act of making it look good, the code started working. That kind of thing happens in a social environment.

DAVE: Absolutely. There's this magic aha moment as well that plays right into what we're talking about being a social activity and what you just said about cleaning up the indentation. A lot of us get the impression that source code is how you talk to a computer, and it's not. Computers don't speak source code; they speak ones and zeros. They speak binary operators. And the compiler takes your source code and turns it into these ones and zeros, which means we don't talk to computers with source code. Well, then, who are we talking to with source code? Other people.

We write our programs in a language that other people, other humans, can understand. There's an ancient quote from the early days of agile back when it was called XP before Windows XP existed and took that trademark. Martin Fowler said, "Any idiot can write code a computer can understand, but good programmers write code that other humans can understand." There's a profound epiphany that I love getting into that somebody said. When you are writing software, you are writing for other humans.

So if you write something and you start moving it around, and you line things up because it's funny to make the letters line up and da-da-da, and you make a picture in the code...and you're doodling a picture, but you're not explaining what you're trying to do with your program. You might think that's cool. You might think that's cute. Somebody comes along and goes, "I can't read this." And you suddenly realize that, or maybe you don't realize this, but hopefully, you realize that, oh, I failed at source code. The whole point of the source code was for another human to be able to read it.

Real early advice that I love to give people is that writing readable source code is a bit like being a jerk. You don't get to decide it. You're like, "Well, I'm not a jerk." No, you don't get to decide that; we're all going to decide that about you. And readable code is the same way. If you take your code and you break it up perfectly and you split the modules up, and you dry it up...DRY is don't repeat yourself.

So everything goes into one specific place, and it's all perfectly correct according to this scheme in your head that nobody else knows but you. And it's beautiful, and it's perfect. And then somebody comes along and says, "Wow, this is really hard to read." Guess what? Your code is hard to read. You don't get to decide. It might have been fun to write. It might have been satisfying to write. But it's not actually readable, and you should change it.

MIKE: And that person probably has some important lessons for you to learn. Sometimes we get caught up in some technique that we think is cool. To your point, that isn't what makes code legible or useful. A lot of times...there's some instinct that you were talking about before and learning, well, what's easy to understand? Which may be different than what's the popular technique at the moment or that you read about last week in some blog somewhere.

DAMON: It's very interesting, actually, for someone in application support trying to go over into a software developer or engineer role just to know that not everybody knows everything, even though they might think everything is all perfect. Someone can come over and just be like, "Hey, I don't really understand what you're doing here." And they can just change it and teach you something. There's always something to learn.
¬
SAM: Yeah, it sounds like being a team player greatly benefits. But my question is, are there people that prefer to work alone? And if so, does that benefit anything at all?

DAVE: I have a pretty strong opinion about this. The short answer is yes and yes. As much as I strongly agree that software is a social thing, there are times in this industry when...let me back up and let me throw one wrinkle into this, a tiny little detail that I'm keeping in my head. Telepathy doesn't work, so let me use my words here. I have said this in the past multiple times, the best programmers I've ever worked with have almost universally been people who have degrees in a science field other than computers, so like math majors, not necessarily science majors, linguists, people with degrees in biology.

And the best programmer I ever worked with had a Ph.D. in geology, and specifically, he studied earthquakes. Not surprisingly, he and I worked at a company that dealt with vibration control. We were all about analyzing shock waves, and ripples, and sine waves, and standing waves, and reflections, and that sort of thing. And he knew that stuff cold. And every once in a while...I remember there was a meeting we had where he was struggling with a problem. And he said, "Yeah, there's this ticking sound coming out of the machine because every 256 cycles, we reset this thing."

And I drew a graph on his whiteboard, and I said, "So you're saying this." And then, I drew a joint in the graph where the thing reset. He's like, "Yes, that's exactly what it's doing." And I said, "Cool. Could you make it do this?" And I redrew the graph, but I drew a smooth curve so that it wasn't resetting at the zero point. It was starting off of zero and at the slope that it came out of the previous batch. And his jaw hit his chest, and he's like, "Holy crap, that would work. Get out of my office. I need to think about something." That was literally what he told me was "Go away."

And I didn't hear from him for three days. I worked like 12 feet away, like, two doors down from him, in a tiny, little office. I didn't see him for three days. Three days later, he comes in, and he's got this yellow legal pad. And all the pages are like standing up and frayed because they've all been written on in pen, like, this whole legal pad was used, and he's waving it like a madman. And he's like, "This, this, check this out. Dave, you got to check this out, this." And I'm like, "What is this?" And he says, "This is the mathematical proof of the drawing that you drew on my whiteboard. It will work."

He had spent three days in his office in complete silence, trying to work out the mathematical proof before he committed six months of his life to writing the software. Because the thing that I had drawn was very simple to say but much harder to do, and he needed to prove that it could be done. And he needed absolute silence and unbroken concentration to get into the state of flow that he needed for that deep, deep level of work. So yes, absolutely, to your question.

There are times when software engineering is this highly...it's a very wide social subject. We want five people in the room. We want to do mob programming. We want everybody talking. We want all the ideas coming out loud of our mouths. It's a noisy room. And we all want to collectively make the best decision that we can. And that's a fun way to program, and it's great for certain types of problems.

But there are also times when yeah, I just want to sneak off to a conference room, and I want to get rid of all the external sounds because I want those parts of my brain that are listening and talking to other people I want them to spin down and release their CPU cycles to the part of my brain that solves problems so that I can get into really, really deep work. So the answer is yes, you do both. And sometimes you don't get to do the one you want to do. But sometimes you get to pick, and that's a good day when you get to do the one that you really want to do that day.

MIKE: We often organize our time so that the socializing is in a certain part of the day, and then the focus time is in another part of the day so that we have a long uninterrupted stretch to think deeply about something. Tricky problems require deep concentration. And then, once you come out of that, you might go back to the socializing part again. They're both necessary. You could have somebody who's just always doing the deep thinking and working on it. And what you'll end up with is very idiosyncratic code. You'll end up with something that really reflects that person.

And we all have our idiosyncrasies, but we're not generally looking for a piece of unusual artwork to come from our work. Again, we're here to solve problems. And, in general, you want your solution to be boring. I don't know if that sounds harsh or dull; it's not. Because a boring thing can be a thing of great beauty. You want a bridge to be something you don't think about at all and 200 years later to still be something you're not thinking about at all because it just works.

And it may have aspects of that bridge that you find quite beautiful, structural members that by their nature are just beautiful things. And software does have those things of great beauty. You don't want it to be too quirky, generally. Those quirky things might not hold up the way a very boring, predictable, hey, that just works solution would do.

DAVE: There's a fun thing...and you can do this in earlier Ruby. Something has changed. I know you can't do this in Ruby 3. I think it doesn't work in Ruby 2.7. As of 2.3 or 2.4, it still worked, as I recall. But this still works in C++ and languages that are all about bitwise stuff. But it is possible to swap two integers in three operations with no temporary variable.

If you know a little bit of programming, you know that the way you swap two numbers is you copy one to a little temporary buffer then you take the other number and put it where the first one was. Now you've lost the first number; that's why you had to put it in a temporary buffer. And then you put the temporary number into the other number's place, and you've now swapped their place. You can take A XOR equals B XOR equals A XOR equals B, and that will swap A and B in place.

If you go learn the rules for how XOR works, about how like if one bit is set, the other one is off, then it turns the bit on. If both bits are on or both bits are off, it turns the bit off. There's this whole algebra for how XOR works that you end up with one number holding itself plus the inverse shadow XOR of the other number, and you can get it back. And it works. It works. And it's super clever. And I carried it around for years, and years, and years, and years. And I would use that.

Anytime I wrote the swap function, I would use this method because it would make people think I was so clever. And I liked getting patted on the head and told that I was such a brilliant boy. And then somebody who really knew how XOR worked...and I had worked it out, like, I could explain to you how this algorithm works. Of course, if I'm going to be clever, I want to prove that I'm clever.

And just a very senior hacker walked in, and he said, "What happens if you tried to swap a number with itself?" And if you XOR any number with itself, it shorts out. You get zero, all zeros, and the number is lost. So if you try to swap a number with itself, it sets it to zero, and my algorithm is now stupid. And the whole point of doing this swap thing is so that you can only do it in three operations, so you don't have to...well, now I have to do an if test to see if they're the same number.

And if you try to swap two different copies of the same number, it will work. It's when you try to swap a number with like you say, swap X with X, and they're pointing at the same location in memory, then what you were using for storage was the sideband XOR data in the number itself. You lose that, and it zeros out. And that was the day that I really finally learned that don't do clever stuff in production; do the boring thing. It wasn't 1988. We weren't paying $20 for that extra byte of RAM to put the number in that we were swapping. We could afford it. And that's even more true today. Well, it isn't.

Everything old is new again because as soon as you say, oh, every computer has four gigabytes of clock or gigahertz of clock and 32 gigs of RAM, as soon as you say that, somebody will come along and say, "Hey, can you help me with this Arduino project?" Five years ago, ten years ago, Arduinos didn't have very much RAM on them. PIC chips back then you could get in...15 years ago, you could buy them with 64 bytes of RAM on them. And so we had to pull out the old books from the 1970s of how do I make this run on a program with no memory or on hardware with no memory? And that's coming around now.

Like, the big push in Ruby is to make mruby work, which is mobile Ruby, and they're trying to make it so that it will fit in an Arduino or on a Raspberry Pi. And the full Ruby will fit on a full-sized Raspberry Pi. But if you've looked at the latest round of Raspberry Pis, it's a four-gigahertz machine with gigabytes of RAM. It's a full computer now. The Ruby didn't shrink down to meet it. The computer swelled up to be able to lift it. The point is, don't be clever. [laughs]

If you're going to make a trade-off, ooh, I just realized there's a better way to phrase this trade-off that everything is a trade-off. Never ever trade off something in exchange...never trade off something good...never give away something good in your code in exchange for getting to think you're clever or getting to show people that you're clever. Because they're going to come along, and they're going to see your code, and they're going to say, "How much did we pay for you to show me this? Because that holds no value to me."

So I've got a question for Damon and Sam. So you guys are working in a software development adjacent field which, by the way, is a fantastic career path. There's a great book by Cal Newport called So Good They Can't Ignore You. And he basically tells people, if you want to go somewhere and you can't get there, like, you know, it's the age-old thing, right? How do you get five years of experience at a job where every job requires five years of experience? And how do you break into that? And the short answer is you get a job adjacent to the job you want. You go into customer support. A lot of people got into programming through customer support.

I went in and worked at a QA department. And I worked there for one week, and I submitted a bug report where I told the person that wrote the thing, "Looking at your Windows program, I strongly suspect you're using the Borland C++ compiler because..." I didn't say why. But basically, there was a tiny little graphical flourish on every Windows window that was a little bit different than the standard Windows thing. And that meant that it was this brand of compiler. And I used that compiler, which is why I recognized that flourish. And there's a really common bug because there was a default setting on the compiler that was dumb.

And so when I submitted the report, I was able to say the software is doing this. "At a guess, I'm guessing you're using the Borland C++ compiler. Go into your settings and change this, and that will fix the problem." And I got a phone call the next day saying, "Why don't you come over and talk to the programming department?" Literally, whoever that report got to, they were like, "Yes, I am using Borland. And holy crap, I do have that setting set." How did he know this? Bring him in here. I want to talk to him. So you work on your chops, work on your development, and then go into something adjacent.

I just screwed up because I was going to ask you a question then I ended up starting telling a story again; I apologize. [laughter] I'll try to do better. My question for you two, and then I'm going to shut up and actually listen and let you answer, is, from where you sit, what does a software development career look like? And that might be from here to starting at your software development; what does that look like?

How are you getting ready for this? Are you getting ready for this? Is this something you want to dip a toe in? Or are you locked in and like, no, this is my life, you know, this is my destiny; I'm going to get there? How are you guys looking at software development from where you're at?

DAMON: I'm ready to just dive into it. It's been something that I've been interested in, but I never took the initiative to learn until...I didn't feel like I was ever going to be capable of doing it, honestly just because it looks a little bit more challenging than maybe it actually is. I don't know; my brain works kind of weird. But, like you were just saying, I was in basically a customer service role. I was in processing for, I'm going to say like, five months, maybe.

And then I decided I didn't want to be in processing anymore because I had a little bit more to offer, not really sure what it was. But I applied for the operations role, and I got hired basically after a week and a half of interviews and stuff like that. I worked in ops for one day, and basically, they were like, "Hey, we looked at your resume. And talking to you, we feel like you're going to be really bored here." I think this was when Ryan, before he left and then he came and got me with Alicia, and they were like, "Hey, we have better opportunities for you."

With that being said, it looks promising for me. I just feel like it's something that I've always wanted to do. But like I said, I just never had the opportunity, the chance, never been given a shot until now.

MIKE: Imposter Syndrome biting you. It's a plague.

DAVE: And it never goes away. It never goes away. I blew an estimate...Mike can confirm this. We had an integration where there was a wrinkle to it. It was a two-week integration. And I estimated, oh yeah, this will take about two weeks. And then they said, "Oh, but you can only test it in production." And I'm like, "Oh, okay, make it four weeks." It took me what? Seven months, six months? I'm terrified to count up the actual total. And that was this year.

I started this last fall and finished in March. Like last month, we put the final bow on this. And I was hanging my head thinking, man, they're going to fire me because I do not know how to program. And that impostor syndrome will haunt you. It never...well, hang on. Let me rephrase. It will try to haunt you for your entire career, and it will sell you a lie. And here's the lie; keep quiet, keep your head down. Don't try for the opportunity right now. Just go learn something more, and eventually, you'll be good enough to get it. That is a lie. You will feel like that your whole life.

I feel like that today. I came out of blowing that estimate thinking, oh my gosh, I'm a terrible programmer. I'm never going to be a good developer. And meanwhile, I'm jumping into skills clinic with new people and mentoring and teaching, and everyone's telling me, "This is great. This is a lot of fun. I love working with you." And I'm like, yeah, but I'm so bad at estimates. I had no idea this was going to bite us in the butt this hard.

Ironically, once we sat down with the customer and said, "This is not going to work; you have to make this work for us," we finished up in about three more weeks. So, you know, we got that thing fixed. By the way, that's literally my imposter syndrome saying I need to speak in my defense here. I'm blowing that estimate because I feel so guilty about it. And that will haunt you. So get comfortable now with reaching for the golden ring when you have the chance for it.

The best use of surplus privilege is finding invisible doors and opening them for other people. But never ever forget that the use of your existing amount of privilege is if you see the golden ring, reach for it. If you see a whole bunch of golden rings around the carousel, get on the carousel. If they'll let you on, get on. Because you're going to tell yourself, oh, I don't deserve to be. And there'll be gatekeepers who will say, "You don't deserve." And if you can sneak onto the carousel, do it. And if you can grab for that ring, grab for it.

And there will be times when you're going to be like, oh man, I got this great opportunity, and I so do not deserve this. I better grow up fast if I'm going to fill these boots. And it will make for very, very happy memories when you look back and realize I did fill those boots. It turns out this entire time, I absolutely was good enough to get on that carousel and grab that ring. Never negotiate against yourself. I guess that's the summary on that.

MIKE: Well put. Sam, how do you see software development?

SAM: Well, I'm pretty much in the same boat as Damon. I was pretty much in a customer service role for about three years, and I told myself that I wanted to do something else. I actually told myself two years into the company working customer support was just hard; I think what you guys were saying imposter syndrome. And then, finally, I just reached a point where like, I got to do this. I got to get out of my comfort zone. So I ended up taking up a position with operations. I did that for about seven months.

And then, like Damon, I was approached by Alicia. And they said, "Hey, we think you'd be a good role for this position in application support." So I decided to take it. And right when I got into this role, this is where I was opened to seeing operations on a different...and engineering, I haven't really looked a lot into it, but yeah, I would definitely want to learn more about it.

MIKE: I'm going to agree with Dave here that, you know, take the opportunity. If you got that opportunity, take advantage of it. And to those of you who are listening, there are a lot of opportunities in software development. And it may be that you keep running into walls, and you feel like, man, I can't do this. And I think Dave gave fantastic advice. Get close to it. Get close to that role and keep doing work and take every opportunity that you can to do some of that software development work.

And this applies outside of software development too. If you want to be an astronomer, go get a janitorial job at the observatory, [laughs] whatever it is, get close to it. And there will be opportunities. And if you keep working at it, you'll get better. And you'll be surprised at how much everybody else around you is just figuring out as they go too.

DAMON: Yeah, that's awesome. Thanks, guys.

MIKE: We've talked a lot about what software development is actually made of and what skills are involved, and the importance of recognizing our fallibility that we all have, allowing us to grow and change. I think we hit on some really great points. We're reaching the end of the time that I think we had scheduled for this. So I'm going to ask, are there any final thoughts, things that have been on your mind you just want to say as we've been talking?

SAM: No. I think I came here just expecting to listen, and I've learned a lot here. So, yeah, thank you for having me. This is definitely empowering.

DAMON: I think for me, personally, this was a really good one because we do plan on transitioning here into an engineering role soon. So I was like, oh, this is perfect. I need to listen here to learn about the struggles that you might go through or you will go through and how to go about those. And teamwork is very essential. This was helpful.

DAVE: Sam and Damon, Acima is the best company I've ever worked at for having a pipeline and an investment in new programmers and turning them into experienced programmers. Hang out, come join a podcast, get close to the programming. That actually was a genius move you guys pulled here today. You absolutely have every right to be here. You're not imposters on the show today.

Also, come hit up the Atlas team, where we're working on the website that the merchants log into. There are people on that team that will say, "Oh, you've got an hour free? Come sit with me, and we'll write some code together." And you'll probably just watch and learn for most of the time.

There are skill clinics. And this is less valuable for people listening to the podcast, except I want other companies and the people at other companies to know that this exists, and you can do this at your shop as well. Put on a skills clinic every day if you can afford to, and if you can't afford it, make the affordance for it. And have tickets in your backlog that are marked as starter that you can have...we cut this food up nice and tiny so that somebody with a small appetite can tuck into it and close it out safely without having to touch the guts of the whole machine. So yeah, get close to it.

Sam and Damon, the next steps for you go find developers on other teams and say, "Hey, can I come sit with you and learn and just watch you type and point out your typos?" And that's a much more valuable pair programming offer than you think it might be. It's not a complete one-way street; it is you actually providing value. Yeah, find the value you can provide and provide it, and that will be your next step forward.

MIKE: I would add on to what you're saying there, Dave, to those people at companies that could be doing this that just say, "Well, we can't afford this. We can't afford to invest in the growth of our employees." I would flip that. I would say you can't afford not to. There is so much --

DAVE: What's the saying? What if we train them and they leave? And then the counterargument is, what if we don't train them and they stay?

MIKE: It's wildly expensive to be in that situation, so is not training them, and they leave. There's no good scenario where you don't help people out that just stays that way because, really, it's not going to stay that way. You're not going to have the culture, and the end product, the software that you really want unless you've built an environment that is conducive to building good software. The cost is going to be paid whether or not you see it.

If you have under-experienced developers who have not had a lot of opportunity to grow their skills, then you're paying the cost of that software that isn't what it could be and paying the tremendous cost of losing good people. Take the time. And if you're out there, take the opportunities that are there. Make them at your company. It can make a tremendous difference, not just to you personally but to the organization you're working.

Thank you, everybody. This was a great session. I look forward to talking to you next time.