55. How to Become a Great Software Developer (Part 1)

Rich: In Episode 55 of Mobycast, we start a new miniseries on how to become a great software developer. Welcome to Mobycast, a weekly conversation about cloud-native development, AWS, and building distributed systems. Let’s jump right in.

Jon: Welcome, Chris and Rich. It’s another episode of Mobycast.

Chris: Hey.

Rich: Hey guys. Good to be back.

Jon: Let’s just find out what we’ve been up to. Rich, what have you been up to this past week?

Rich: Last week I was at a conference called MicroConf in Las Vegas. It’s a smaller software-focused conference that follows bootstrappers and self-funded solopreneurs. It’s a pretty cool yearly event that I’ve been going to for probably three or four years.

Jon: The conference was in Vegas?

Rich: It was in Vegas, yeah.

Jon: Where did you stay?

Rich: At the Tropicana where the event was.

Jon: Cool. I might stay there.

Rich: There’s nothing special about it, but it’s cheap.

Jon: There you go. That’s what you went, for a bootstrapper’s conference, right?

Rich: That’s right, yup.

Jon: Chris, how about you? What have you been up to or what are you about to be up to?

Chris: I’m busy preparing for a spring break with my family. We’re heading off the continent going to Italy and visiting Venice and Rome. I’m super excited for that. Although, it feels like I just got done with 32 hours each way going back and forth to Brazil. At least this time, it’s only about 16–18 hours each way.

Jon: So much further and you’re well-practiced, so no problem.

Chris: The time zone changes going to be a killer. Nine hours difference.

Jon: I’ll just go the whole week feeling so bad for you and how tired you must be.

Chris: As I stuffed my face with a lot of espresso.

Jon: All right. Now, I want to apologize to some people that are excited for another episode in our networking series. Networking is something that we always need to brush up on ourselves in order to be able to talk well about it and in thinking about brushing up, we thought, “You know? Actually, this relates to just the topic of staying up-to-date and being a great software developer.”

Let’s take just a little break from networking—we will get back to it—and just talk about what are some things that we can do to be great software developers. To go from somebody who can code to somebody who is just super great at coding, somebody who upon a team is just indispensable. That’s was the word I was looking for is indispensable. So, here’s seven things to become a great software developer. Chris, can you take us off?

Chris: Sure. I’m kind of the motivation for talking about this. This is a very real world topic for us at Kelsus and actually just about every company I’ve been at. We’ve talked about how technology is changing so rapidly, so much innovation is happening, big shifts in just how a software is built and the text […] go along with them.

Software developers have to continually learn, involve, and improve. In order to make those kinds of transitions and to improve, you do really need to have some core foundational baseline skills and just hard-fought knowledge. This is something we think about a lot with our team.

We’ve put together a plan and do a lot of things to help foster that kind of development. We’ve done things like instituted one-on-one meetings where we set up individual plans for each one of our developers, on the kinds of goals that they want to obtain, what they need to work on, and help them achieve those goals. We have monthly engineering team sessions where we all get together as a team and spend some time just to talk for some degree, dig important issues related to engineering, processes, and whatnot. We have online training available to our team. We do prioritize code reviews quite a bit as a way of fostering learning and improvement. Then we do things like the offsite retreats like we just recently had, where we were in Brazil for a week.

Maybe to some people’s chagrin, we actually spent most of the time doing serious engineering, learning, professional development, and less time on the beach. We didn’t very much prioritize it.

Jon: Yeah. It’s so hard to be looking at the beautiful ocean while you’re in there reading man pages, trying to get better at Bash skills.

Chris: Yup, indeed, but it’s important. This is just the landscape. It’s critical in order to be successful in software development.

Jon: I just want to reiterate those things because you just listed off a few things that I think are great. We’re doing this from a management leadership perspective, so I’ll list off the five things and then flip them around to think about it from a personal perspective.

The five things are the one-on-one meetings. If your company is not providing those for you, then maybe just flip it around and think of, “Who’s somebody who I look up to? Who is the software developer that could mentor me?” That’s essentially what that’s about is getting that regular mentorship. Hopefully, your company is providing that for you, but if they’re not, it’s really on yourself to find that.

The next one, monthly engineering team sessions. That really is more of a company thing and different companies might do that different ways. But if your company is big enough so that not everybody can talk to each other everyday about whatever small project you’re working on, then there’s got to be some cross-pollination. Again, you can do that. If your company is not doing that for you and you see that there needs to be more cross-pollination, she will rise in the ranks if you point that out, suggest it, and organize it for your company. Absolutely.

Offsite retreats, that’s really a Kelsus thing but I think that the equivalent would be going to conferences, wouldn’t you say, Chris? In the US, going to conferences is kind of the equivalent of what we’re trying to pull off at Kelsus camp. It’s just that, the conferences available in South America are just not at the right level for our team and not presenting the right types of things. We are essentially bringing the conference to them. Wouldn’t you say that’s kind of what’s happening?

Chris: Absolutely. It’s not nearly as cost-effective to send folks to conferences when you have such a big team. But yeah, conferences are great. They are spendy but pick your conferences right and you can get a wealth of learning and improvement. We’d be talking about in the past, things like re:Invent, that’s a must-do if you’re in the world of cloud and DockerCon as well, which I’ll be going to here in a couple of weeks and likely to be my fourth in a row that I’ve gone to. Although, as we’ve mentioned in the past, I’m less bullish on DockerCon.

There’s a lot of great conferences out there with just tons of really in-depth type of a content. It can be a really great way for you to just get away from the office and focus on learning and improvement.

Jon: Right and then the last two were online training and code review. Online training is the one thing that everybody gets their head around. You watch videos, you read blog posts, everybody knows to do that and they do it. Whether they’re learning the right things or not, it really makes the difference.

Code reviews, we just can’t say enough good things about taking code reviews seriously. “Looks good, commit it,” is not worth anybody’s time, so doing code reviews with thoughtfulness and wanting to help other people, actually putting a little bit of heart in the code reviews is just so killer for getting better at software development and helping your team grow.

And all of those five things, the interesting thing about them is that—it’s about what we’re about to talk about—for me, you can push all these five things on people and have it be absolutely worthless. These five things are great if people internalize them, if they really want to get better and have that internal desire, intrinsic motivation is the word I was looking for. To do these five things and learn, that’s when they work. If you’re just pushing it on people, you might as well not because it’s not going to help.

Chris: Yeah and maybe just to make that even more explicit is that, at the end of the day, you the individual are responsible for that, no one else. You needed to be the one on the driver’s seat. You need to decided that’s the part that you’re going to make it happen. It’s not someone else’s job to do that. Your company can provide resources, opportunities, and whatnot, but at the end of the day, this is your job. This is your priority and you need to own it.

Jon: Right. I’m a little lazy. I do love it when I can just go someplace, sit back, and absorb the learning. So nice.

Chris: You still have to do the work. Figuring out what you need, otherwise, it’s not like you can just sit back, open up your brain, and now they just spoon in. It doesn’t work that way.

Jon: Right on. I think that leads into our next point quite a bit. Go ahead, Chris, what is our next point?

Chris: I spent some time just thinking about what are some of the traits that make really great software developers? What are some of the core foundational skills that they need to stay relevant and keep up with the pace of innovation? I think the rest of us will go through this. I came up with seven principles that, at least for me, have been very important and foundational during my career. I think it’s a good start, it’ a good springboard to have that discussion and see what other people’s thoughts are a well, but maybe they’ll dive into it.

The first principle is just practice. Practice, practice, practice. The only way to really get great at software development is by writing code and writing lots of it. There’s no substitute for that. You can go and take classes, you can get books, you can go to university, you can get certified, but not of that is going to make you a great software developer. The only thing that’s really going to make that happen is if you’re actually writing the code. Your hands are on the keyboard and you’re just writing that code.

It’s really important, too, don’t copy-paste. I do see a lot of that. It’s really an easy thing to do. You can go google what it is that you’re working on, go find some sample codes somewhere, just copy-paste it, and then you just do some scaffolding around it. It may end up you have something usable that works but how much of it did you really do? You’re really relying on the patterns of others, similar or what not. Programming, software development is really problem-solving. The more you just do it yourself and write that code, the better off you’re going to be.

Jon: I think that’s really important. It’s such a weird hard balance because software development has progressed so far so rapidly because we can rely on each other’s work. We talked about that many times in terms of open source and using libraries and stuff. Without that stuff, if we were writing everything from scratch all the time, we wouldn’t be where we are today where we can just spin up a framework and get amazing things done really quickly.

But at the same time, this last five or eight years or so, that’s turned out a lot of copy-paste development and developers, is not great for the future of software development. We really need people that understand what they’re doing and have code ready at hand, that able to produce code without Google is a critical skill.

A lot of innovation comes from mastering that skill and then using Google. Learn how to write that code by writing that code and practicing it. Then, look at how other people are doing things, read other people’s code for sure. Don’t solve every problem by copy-pasting other people’s code. You’re not going to learn as much. You will learn, obviously, but more slowly and you’ll see the people that are doing the hard yards, that are learning by doing, accelerate at their skills level much more quickly than yours. I think that maybe is the core thing. Sure you’ll learn but so much, much slowly than you would if you’re practicing, if you’re really doing it.

Chris: I think you hit a really important point there. There’s a time and place for having that approach of when you copy-paste or when you leverage the work of others. If you just start off your career and that’s the only style of developing you do, then you’re doing yourself a big disservice. But once you build that foundation, once you really have them, the hard work, the heavy lifting, and you have written a lot of code, then you can start being a little bit more flexible. You can make those trade-offs. You’ll have a much better idea of when it makes sense for you to go and leverage something that someone else has done versus doing it yourself. There’s a time and place for it but don’t do it early on.

Jon: There’s something that’s not in our outline but it’s something that I always think about, when I think about what are the mental skills that you need to be a good software developer. I think this one is something that comes from practice, so it fits in with this bullet point. One of the skills I think that people need to develop is the ability to hold many different possibilities in their mind at once without needing to have them laid out explicitly in front of them or without having to try them one at a time with the computer. It’s sort of the difference between writing one line of code, compile it, run it, and see if it works. Write another line of code, compile it, run it, and see if it works, versus being able to think through a whole design and maybe even writing a whole function and then seeing if that works as opposed to just one little thing at a time.

In order to do that, you have to have lots of stuff in your mind at once. You have to think, “Well, this is going to happen and that’s going to happen. If I do this, then that will happen, and I’ve got to have an expression that I’m going to match with these inputs.” All these things are in your mind and you imagine them. I don’t know how to describe this but you can imagine it and see it all in your head all at once. That is a skill that people can learn.

The more practice you have at software development, I think in a sense the more of that you can hold in your mind at once. As soon as you start to feel like you can hear a problem and then imagine the code behind it fairly easily, that’s maybe when you’re like, “Okay, I’m starting to get this. I’m starting to develop some mastery.” I don’t know. Maybe that’s too abstract. What do you think, Chris? Is that a reasonable explanation?

Chris: Yeah. Like I said, it goes back to the core of software development. You are problem-solving. You’re thinking basically everything is an algorithm. You’re breaking it down from a logical standpoint of what’s the problem and what’s my solution to it. That whole thought process is complicated. You can’t think of it as just one line of code at a time. It really is like what is the algorithm?

You have to be thinking of various ways of doing it. It can’t just be the first thing that come to mind. That may not be the best. It probably isn’t. The more you practice, too, the more you’re exposed to those kinds of situations. Actually probably the set of possibilities grows with the more practice you have and it makes you even better.

Absolutely being able to juggle all those abstract concepts, to be thinking algorithmically, to be thinking analytically, to breaking problems down into steps, these are all core key to software development.

Jon: I want to push on this just a little bit more because I want to see if you relate to this. I’ve never asked anybody this before. When I’m starting to write, say, a new function or a new class or something, sometimes my mind will fill over full of stuff, all this stuff that’s going on in my head that I want to get out. It’s all organized in my head and it’s clear what I want to do but it’s like over full. There’s so much in there that it’s almost like a bad feeling. Then, as I get the code out onto the screen, that bad feeling starts to go away and turns into a good feeling. I was like, “Ah, yes.” I’m no so overfull in my mind of things that I had, all this logic that I was trying to keep all in my head all at once, and now it’s on the screen, I feel better. Can you relate to that at all, Chris?

Chris: Sounds like a brain explosion.

Jon: Yeah, a little bit like that.

Chris: I think everyone’s different. For me, I don’t think my experiences been so much like that. I don’t know. It’s weird. I think I’ve been doing it for so long and I’ve done it so many times. I feel more like a divide and conquer. I see the first thing with a big picture, then I start breaking it down into systems, components, modules, and just go from there, start building up the scaffolding, if you will.

Maybe it’s a different approach. If it’s something really hairy like a really complicated algorithm or problem, then that’s when I may start sketching stuff out and putting something down physically on paper that let me think it through.

Jon: Interesting. All right. That’s practice, practice, practice. What’s next?

Chris: The next one I think is really important for software developers is persistence. You’ll never have mastery over software development if you don’t have that persistence. Software development is hard. You will struggle. There’s been so many times where I will be staring at a piece of code, just not understanding why it works. There’s just no substitute for just sticking with it.

Persisting through that is painful, it’s suffering, but you just have to do it. It’s just part of that process. That’s the journey that produces the insights. It’s the mental exercise that builds that muscle that just lays more foundation for going forward in the future.

If you never have anything that is challenging to you in software development, if you never have a need to persist and you’re either just absolutely a genius or you’re definitely not being challenged, it may just be that something’s wrong or you’re doing it wrong. It should be difficult. It’s a very mentally intense exercise for programming.

Jon: Just to point out that it may not seem like there’s much of a difference between persistence and practice, practice, practice, but the real difference is that the persistence isn’t the practice part. It’s the part where when the going gets tough, you keep pushing no so much the quantity but the not letting go.

I just want to say that, what you say is persistence, I think what it leads to is the development of confidence. I think that that’s one of the hallmarks of somebody who’s likely to be a good developer. Just a confidence that they can solve whatever problem comes their way because they persisted through so many before. This is just yet another one. This is one that’s solvable, too.

Of course, there are some things that are not possible with today’s technology but somebody that’s persisted through a lot of difficult problems won’t know the difference. “That one, we can figure this out. Just give me another few days,” kind of thing, “and we’ll solve it. We’ll get there.”

I feel that’s relevant to Kelsus, too, because I find myself telling clients, like, “Yeah, you ever going to fix that bug or produce […]? This is taking a lot of time.” “No, we will. We’ve got this. It’s just one of those hairy software problems that take a few days. Just give us a little breathing room and we’ll figure it out.”

Chris: A common indication of this is how many times where you know people, or maybe even trust personally, you’ve started the project, and then once something got difficult or just too challenging, just give it up. So, how many have started projects are out there and they’re much more common than they should be?

As you point out, quality definitely trumps quantity here. Finishing matters so that when the going gets tough, just doubling down, having that confidence in yourself, there’s a solution. You just haven’t found it yet. You just need to stick with it and do it. Having that persistence is so key, so critical.

Again, anyone can do the copy-paste stuff. If their problems have already been solved and they’re out there on the internet, you can go copy-paste. Anyone can do that. What distinguishes you from any other developer out there, the really great ones are the ones that can deal with more novel problems or the more impromptu problems. You can’t go your way out of it and it’s not going to be intuitive or easy to do. It’s going to require the persistence. It’s going to be painful and hard. But just have the confidence in yourself, like, “I can do this.” Life’s […].

Jon: I’m laughing because I saw a tweet the other day that said something like, “Oh, I ran into a software problem and I couldn’t solve it,” on Stack Overflow, “and I just persisted and finally found it on the second page of Google.” That one’s like, “What? There’s a second page?”

Chris: I’m laughing but that makes me sad.

Jon: Right. What’s after persistence? Number three?

Chris: Thinking this through, the third thing that really came top of mind is this concept of placing value and understanding above correctness. This is definitely in line with some of the things we’ve already talked about, but it’s very common, especially today in things like Agile processes and having the work items that are assigned to you and having cards or what not to work on, you just want to get things done. Just, “Here’s my task items. Here’s what I’m supposed to do this week or whatever. Just get it done.”

There can be a tendency to really prioritize that, of just getting something to work, and I think you’re doing yourself a big disservice there when you don’t understand fully why it works. Don’t let anything about your software be a mystery. You really should understand what every line of your code is doing. This is incredibly true for when you do look at other code from other people, borrow it, copy-paste or what not.

Don’t ever copy-paste any piece of code into your code base unless you understand exactly what it’s doing. If you don’t understand that, you’re taking on a big risk and it’s potentially going to cause you a lot of problems down the road. Not only that, you’re missing a huge opportunity for learning and insight. I think that’s really important.

Related to this would be when you are dealing with a problem in your software, like you have some gnarly bug that you’re dealing with. It could be a timing issue, or a memory issue or what not. You just start randomly changing things because you’re not sure exactly what’s going on. You just understand the symptoms but you really don’t know what the cause is. So you start changing things and maybe it just goes away. Then you’re like, “Whew. All right. Done.” Don’t do that.

You’re really, again, doing yourself a disservice because this is a huge opportunity for some deep insight and understanding. It probably means you’re going to be learning something really core that you just didn’t understand before. It could be something like really understanding how an operating system does threading or it could be like how does node garbage collector work. It could be really, what does it mean to have synchronization in code with semaphores or something like that.

Just really persisting to understand what the cause was, why it’s happening, and why the […] works is really important. Again, this is, give me those core foundational insights that becoming just investments in you. It’s taking you to the next level each time you do that, as opposed to just letting the mystery remain. You’re missing valuable opportunities there to fill in those holes, to increase your understanding and your comprehension that are just going to pay off immensely in the future. So, definitely just value understanding above just getting stuff done. I think you’re going to be a much, much better developer that way.

Jon: We were talking about this a little bit last week while in Brazil. I think the thing that’s hard to do is know when to dig deep and know when to just stay at the surface. If you say, “Well, always dig deep,” you just always have to dig deep, then you just paralyzed a new developer. They cannot get anything done because they don’t know anything.

“Go learn the Express framework,” and it’s like, “Okay. Oh my God. There’s so much code here. Now I have to go learn how Node works […],” and, “Oh my God. Now I have to learn Javascript grammar,” and then, “Now I have to understand what Unix is doing.” That’s just too much. You can’t even do anything. People come out of code school, they come out of universities, and they don’t know these frameworks, but they’re expected to produce code in those frameworks.

I think what you’re getting at is, maybe you don’t know every detailed thing about everything you’re doing right now, but look for opportunities to dig deep. You’re writing some code that has a problem. Instead of just looking for the code solution to the problem, really take that opportunity to find out what’s really causing the problem. Look for those opportunities because taking that extra 15–20 minutes to read something, that’s not going to really slow you down or make you look bad on your Trello burndown rate kind of stuff. It will pay those dividends.

I think that’s where you’re getting at, right Chris? It’s looking for those opportunities and not just stop all the coding until you understand everything?

Chris: Yeah. You don’t have to boil the ocean and understand every single line of code that you’re pulling in from every framework that you’re using, but I do think that whenever you’re working on something and you run into a bug, or a problem, or you’re just not understanding how it works, don’t just do the easy way out. Don’t copy-paste your way to those solutions. Don’t just—

Jon: Changing code randomly.

Chris: Yeah, don’t spray and pray. Understand what it is. It may end up taking you six hours to finish that instead of one, but those five extra hours are going to be just a really great investment in the future. As you progress, as you do this more often, that’s going to flip that ratio. It’s not going to be as common anymore because you’ve already made those investments, you have improved, and you’re getting better each time.

Just that one thing, whenever there’s mystery in the code that you’re writing that you just don’t understand what’s going on, understand it. Chase it down. If you have to go have someone else to help you out, do that, but understand why.

Jon: Cool. So, that was number three. Rich, has this been at all helpful for you?

Rich: Yeah, definitely.

Jon: Nice. I don’t know. Because you’re a self-taught developer, have you found that this is what you do, these first three things of practice, persistence, and valuing understanding above correctness? Has that been your approach at all?

Rich: Yeah. I think my biggest problem Chris had mentioned pretty early on is all the training in the world, all of the Udemy or Lynda courses you take, they’re not really valuable until you start writing code. I found myself early on falling into where I tried watching the entire series without writing code, with the intention of jumping back afterwards and starting over again but that rarely happens.

My biggest thing these days, especially for our team, is just don’t lay on the couch and watch these things. Watch them at your desk with a code editor open because you’ll forget just about everything the moment you put on Netflix.

That’s when I had to teach myself and something that we definitely try to promote internally at Secret Stache. It’s not yet all of that but the persistence is like anything else. This isn’t easy and persistence is ultimately what wins out with things that are hard. Just doing what the others are not willing to do and most of the time that’s just really outlasting.

Jon: Cool. We have four more to go but we want to respect your times. We’ll get back to it next week on Mobycast. Thanks for joining, Chris and Rich.

Chris: Thanks guys. See you next week.

Rich: See you.

Well dear listener, you made it to the end. We appreciate your time and invite you to continue the conversation with us online. This episode, along with show notes and other valuable resources is available at mobycast.fm/55. If you have any questions or additional insights, we encourage you to leave us a comment there. Thank you and we’ll see you again next week.