[00:00:00] SY: Okay, so we are all sold out of earlybird tickets to Codeland. But regular tickets are now available. They start at 99 bucks, and they get you talks, a workshop, great food, great people, all in New York City on July 22nd. Go to codelandconf.com for more info. Link is in your show notes.

[00:00:29] (Music) Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host, Saron, and today, we’re talking about going from junior developer to just developer.

[00:00:44] (Music) In 2012, Ben started Upcase.

[00:00:47] BO: My name is Ben Ornstein.

[00:00:48] SY: And the tagline of this learning platform is “take the junior out of your title.”

[00:00:54] BO: It’s very much dedicated to leveling up especially junior developers.

[00:00:57] SY: There are tons of learning resources out there for new developers. But what happens when you’ve been on the job for a year or two and you want to get better? How do you level up? Sometimes leveling up is about getting better at the thing you’re already doing. Other times it’s about learning a new concept or a new framework altogether, and still other times it’s not about the code itself, it’s the stuff around the code. What’s your tool set look like? How do you pair program with other developers? How do you do a code review? We talk to Ben about how to go from junior developer to intermediate developer and how he built the product to help you get there, after this.

[00:01:39] As you know, I’m a podcaster, and I love talking to people and hearing their stories, and I love it so much I actually host another podcast called Command Line Heroes. It’s produced by Red Hat. And in that show, I get to talk to tons of people doing incredible work in open source. But besides awesome interviews, it’s also got sound effects, background music, you know, creative audio stuff. So if you’re looking for some more awesome tech podcasts to fill your feed, check out Command Line Heroes. Go to redhat.com/commandlineheroes. Link is in your show notes.

[00:02:16] If you’ve got a personal project, a small business, or a big business with lots of data, Linode offers you secure hosting for all your infrastructure needs. They are a Linux Cloud Hosting provider where you can get a new server up and running in under a minute. Plans start at one gigabytes of RAM for just five bucks a month. And with the promo code CodeNewbie2019, you can get a $20 credit. So go to linode.com/codenewbie and give it a try. Also, they’re hiring. Check out their jobs at linode.com/careers. Links are in your show notes.

[00:02:50] SY: If you’re listening to this, you’re already on your way to changing your life through code. At Flatiron School, you might end up with a job, a promotion or a better salary. But that’s just the start of changing your career, your life, and the world. On campus or online, you’ll join a community of learners that are empowered to change their future in the rapidly growing tech field. A bold change begins with a single step. To take yours, go to flatironschool.com/codenewbie. Link is in your show notes.

[00:03:24] DigitalOcean provides the easiest cloud platform to deploy, manage, and scale applications of any size. They remove infrastructure friction and provide predictability so you can spend more time building what you love. Try DigitalOcean for free by going to DO.co/codenewbie and get $100 in infrastructure credit. Link is in your show notes.

[00:03:49] SY: So Upcase started in 2012. And what exactly is it? What is it look like? If I go to Upcase, what do I see?

[00:03:56] BO: You see quite a collection of content now. It’s a lot of video courses, I would say, is the bulk of it and it’s got a bit of a Rails flavor to it because thoughtbot was predominantly, at least in the past, a Rails consultancy, but it goes beyond just learning to use Rails well and covers topics that are of more general interest to developers like test-driven development or using your shell really well or your editor well or Git well.

[00:04:20] SY: So with this video content, especially in 2012, I feel like there’s a lot of content nowadays, you know, if I want to learn to code, I’m overwhelmed by all the resources and options. What did the landscape for learning this stuff look like in 2012?

[00:04:37] BO: So it wasn’t as saturated as it is now, but I would actually say that today’s landscape is similar to what existed back then in one important way, which is there is a huge amount of beginner content. People are making way more things for new people than like late intermediate people. There’s a huge market of people who want to get into programming. So if you want to make an educational site, you have this steady stream of people that are trying to get into it. But once those people have graduated boot camp or been on the job for a year or so, the amount of content really thins out and that was where we had so much knowledge to share because we have been doing this stuff every day in the real world. And so we had a lot of like real world lessons there and it was also the least crowded area. And so we from the very beginning decided the Upcase would sort of not be super targeted at new people, it’s not new like unfriendly to new people, but it kind of comes in when you’re a little bit further along in your journey.

[00:05:36] SY: So what are some big differences between newbie content and intermediate content?

[00:05:42] BO: When you’re a new person, you’re trying to get your feet underneath you. It’s often really useful as a teaching technique, I think, to give newer people simpler rules or sometimes simplified explanations of things where it’s like I’m intentionally kind of leaving out a little bit of the subtlety here or the complexity, and it’s fine for now, but I’m doing this to sort of prevent overwhelm in the beginning. And then later on when you have your feet underneath you and you’re feeling a little bit less overwhelmed, it’s like, “Okay, now you’re ready to hear the full story on this thing and understand the trade-offs and the complexity there.”

[00:06:15] SY: I really like that because it also made me realize why I get so frustrated with new newbie content because sometimes I can tell that it’s oversimplified, right? I’m like, “That’s not really the way that I would see that,” especially… and I feel this pain right now because I’m trying to invest more in my front end skills and I’m looking for more examples specifically in how to use CSS in a real project. And when I look up, you know best practices for CSS just in general I get a lot of newbie stuff and I get a lot of beginners stuff, but I know there’s not going to be just one CSS file. It’s not even going to be a CSS file, it’s going to be SAS file, you know, like there are so many other parts of the story of the context that’s totally missing when you’re looking at something that’s, you know, for that starting point that totally exists when you’re a little bit further along, a little bit more comfortable in that skill set and you need some of those other pieces to really be valuable.

[00:07:14] BO: Exactly. What do you what do you do once you’re using this thing in anger for real?

[00:07:20] SY: Yeah. I think that might be the best way to sum up intermediate content, “Things that you use in anger.” Okay. So we talked about, my example was, you know, CSS and front end stuff. In the Upcase world, what are some of these more intermediate topics or pieces of content that I might come across?

[00:07:41] BO: I would say the biggest one is probably testing. Testing is very much part of the thoughtbot culture. It’s a very common stumbling block. And if I were teaching a person Rails and they were new to it, I would leave out testing for a long time because there’s already so much to learn.

[00:07:56] SY: Yeah, agreed.

[00:07:57] BO: And testing is like such an important practice and totally worth learning. But like again, like you have to figure out what to learn in what order, like the sequencing matters a lot or you can just really lose people. And so we found that there were a lot of people at roughly the intermediate level who wanted to get into the testing stuff or had been going down that path but were struggling, like, “Okay, I read the intro to TDD guide, but like how do you actually do this like for real? Can I see someone who knows what they’re doing actually do this?”

[00:08:25] SY: That’s such a great example and I like that because when I think about intermediate content, I’ve always thought of it as a more advanced version of something I already know about, but I totally agree with you that testing isn’t something a beginner should worry about. It doesn’t make any sense. You know, what do you even know what to test and why when you don’t even know how to build the thing that you want to test? You know, it just doesn’t make any sense to learn it so early.

[00:08:52] BO: Totally.

[00:08:53] SY: Yeah. What are some other topics or things that maybe folks listening have heard about and think they should know about but maybe should hold off on?

[00:09:01] BO: So there’s one that’s very dear to my heart which is Vim, which is a text editor.

[00:09:07] SY: Yup.

[00:09:08] BO: And it’s one of these things where it’s an incredibly powerful tool and the rewards for learning it will pay back over such a long span of your career that I think it’s worth doing. But again, I don’t think it’s worth doing right away necessarily.

[00:09:21] SY: I completely agree and the only reason I know Vim is because of thoughtbot because you all made me learn it and it was the most painful two weeks. Oh my goodness! I felt absolutely useless, but I did it and now it’s just fun. I really enjoy it. And because I know Vim a lot of people will say, “Hey,” a lot of beginners especially will say, “Hey, do you think I should learn it?” And I’m like, “Nope. Don’t do it. Of all the things you could focus on, that is not the thing right now.” You know, when you get a little bit more comfortable, pick it up later, but that is definitely not a priority at the beginning.

[00:09:54] BO: Yeah. I think this is somewhere where a teacher or a curriculum can add so much value and just telling you like, “Hey, don’t think about that right now.”

[00:10:00] SY: Yes.

[00:10:01] BO: I think the right thing to do is to not think about that, it’s to think about other stuff and focus on the more important topics at the time, but also I don’t want to like shut down someone’s question. So it’s sort of a balancing act where I want to like acknowledge that like it’s reasonable that you asked that. It’s not like you did something wrong. I don’t want to be like your parent like, “Ask me when you’re older,” or something, just like totally shut them down.

[00:10:19] SY: Yeah.

[00:10:21] BO: But it’s like, “For your own good, I’m going to not tell you why keys are symbols and Ruby is, it don’t worry about it. It’s fine.”

[00:10:27] SY: Okay. So what do the rest of us do if we don’t have a Ben in the room, if we don’t have someone like you to say, “Actually, you know, don’t worry about that,” we come across something on the Internet, on Twitter, in, you know, a course and we go, “Ooh, is that another thing that I need to know?” How do we screen those things out?

[00:10:47] BO: It’s okay to have that curiosity. I think you should probably try to like learn widely, like if there’s a topic or a course or anything and you’re like, “This looks interesting and maybe relevant to me. I want to give it a shot.” Totally do that. I think the important thing is the mindset to have which is if you come across something in there and it just doesn’t click, don’t worry about it too much. This happens to me all the time where it’s like it doesn’t make sense the first time or the second time, but the third time I finally got enough context and I can actually slot it in somewhere and I’m like, “Oh, it’s kind of like that other thing that I’ve learned in the interim but different in this way.”

[00:11:18] SY: Yeah.

[00:11:19] BO: So I think cast a wide net if that’s how you like to learn, but don’t worry about like a total completionist kind of approach, like, “I have to learn every chapter and understand every example or whatever.” Feel free to just let stuff go because there’s so much like you’re going to have to do that. It’s fine.

[00:11:32] SY: And I think for me as a career transitioner, that’s been the weirdest part about coding because when I think about school or just even most other jobs, you’re supposed to be a hundred percent prepared, you know, you’re supposed to digest every single piece of information and know it to completion and then you do the thing, you give that pitch, you give that presentation, you take that test, right? Like you prepare and absorb everything and then you execute. And with coding, I’ve had to really, you know, rework how I think about it to be, “Okay, I don’t need to complete everything.” It would be nice to be familiar, you know. Hopefully I can identify the key parts and know those key parts well and the rest of it eventually will be more familiar, and at some point, hopefully, I will get it, but that’s hard. It’s just a totally different mindset than most other careers will allow.

[00:12:27] BO: Absolutely. Yeah. Understanding that to me has become such an asset. I happen to be like working on a project that is very difficult for me technically and I think one of the biggest things that I’m bringing to the table right now is that I understand that it’s okay that I don’t know all of it and that the pieces will slowly and steadily fall into place if I keep working on it and like the things that seem important might not be important, so it turns out don’t worry about it after all anyway. Being able to sort of stay calm as I kind of blindly fumble about in the dark and like pick up something like, “What is this? I don’t know what this is. I’ll put it back down.” It’s like that’s actually just kind of okay and eventually it works out in the end.

[00:13:04] SY: Yeah, that’s basically me coding, just picking things up and going, “What is this?”

[00:13:07] BO: Yeah.

[00:13:08] SY: So I’m curious about your opinion on even the word junior because the slogan or the tagline I guess for Upcase is, you know, “Take junior out of your title.” That’s the thing. That’s the goal. And that word junior has been surprisingly controversial like, you know, the first time I heard of a junior developer, junior engineer, it seemed I thought it was great. I thought, “Okay, cool, we have levels and we can work our way up,” but it’s become kind of this controversial thing where people are using the title junior to really just pay people less and that ladder doesn’t actually exist and the levels aren’t really there. It’s kind of become this funny, frustrating word for folks. I’m curious. What’s your opinion on that title?

[00:13:54] BO: To me the word seems like it shouldn’t matter too much. It’s what you talked about where it’s like, “Oh, there’s actually no career advancement path for someone. We’ll slap this title on you, but then leave it there and not help you grow, not pay you more, not give you more responsibility.” That’s the problem right there to me.

[00:14:11] SY: Right. It’s the job I guess itself, right? It’s not really the word. It’s the context around it. And that’s one thing, you know, also with being a developer is it’s hard to know when you’re no longer a junior, right? So even if I’m not waiting for my company, my boss to say, “Okay, now you’ve graduated, we will take junior out of your title.” If I wanted to take it out of my title and, you know, maybe apply to something that’s a little bit more senior, how do I know that I’m now intermediate? How do you know just for yourself when you’ve leveled up when you’re ready to level up?

[00:14:46] BO: So one kind of lame answer to this is that there actually is no standard that defines junior and not junior. And so my best answer to this is you have stopped being a junior programmer when you realize that programming is mostly about managing a series of trade-offs. So I like to think of programming as there is a huge panel of dials in front of you and you can turn each dial up or down and every dial that you change has certain trade-offs. So as you add more levels of abstraction, as you do any sort of programming technique, like I want to take this line of code and move it over here, or I want to extract a method or extract a class. Each step you take, each dial has various trade-offs. And so there’s a ton of them in front of you and you have to on a case-by-case basis decide which dial should I move in which direction, how will that affect the other dials, and which one gives us the best result given that all things have some good sides and some bad sides.

[00:15:47] SY: I really, really love that. And I think, yeah, I didn’t think of it in terms of dials myself, but there was a point in my career where I realized that coding is just a lot of decision-making and sometimes postponing those decisions and saying “I’m not going to decide that right now. I’m going to wait until I have more information or, you know, feel more confident” or whatever it is. But I really like that idea of there just being a lot of dials and you’re just figuring out what you’re willing to give up and what you are hoping to gain.

[00:16:15] BO: Exactly. It’s like in the beginning, you’re thinking sort of in absolutes where it’s like, “Oh, like my methods shouldn’t be longer than five lines,” or, “I should write a test for every line of code that goes into production.” I think when you get more experience you start to realize there are pros and cons to each of those things and you need to make a choice on every little bit and that’s like what you said, that’s what you’re doing all day long, it’s the decision now and what decision should we make.

[00:16:39] SY: When you think about your own coding career, was there a moment where you found yourself stepping more to the intermediate level of being a developer?

[00:16:52] BO: I can’t picture a moment like suddenly I was like, “Ah, there it is. Now I’m intermediate.”

[00:16:58] SY: I’ve arrived. Yeah.

[00:16:59] BO: Yeah, I have arrived, it’s like, “Oh,” and all of a sudden intermediate. I think some of it was just in my own confidence. I noticed that I was getting more confident in things. I was writing Ruby on a small team before thoughtbot and I spent all my time in the beginning pair programming with my boss to sort of get up to speed because they were way ahead of where I was. And just slowly but steadily I kind of caught up a little bit and then was able to produce code myself. I was able to get stuff done without him and I was like more confident in meetings, like we would meet with like a client, like a stakeholder person, and they’d be like, “We need to do X.” And I’m like, “Oh, yeah, maybe you actually don’t need X, maybe it’s actually the real problem is this.” So it was somewhere around there.

[00:17:39] SY: Yeah, and what I like about that is it almost feels like you had an environment where you could measure your own progress, right? Because if you are constantly pairing with someone who’s a lot better than you and has more experience than you, you can see yourself getting to decisions faster, coding faster, being able to contribute to the conversation more, you know? In the context of always pairing and working with someone who’s better, you have regular opportunities to check yourself and just see where your progress is.

[00:18:12] BO: Totally. And that’s what I like about working with people.

[00:18:14] SY: Yeah. Yeah, exactly. Yeah, because my next question is going to be, you know, if I’m trying to speed that process up, right, if I’m a junior, a junior level, I’ve been stuck there for a little while, I’m trying to, you know, move a little bit faster, move my career forward, get going, go up to intermediate, what are some things I can do to get there a little bit faster?

[00:18:36] BO: The quality of your co-workers is the most important variable in this, I think.

[00:18:39] SY: Yup. Absolutely.

[00:18:40] BO: And if you don’t have great co-workers, it doesn’t have to be co-workers, it could be other people at a meet up or friends or professors or something like that. In programming pairing is a nice way of sort of doing that in real time, like pair programming is great, but even if you don’t pair with someone, just having co-workers around you that have high standards and care about what they’re doing and want to help you level up is I think just the biggest variable.

[00:19:03] SY: So you mentioned pair programming. How exactly does pairing work?

[00:19:06] BO: Pair programming is two people working on the same problem, on the same computer. So the way it is usually done is if you and I wanted to pair on something, I’d say, “Hey, Saron, could I get another set of eyes on this?” And you would say, “Sure, no problem.” And you being very savvy would probably bring your keyboard and we’d plug your keyboard in and you and I would sit with the monitor between us and we would take turns typing. So maybe I’m writing the code and you’re looking at it and thinking and considering the edge cases or maybe you’re writing the code and I’m doing that and together, hopefully, we can produce something better, stay blocked for less time, have fewer bugs than if we were doing it on our own.

[00:19:43] SY: Yeah, and I think pairing has been really, really helpful in my leveling up, but it can also be a little scary when you’re, you know, pairing with someone who is, you know, way more… I think, yeah, one is that, but I think I paired with Joe Ferris, the CTO. Oh my God! I was terrified. He was very nice. It worked out really well, but the whole time I’m like, “Oh my God! Please don’t be stupid. Don’t be stupid. Don’t be stupid,” of me talking to myself.

[00:20:06] BO: I had the exact same experience with Joe.

[00:20:09] SY: Yeah? Okay.

[00:20:09] BO: Not because he’s… he did nothing wrong. He was very friendly.

[00:20:11] SY: He was great. He’s amazing.

[00:20:12] BO: But he’s just extremely talented, fast programmer, and it’s intimidating.

[00:20:18] SY: Yeah. Yeah. So when you are in those sessions, what, as the junior person, the person who maybe doesn’t really have a lot to contribute, are there things that we can do to, number one, be useful to the pairing session, but also to make sure that we’re getting value and we’re absorbing as much as possible?

[00:20:36] BO: Yes. So it’s a little painful, but you have to ask a lot of questions. That’s probably the number one. Beyond that, you should realize that that sort of impulse that you have in your head or that voice that says, “You’re slowing this person down, you shouldn’t ask too many questions,” can actually be quite wrong. I bet a lot of people in your audience have had this experience, which is you are pairing with someone and they say, “Why did you do it that way?” And you say, “Well, I guess I just always sort of do it that way,” and then you realize you have no good reason for that.

[00:21:09] SY: Yeah.

[00:21:10] BO: And so sometimes someone with like a new perspective, a fresh perspective asks you a question and can point at this like sort of gap in your own knowledge and offer like a really interesting opportunity to go learn it together right then and there.

[00:21:21] SY: Absolutely. Yeah. That’s one of my favorite things about pairing with someone who is less experienced, who knows less about the thing that I’m working on is not only is an opportunity for them to point out my knowledge gaps, but it also forces me to be really thoughtful because I anticipate those questions, you know, like I think, “Okay, I want to do this right, I want to make sure I’ve thought about this,” because I see that coming, so actually gets me to do some of my best work in that way.

[00:21:50] BO: I believe it. Yeah. It probably keeps you from going down a path that’s like a little too clever.

[00:21:54] SY: Yeah. Yes. Yeah, exactly. Yeah. Absolutely. Yeah. One of the things that I really appreciate about the Upcase platform, which by the way recently was announced to be like free now, right?

[00:22:06] BO: Yeah.

[00:22:07] SY: It used to be a paid thing, but now it’s totally free and open for anyone, which is awesome.

[00:22:10] BO: It turns out we have buried the lead a little bit.

[00:22:13] SY: Yeah, right, which is great. So anyone who is listening can go and the link will be in the show notes and you can check it out and you can level up today at no cost to you. So I know you don’t worry about that anymore, but shout out to thoughtbot for doing that. I appreciate that. So in terms of the content, what I really like about the selection is that it’s not just languages and frameworks, even a lot of the conversation you and I have had today is about all the other stuff that you have to think about as a developer. It’s, you know, Vim, like it’s a tool, it’s the way that… it’s the environment in which you do the coding, right, even like testing is a process that you implement to create better products. And so it feels like there’s almost this other type of education, this whole category of learning that isn’t JavaScript, Ruby, Python, it’s how to do the JavaScripting and the Pythoning well. You know, there’s all this other stuff. If you don’t want that stuff on Upcase, where do people normally learn that stuff?

[00:23:13] BO: I don’t really know. My guess is a lot on the job. So there’s nothing like having to actually make a PR or make a commit in Git to force you to go figure out what the command-line flags are to that.

[00:23:26] SY: Yep. Yeah.

[00:23:27] BO: Or it’s like if I’m going to get some work done, I have to do this. And so I think most people kind of patch together a functional subset of the various tools they need to get work done and we’re all doing that by the way. That’s not like a bad thing. But I would say one of the strengths of things like Upcase doesn’t have to be Upcase is that it can kind of fill in the gaps.

[00:23:45] SY: Yeah.

[00:23:46] BO: I imagine most developers have sort of… they’ve got their five or six Git commands that they’re pretty familiar with, but they maybe don’t have like a mental model for how the Git model works or how things fit together. And so sometimes it’s nice to go kind of fill in those gaps.

[00:24:02] SY: What are some of those other not language, not framework specific things that new developers may not know they should know about? We talked about testing, we talked about pairing, talked about Vim. Are there other coding related things that folks should maybe look into or even try to improve?

[00:24:19] BO: So yes. I think the best answer to this is honestly it’s the things that you’re using a lot. So one habit that I got into early in my career that paid off for me tremendously was keeping what I call the Tool Sharpening List. So during the day when I was coding, I would try to accomplish a thing and it would be not great. I was like, “Wow, that took me a lot of keystrokes to get done or like I really struggled with getting this thing to work.” And so I would just jot myself a little note in this list that was like, “Find a better way to undo my last commit,” for example.

[00:2451:] SY: Yeah.

[00:24:52] BO: And I would store in that file and then in the mornings when I got to work, I grab a cup of coffee, and the first thing I would do is spend about 20 minutes looking at my Tool Sharpening List and I’ll pick something on that list and improve that.

[00:25:02] SY: Oh, I love that idea.

[00:25:04] BO: It was huge. This was like tremendous for me. It was like every day I shave down a rough edge in my environment, in how I worked, and it was all stuff that was super relevant to me because of the thing that I had actually encountered and it had this really nice effect where if you’re trying to get work done and you realize that your workflow is kind of suboptimal, you don’t want to stop right then and go research something to improve it.

[00:25:30] SY: Right. Yeah, exactly.

[00:25:31] BO: But you don’t want to miss that opportunity to fix that thing for later and this little habit that I got into solve that really nicely for me.

[00:25:39] SY: Coming up next, we dig into the technical side of building Upcase, what it was like for Ben to go from developer to product manager and how being a product manager has affected his coding skills. And after the break, Tales from the Command Line, it’s up next after this.

[00:25:58] We’ve talked about open source a bunch of times on this podcast, but frankly, open source is so big and complex and fascinating that it needs its own show, and it has one. It’s called Command Line Heroes. It’s produced by Red Hat and it’s hosted by me. That’s right. I’ve got another tech podcast talking to incredible people about all things open source. We talk about the history of open source, the introduction of DevOps and then DevSecOps, and we even do an interview with the CTO of NASA. And that’s just the beginning. We also dig into cloud and serverless and big data and all those important tech terms you’ve heard of, and we get to explore. If you’re looking for more tech stories to listen to, check it out at redhat.com/commandlineheroes. Link is in your show notes.

[00:26:48] DigitalOcean is the easiest way to deploy, manage, and scale your application. Everything about it was built with simplicity at the forefront; setting, deploying, even billing. Their support is amazing. They’ve got hundreds of detailed documents and tutorials. So if it’s your first time deploying an app, they’ve got great tools and community to make it nice and easy. Try DigitalOcean for free by going to DO.co/codenewbie and get $100 in infrastructure credit. Link is in your show notes.

[00:27:20] Ready to change your life? Well, Flatiron School designed a school just for you. Flatiron is a global school with immersive and online courses designed for passionate people like you. If you’re looking to excel in a new, rewarding career, you can start right now. Check out Flatiron School’s free 75-hour boot camp prep, where you can learn JavaScript, Ruby, and do some interview prep. Flatiron School has helped thousands of students from all backgrounds invest in themselves by learning online or in person. By the way, did you know that they’re now part of WeWork, which means they now offer classes at a growing number of WeWork locations around the world. So go to flatironschool.com/codenewbie to learn more.

[00:28:10] Linode is giving you a chance to try their powerful servers built for all your infrastructure needs. They’ve got nine data centers worldwide with new data centers opening up this year in India and Canada. Getting started with a shiny new server takes less than one minute, so you can get up and running in no time. And you can get a $20 credit by using the promo code CodeNewbie2019. Just go to linode.com/codenewbie for more info. Link is in your show notes.

[00:28:41] Tales from the Command Line. It gives us a chance to dig into one particular part of the episode and hear a different perspective from a really experienced developer in the field, Scott McCarty.

[00:28:52] SM: Yeah. My name is Scott McCarty. I am a Principal Product Manager and I focus on containers, like all the technology within containers that enables Red Hat Enterprise Linux and OpenShift.

[00:29:04] SY: Let’s begin. And how long have you been in tech?

[00:29:17] SM: So this year is 20 years, 1998.

[00:29:11] SY: Twenty years. Wow!

[00:29:13] SM: Which is so strange.

[00:29:14] SY: And you started in sysadmin, but you’ve had… I feel you’ve had multiple careers in tech. Is that fair?

[00:29:20] SM: It is, yeah. I started off in computer science and anthropology in college, kind of was a sysadmin in the lab. I was a lab assistant for like the grad students and that was kind of how I ended up down that sysadmin road. I would teeter on coding again in a lot of different jobs I had because as a sysadmin you kind of end up fixing and porting apps and doing all kinds of weird stuff that’s kind of like you were the catch-all bucket, right? Like you wouldn’t really write new apps, but you’d fix things, you’d migrate things. I was responsible for the Holly Hobbie and Strawberry Shortcake website at American Greetings back in the day and I had to port all that Java code to make it work on Linux from something else. I forgot what it was running on before, some non-Linux thing like IBM power or something, I forget. But I wrote installers, all kinds of installers, which it’s funny because now that I work at a software vendor I realized that’s considered engineering.

[00:30:13] SY: Yeah.

[00:30:14] SM: And I didn’t really think of it that way at the time, but then in retrospect, I realized I basically was an engineer building software, I just didn’t realize it. That’s another thing. I kind of touches on like that constant sense of Impostor syndrome or insecurity where you’re like, “Aw, am I really good at this? Am I really an engineer?” But after 20 years, I guess that does go away to an extent. To an extent, you still feel it, you learn to muscle through it, kind of you’re like, “All right, wait a minute, it’s just my insecurities. All right, wait a minute, I know the answer to this. Let me focus on this problem.” And you feel less scared to start to suggest the answers to problems.

[00:30:47] SY: Yeah. And so when you’re working through these different careers, in these different roles, is there a moment in each one where you go, “Oh, I got to know what I’m talking about”?

[00:30:57] SM: To an extent, like yeah, you start to realize at some point you kind of have an opinion on things. It’s funny. Now people will ask me like, “What do you think about blah, blah, blah?” And I’m like, “Well, I’m just going to let you know, I’m kind of opinionated about this,” and they’re like, “No, that’s why I’m asking you. I want to know your opinion.” I was like, “All right, you asked for it. Here’s my opinion.” So then after I was a sysadmin for many years, I ended up going into sales of all things, which was a change of companies and a change of roles, which was probably the most terrifying change I ever made. And then four and a half years into that, I started to realize I was teaching other people what we should be doing and you kind of wake up one day and you’re leading again and you’re like, “Oh, how did I get here? How did this happen?”

[00:31:36] SY: Yeah.

[00:31:37] SM: And then I change the product marketing and the same thing happened like three and a half years later. I started to realize I was guiding people on positioning and messaging and how we should message things and align them with other products across the portfolio and start to think of the stories holistically and you just get good at it. It’s bizarre. You start to show other people how to do it and you start to mentor other people and now I’m in product management and I would say I’m not there yet. There are certain things I know, but this is probably one of the hardest jobs I’ve ever had. I joke like I’ll walk into a meeting and I’m like, “All right, there are no good ideas. I just want to level set. We have no good ideas. We have only bad ideas. But now we have to figure out what the best bad idea is.” And everyone’s like, “Oh gosh, this again.” I’m like, “Yes, this is where we’re at.”

[00:32:21] SY: You mentioned that a couple times when you look around and you go, “Oh, people are asking me questions and asking me for my opinions and I actually have some really strong opinions.”

[00:32:30] SM: I have a funnier story that just popped in my mind about when I didn’t know, but I thought I did. I’ll set the stage here. You know, I was 19-ish. I started college. I had blue hair. I was in punk bands. I wore combat boots. I was like a complete freak back then. I mean nowadays, this is more common, but back then there was nobody like this in computer science. It was very, very conservative, I guess, is just the best way to explain it, and I show up, I came from a inner city school, like I went to a school that was very mixed. I was the only as they say. I had the feeling of the only. And I was starting to feel like I thought I knew what I was doing. I was programming for about a year and a half and I realized I was pretty good at it. I was maybe better than average, at least I fancied myself that. I was working on the Pac-Man game on the side and we were being competitive and basically like my friend goes -- I had this brand new laptop that I bought that I thought was like amazing. I remember it was like a Compaq 1135, it had like a K6-2 AMD 266 megahertz processor. I was like super proud of this thing, like I knew all of its stats and like all these things. I showed up one night at a restaurant with all these other kind of nerds, geeks, whatever you want to say, at the time, and I was like, “I know, I know what I’m doing here.” And I was like, “Let me show them this. They’re going to be like, ‘Yeah.’” My one friend Chad was like, “I mean, it’s cool, but why don’t you have Linux on it?” And I was like, “Linux?” I was like, “What is that word? Like I’d never even heard this word before, Linux, Linux? What is this? And he goes, “Yeah, it’s like another operating system.” I was so mad because he like said it in such a scoffing way. He was like, “I mean, you think you’re cool, but whatever dude,” you know, and I was like, “I will learn more about this than him. I swear on my life.” I was so mad. I think he regrets it because I probably talked to him every day multiple times a day on the phone for like 90 days straight. I was like, “I can’t get this modem to work. What is this weird error message?” I remember we went to Best Buy and bought Red Hat Linux 5.2. I could barely install it. You know, slowly but surely over like 90 days of chaos. There was no Google at the time. You got to remember like you couldn’t just Google problems. So I would just call Google which was my friend Chad, the original Google, and then one day finally, probably I was about 24, and I got a job at NASA and then I realized, “Okay, I know a little bit about this now.” And so then yeah, once I got a job, I think that helped me realize that I had something that was useful to the market, you know, but I learned it just because I was annoyed because he told me I didn’t know about something that was cool.

[00:35:00] SY: Yep. I love that. I love that that was what started your Linux career.

[00:35:06] SM: It’s always a balancing act, like you have to have enough confidence to know that you can bat at the next thing, so like going from being a sysadmin to going into sales was terrifying because I don’t know what I don’t know and I don’t know why these people think I can do this job. In a nutshell, you’re kind of like, “Why are these people having this confidence in me that I can do this? I’m not sure that I can do this.” But then at the same time you start to trust other people, like most other people are not going to tell you that you can do something if you can’t. I’ve found in my experience most people do want to see other people succeed, like it’s way more fun to invest in somebody like a junior person and invest in them and see them succeed than it is to invest in them and see them fail, right? Nobody wants that generally. But if some other person is telling you something, they’re like, “Hey, I think you’re really smart,” “Hey, I think you’re really technical, you’re really good at this thing.” As an engineer, I’m only skeptic. I’m like, “Ah, they don’t know enough to know whether I actually know this or not.” But then you realize, “Wait a minute, they’re proactively saying this, they’re taking time out of their day to invest in even telling me these words, they probably have a strong sentiment about this.” And so you have to start to accept that, right? Like at one point you go, “Oh, okay, this person seems pretty smart and they seem to know and they’re telling me and it’s been like three people now or four people or five or whatever,” and you start to realize, “I guess I need to have some confidence in myself and actually do this next thing.” That’s kind of the magic.

[00:36:35] SY: And now back to the interview. So I want to switch gears a little bit. We talked about curriculum and leveling up. I want to talk a little bit about building a product because you are one of the co-creators of Upcase so you were there from the very, very beginning. Tell me a little bit about how that idea came to be.

[00:36:57] BO: So thoughtbot had this teaching culture. And so in the beginning, we started running in-person workshops. And every single time we offered them people would say, “Could you record this or do it remotely somehow?” And every time we’re like, “Not sure, maybe.” And eventually we just did it. We’re like, “All right, let’s record one and we’ll sell it for less than the live one, but we’ll see what happens.” And people bought it and they liked it. It was valuable to them. And so we started recording more of the workshops. And around that same period, I had to kind of dip my toe and make a screencast and sell it, Waters, and the CEO of thoughtbot, Chad, came to me. He was like, “Hey, you should sell that screencast through our platform. We should put more content out there.” I was like, “That sounds great.” We were making more content and putting like my stuff up there and whatnot and suddenly there was like… all right, there’s like six or seven disjoint workshops up for sale on this the site we created. And one day I went to Chad, our CEO, and said, “Hey, I think we should change this to a monthly subscription. We should turn it into its own business and try to build a community around it and put just a bunch of stuff on there.” And Chad goes, “Yeah, okay, that sounds good. Go do it.”

[00:38:15] SY: And that’s how decisions are made. I love that. I love that you were so empowered to just have an idea and do it and then you actually did it. 

[00:38:24] BO: That is very much sort of thoughtbot. I mean, that’s down to like to Chad basically. And like right around then was when I did more or less my last client engagement. I was a consultant at thoughtbot and then I was like, “Okay, I’m working on this now.” That was just like done. Okay.

[00:38:37] SY: Interesting. So that became your full-time job at thoughtbot? 

[00:38:40] BO: It was, yeah, for many years.

[00:38:41] SY: Very cool! Okay. So when you switched from doing the consulting thing to the full-time Upcase thing, this brand new thing that the CEO of the company approved and gave you the green light on, what’s the first thing that you do?

[00:38:55] BO: I’m not sure the first thing we did. We changed the pricing model because that made sense to us, like we wanted to have a thing that you paid a little bit each month as opposed to one-off purchases so that we could create a ton of content and everyone would get it.

[00:39:07] SY: Yeah. Yeah.

[00:39:08] BO: And I think the pricing model change our mentality around it. We’re just like, “Yeah, we could just make a lot of stuff” and start thinking about this as more of a curriculum than like one-off purchases and we also started thinking about it as a community. So I don’t remember when we started, when we added the forum, but we did, and that helped a lot, like a forum does not make a community by itself, but it doesn’t hurt. It’s one of those sort of key early steps for us, I think.

[00:39:30] SY: Yeah. So when you are moving from, because it was different iterations of the product, right? There’s the live. We’re getting live classes and there’s the recorded classes and then now there’s a lot of different stuff that people can kind of do a little bit more a la carte or build a curriculum out of. How did the curriculum or the content itself change over those iterations?

[00:39:54] BO: So it changed in a couple ways. One is I think it got better. We re-recorded a number of our most popular workshops because, well, because Rails versions would change and whatnot.

[00:40:03] SY: It’s true.

[00:40:04] BO: So a two-day in person class can have a very different shape than an online class and probably should. And so the online versions got more split up. Some people would like binge on it over like just a day or two, but a lot of people would kind of want to consume it in smaller bites. So one of the first things we started doing was like break these into smaller pieces. Another thing was that we… and like along those same lines is we added actually a weekly video to go out to people.

[00:40:31] SY: Yeah.

[00:40:32] BO: When you sign up for the service, there’s like this big pile and they’re like, “Wow, that’s a lot here.” And by making a video every week, a short one, and sending it out to people, it was like, “Okay, if you find that a little too overwhelming, maybe just try watching this one each week and you’re still going to get some good knowledge like pretty guaranteed,” and that might be a good kind of on-ramp to this.

[00:40:52] SY: Yeah. So when I think about the process of building the product physically, I guess technically, there’s the content itself, which it sounds like you already did a lot of thinking around that, there already was a lot of content that was established from the live teaching and then the recorded teachings and now there’s this pricing change and there’s some shift in the content, but you also have to build out an actual platform, right? You have to build like software to make this business run. What was that process like?

[00:41:23] BO: It was like most software development processes, much longer than we anticipated.

[00:41:27] SY: How long did you think it was going to take and how long did it actually take?

[00:41:31] BO: I just remember spending so much time writing code that didn’t really make the product that much better.

[00:41:38] SY: Oh, interesting.

[00:41:39] BO: Yeah. So like we integrated with Stripe for our billing purposes. It’s gotten better in this regard. But back then, it was like incredibly easy to get on boarded, like the first… getting to the point where you could have a credit card form on your website was like an hour. And then over the next year, I did probably another like hundred hours of development. We’re like, “Oh, we need to give people receipts.” And some people want special things written on their receipts and people keep mentioning this thing about taxes and whatnot. I don’t want to think about that for sure. I just kept going back to the product and I would like spend a day writing Stripe support code and I’m like, “No one is paying us for Stripe support code. I’m just like kind of fooling around here.”

[00:42:19] SY: So when you think about… and that was six years ago now, right? When you think about what you know now as a product manager and you actually are managing your own product with your startup now, what are some things that you learned in building Upcase that you would not do again today?

[00:42:36] BO: So there’s this pretty famous Paul Graham essay and Paul Graham is the start-up investor, and it’s called, “Do Things That Don’t Scale.”

[00:42:44] SY: Yeah.

[00:42:45] BO: His advice is in the beginning founders are always looking for scalable solutions to things, like how are we going to deal with this when we have thousands of customers?

[00:42:53] SY: Yeah.

[00:42:54] BO: And you should probably in the beginning like what it takes to get most companies off the ground is doing things that don’t scale. Don’t think about a thousand customers, just think about five. And so if it means you have to like write someone a custom birthday cake or something, like do that even though it’s not a thing you can do later at scale. And so one day Chad and I read this post and we’re like, “This is great advice. This is so good. We got to do this to make Upcase more awesome.” And so we decided to offer one-on-one mentoring to I think just about anyone that signed up for Upcase.

[00:43:25] SY: Oh, man!

[00:43:26] BO: And within like a month, our calendars were just like booked solid with like 30-minute video calls with people.

[00:43:33] SY: Wow!

[00:43:34] BO: We did learn a lot. But you can imagine after like 30, like you stop learning new things. And so we were like, “Well, we did the thing that didn’t scale and it didn’t scale. So I think we have to kind of… like we’re already at too big of scale to do the things that don’t scale. So we got to do something else.” And so like we released like a lot of that, like pretty fast. So be careful about blindly following, you know, advice from the internet, I guess, is the lesson there. 

[00:44:01] SY: Yeah. And your situation is also different because you’re kind of a startup within an existing and pretty successful company, right? So you kind of do have to think about scale a little bit, just a little bit at that point. So yeah, that’s interesting.

[00:44:13] BO: Yeah, exactly.

[00:44:14] SY: It’s also interesting point about talking to customers too because you know for a long time before I got into coding and even just the startup world, I read a lot about it and I would read about, you know, “Get Out of the Building” is like a famous mantra in the Lean Startup World and they will tell you to do all these customer interviews and I was always confused by it because it felt like trying to put a scientific process on something that is not scientific and I’m thinking, “Well, how many data points do you need before you can conclude?” You know, like you know for sure that this feature is indeed the thing to work on, you know? Like I always saw it from that perspective and it wasn’t until I just did it that I realized, “Oh, you just need like five.” You really don’t need hundreds or even dozens a lot of times. You just need a couple to point you in the right direction and you do a couple more. So yeah, a lot of… and I think this applies to coding too. A lot of what you read about makes a lot more sense when you just do it. You know, when you just roll up your sleeves and take that first step.

[00:45:120] BO: Oh, yeah. Yeah, there’s nothing like actually throwing yourself into it.

[00:45:14] SY: Absolutely. So when I think about a learning platform, again on the technical level, I’m thinking I can watch the videos, there’s some type of media player, I have to pay for it. So there’s some type of credit card payment processing tool thing. What other stuff is there? What are some of the other features that you had to think about when building this product?

[00:45:37] BO: So as a product goes, it’s fairly simple from a functionality standpoint because the thing that you’re buying is not like a normal SAS where it’s like I’m buying a tool that accomplishes this goal. So much of the work that I did honestly on Upcase was not writing code. So much of Upcase was content creation and being in the studio and figuring out how do we teach things, how do we reshoot this, how do we make it clearer and better.

[00:46:00] SY: Yeah. So when you transitioned from being a consultant at thoughtbot, which was I imagine mostly actual coding like coding on a product and working with clients and then moving to product management, what was the biggest shift? What was the biggest change for you?

[00:46:18] BO: I guess it was that a lot of the times writing code is not the answer.

[00:46:21] SY: Oh, interesting!

[00:46:32] BO: And when you’re a developer, all problems are solved by code basically.

[00:46:26] SY: Yes.

[00:46:27] BO: So like someone has already vetted this customer and determined that the thing that they need is code.

[00:46:33] SY: Yeah, that’s true.

[00:46:34] BO: And so it’s like all you get, like constantly you just meet a new person, “Hi, this is your new client and they need codes.” I’m like, “Great! And I went to code, let’s make code. Here we go.”

[00:46:42] SY: I can do that.

[00:46:43] BO: Yeah. And when you’re trying to grow a business lots of your problems are not solved with code. So it was tough to give up my programming roots basically where a lot of the times it’s like, “I haven’t written code in 10 days and that’s the best thing I could have done for this business right now, but it was something I love.” So it’s a hard tradeoff I had to make.

[00:47:01] SY: Yeah. At that point when you switched over to doing Upcase, how long had you been coding for professionally?

[00:47:07] BO: About five years.

[00:47:09] SY: Okay. So at that point, were you worried that your skills might slip by not being in the weeds with coding so much? Because I know like a lot of folks in our community will start off coding and then maybe it’s their first job, do it for a couple years, and then switch gears to something that’s related, still in the same world, but not exactly coding. And I’m wondering, when you made that shift, were you concerned about your skills?

[00:47:36] BO: Yes, and I was right to be concerned because I did slip.

[00:47:38] SY: Yeah.

[00:47:40] BO: I missed JavaScript basically. There was this like emergence. So I was like, “Holy crap, JavaScript!” And it was backbone.

[00:47:46] SY: Yeah.

[00:47:47] BO: And things like that. And I sort of like missed that whole thing. But yeah, if you’re not programming full-time, the world of programming changes so much that keeping up with it is honestly quite a bit of work.

[00:48:01] SY: So I’m wondering now as a CEO of that tiny startup you mentioned when you reflect on your years as a developer and then your years doing Upcase and building a product where code is still important but not the most important thing, how do you balance your coding skills and your product management skills? Do you get to code as much as you used to?

[00:48:24] BO: No. So yeah, I’m in a tiny startup right now and there’s three of us and my other two co-founders are both developers and they are the only ones writing code right now and I’m focused on sales and marketing.

[00:48:33] SY: Yeah.

[00:48:34] BO: So I have like almost kind of officially given up the keyboard in a professional capacity for my day job.

[00:48:38] SY: How do you feel about that?

[00:48:39] BO: It’s not awesome honestly. I view it as a bit of a sacrifice that I’m making to hopefully make this business work. I’m not doing the thing I love most though. So it’s tricky. So I’m finding that I am doing more stuff on the side. But yeah, to be honest, it’s a sacrifice, but it’s one I’m willing to make right now.

[00:49:57] SY: Yeah. So what advice do you have for folks listening who are juniors, who are hoping to level up and be a little bit more intermediate? What advice do you have for them on how they can make that transition?

[00:49:11] BO: Working with good people is the best. The best of the best to me honestly is sitting next to somebody who is a great developer, who’s friendly and patient, and pair programming with them as much as you can. So it’s possible that you can do that at work, it’s possible that you can do that at a meet up. If you can’t find good co-workers and there’s no good meetups, you probably should move or something. I think it’s never been easier to get access to this kind of knowledge.

[00:49:33] SY: That’s true.

[00:49:34] BO: But if it were me, if I will like delete my brain and start from scratch, I would want to do the same thing I did last time which is find someone really good who’s nice and patient and sit with them a lot as much as possible during the day and just like try to copy their brain into mine as efficiently as possible.

[00:49:50] SY: I like that strategy. All right. So now let’s move on to some fill in the blanks. Are you ready?

[00:49:55] BO: I’m ready.

[00:49:56] SY: Number one, worst advice I’ve ever received is?

[00:49:58] BO: So I tried to come up with an answer for this one for a while.

[00:50:02] SY: It’s a tough one, right?

[00:50:03] BO: I kept going back to it and I could not come up with a good answer and I’m not sure why that is. I think it’s either I’ve been like fortunate enough to only have people around me they give me good advice or I’m just good at blocking it out like when I get the bad one. I don’t know. This is not to say that I only make good decisions because I’ve made so many bad decisions, but it’s usually as a result of advice I’ve given to myself.

[00:50:25] SY: Can you give me an example of that? That sounds really interesting. What is that advice you’ve given to yourself?

[00:50:31] BO: You know, I don’t want to get too deep into it, but I will just say like dating is like the genre for this. Yeah.

[00:50:37] SY: That’s a different podcast, but okay. I got it.

[00:50:39] BO: Yeah, exactly.

[00:50:40] SY: Number two, my first coding project was about?

[00:50:43] BO: So the first time I ever touched code and changed it and saw the world change was in QBasic, which was like this programming language for I think DOS back in the day and there’s this game called Gorilla.BASIC. It’s like a little game where you have two gorillas standing on a skyline and they would throw bananas at each other.

[00:51:02] SY: Oh.

[00:51:03] BO: And so like you would enter in an angle and you would enter in a speed and then like it would fire the banana and you would try to hit the other player.

[00:51:10] SY: Interesting.

[00:51:11] BO: And this game had the source code right there, like you could just go look at it and it’s the first time I’ve ever seen it and I was like, “Oh my God! What is this arcane magic?” And there was like a set of constants at the top of this file, and like these are the constants that controlled the game and there’s -- gravity was set to a certain number. And I was like, “What if I just change this to a totally different number?” And all of a sudden like you would run the game and throw the banana and instead of like going up in a nice arc and coming back down, it would fire off into the sky, it’s like having a negative gravity all of a sudden and we just like enter orbit and be gone.

[00:51:39] SY: Oh, wow!

[00:51:39] BO: And that was like the first time in my life, I’ve been like, “Wow, like I changed, I can see now, I kind of understand if I change this thing over here, the program changes, like, wow, that’s really cool.”

[00:51:47] SY: That is really cool. How old were you when you did this?

[00:51:50] BO: Pretty young. I was really lucky. My dad was in the high-tech industry. So we got a computer pretty early on and so I was probably 10 or something.

[00:51:56] SY: Yeah. Well, 10 is pretty young. But at that point, did you know that you could get a job doing stuff like that?

[00:52:04] BO: No.

[00:52:05] SY: Yeah.

[00:52:06] BO: No. Development being like a good career was a very happy accident for me.

[00:52:10] SY: Oh, yeah.

[00:52:11] BO: Well, like I was in love with computers so early, but I have never was like, “And it’ll be a great career someday.”

[00:52:17] SY: Yeah.

[00:52:18] BO: There’s just like, “I love this thing. I want this. I want to do nothing but touch it.” And so I did, and just out of pure luck, it turns out that people will pay you to do this and that’s lucky me.

[00:52:27] SY: At what point did you realize that it could be a career?

[00:52:30] BO: So I got like an internship when I was in high school to do IT work for a company. And just the stuff I had learned kind of organically, it turned out to be like what a junior IT person would do at a company.

[00:52:45] SY: Wow! That is really lucky.

[00:52:46] BO: Yeah. My dad was in sales, and the opposite of bad advice, he gave me this great advice which was for any job or anything you want really, there’s like the front door normal path, which is like send your resume here or like do an interview here, go to this right school and then get interviewed because you went to the good school, and then there’s like the back door.

[00:53:05] SY: Yeah.

[00:53:06] BO: Which is like it requires a little bit more work, but can often be like a better shortcut.

[00:53:12] SY: Yeah.

[00:53:13] BO: So like I wanted to get an internship when I was in high school and I was like, “I fiddle around computers so long, I’ve been so obsessed with this, surely this is somewhat valuable.” And so I spent a couple days at the start of the summer walking around to companies and trying to get them to hire me. And the big companies that I would walk up, I’d be like, “Hi, where’s HR?” And they’d be like, “I’m sorry, who are you and how can I help you?” And I was like, “Yeah, I’m looking for a job,” and I was like 16 or 17 at the time. And they’re like, “Oh, sure. Why don’t you leave a resume with us and we’ll get back to you?” And I was like, “Right, that’s the front door. That means no. That means that’s never going to work out.” But I kept wandering around and one day I found a startup and the startup didn’t have a receptionist, like any person up front because they were too small.

[00:53:57] SY: Yeah. 

[00:53:58] BO: And so I wandered through and like saw someone in the hall, it’s like, “Hey, where’s HR?” He’s like, “Oh, it’s Andrea. She’s over there.” I was like, “Great. Thanks.” And then I walk over to HR, I was like, “Hi. Can I have a job?” And believe it or not, like that worked.

[00:54:12] SY: That is amazing. 

[00:54:14] BO: Yes. “So who are you and what do you want to do?” And I told her and she’s like, “This is crazy, but we were just considering posting a job ad for a junior IT person. Let me go get our IT manager and have him talk to you.” And I was like, “Wow! I can’t believe that worked.”

[00:54:25] SY: Oh my goodness!

[00:54:26] BO: So this is the inflection point for my career where like having this tech-related experience gave me so much legitimacy later on that I really think it like took the curve of my path and really just like yanked it in a particular direction that was super huge for me.

[00:54:39] SY: That is so amazing. Were you nervous at all about going into… because you’re a kid, just to remind everyone, you’re a child, you’re a teenager and you are walking into these businesses where grown people are working for money. Did you feel any type of way about that?

[00:55:02] BO: Oh, yeah. I mean it was very nerve-wracking to do and it was a little scary afterwards even when I got the job. I remember like getting dressed for my first day of work, like I put on like a baseball hat and my mom was like, “No, no, honey. No baseball hat. Not at work.”

[00:55:14] SY: That is so horrible.

[00:55:16] BO: This is business casual and was like, “Oh, okay.” I was like, “Oh, my hair looks kind of puffy so I thought of the hat.” She’s like, “No, no, no.” So yeah, I didn’t know what was up, but like honestly that lesson of like try the other thing has been a recurring theme for me and has given me some of my biggest breaks.

[00:55:34] SY: Number three, one thing I wish I knew when I first started to code is?

[00:55:38] BO: That feeling of being stuck and not knowing what’s wrong and this thing should totally work and it doesn’t and this is so frustrating. I’m like, “I hate this and I’m angry” is a hundred percent normal and continues throughout your career and it’s not you. And so if you’re feeling that and especially you’re in the early days, the natural response to that is like, “I’m messing up,” or like, “I’m not getting this as quickly as I should.” But that’s just the life of a working programmer. And so your best bet is to like don’t think negative thoughts about yourself, realize that’s just the job, and hopefully you kind of learn to love it, love the suffering just a little bit. 

[00:56:20] SY: Love the suffering, I like that. Yeah, you know, what always confuse me, especially in the first few years of my coding career, is the fact that there were so many prominent, you know, famous, accomplished developers who seemed to enjoy bragging about how little they knew. You know, you’d get you folks like Scott Hanselman saying like, “You know, I still don’t know what I’m doing, I’m still figuring it out,” and I would think, “Scott, we can we can see that.” You know? Like, “Why would you admit that you…? And why would you publicly admit that you don’t know what you’re doing?” It never made sense to me and it wasn’t until years in that I realize it’s because the value of a programmer isn’t in how much you know, it’s the fact that you know you will figure it out. Once I realized that, things got a lot easier, you know? There wasn’t this intense pressure to absorb and memorize and internalize every single thing that came up. It was trusting the fact that “I don’t know this now, you know, I’m picking things up seeing if it works, but I know that I can figure it out” and over time I built up that confidence. And I think that’s really what we get paid for as developers. We get paid to figure stuff out, not to already know everything.

[00:57:35] BO: I love it. Good wisdom there.

[00:57:36] SY: All right. Well, thank you so much Ben for talking to us about leveling up and how to get from junior to intermediate, how to build products. I feel like we covered so many great topics in that one. Thank you so much. You want to say goodbye?

[00:57:46] BO: I’d love to. Thank you so much for having me on. I love what you’re doing and we’ve been friends a while. So it was a treat for me to do this. I had fun.

[00:57:53] SY: And that’s the end of the episode. Let me know what you think. Tweet me at CodeNewbies or send me an email, hello@codenewbie.org. For more info on the podcast, check out www.codenewbie.org/podcast and join us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. Thanks for listening. See you next week.