Dear New Developer  ## Metadata - Author: [[The Changelog: Software Development, Open Source]] - Full Title: Dear New Developer - Category: #podcasts - URL: https://share.snipd.com/episode/6c71400a-c353-4882-9089-d411c5c29894 ## Document Notes ## Highlights - **Embracing New Opportunities** - Be excited about new projects and opportunities. - Don’t feel obligated to commit to something forever; projects can have a defined end. Transcript: Dan Moore They don't need to last forever. Sometimes you can hand them off to other people. I've tried to do that not with this blog, but with other situations. But there's nothing that says you need to commit to something for the rest of your life. I think things can have a start and an end. Jerod Sant I agree with you, but I find that very hard to execute on. Dan Moore I was sad. Right? When I wrote the thank you post, I was also happy. Right? I was like, you've been relieved. Yeah. But it is hard to do. And I've actually closed up some other projects recently, too. And I don't have any advice other than just being excited about the new space and the new projects that you can take on. And ([Time 0:07:03](https://share.snipd.com/snip/f9a299b4-75af-4db4-8826-08a30e8d1906)) - **Target Audience** - "Letters to a New Developer" focuses on succeeding in a developer job, not on acquiring one. - It targets those considering or new to software development up to 3-4 years in. Transcript: Nikita Shamganov When you think about new devs, are these people who are like in school, in a bootcamp, are they been working? Jerod Sant They've already landed that first job or they maybe been working for a couple of years, but still considering themselves juniors or is it the whole umbrella? Who do you actually think about when you're writing? Yeah. Dan Moore So I remember I went to a talk in the mid 2010s and someone asked the question about junior devs and the speaker said, I don't actually like that term. I feel it's a little bit like diminutive. And so that's why it's called letters to new developer instead of letters to a junior developer. And though I understand you can't swim upstream the entire time and that's what they're commonly called, right? People who are new in their career. But so what this blog and book is categorically not about is how to get a job because the last time I tried to get a job as a new dev, it was, you know, Bill Clinton was in ([Time 0:10:32](https://share.snipd.com/snip/c8f5ab1a-02c0-41a2-aa80-d64313b6a0cd)) - **Popular Posts and Impact** - Dan Moore discusses two popular blog posts: one about programmers struggling to program and another about improving code. - The latter emphasizes making small improvements, like writing tests or documenting. Transcript: Jerod Sant Well, let's dive into some of the content. I mean, surely you've had hits, things that have resonated more or less with people throughout the years, like people probably come to you and said, thanks Dan, this particular letter Helped me succeed in this way or that or get a raise or whatever, be more confident. What do you think are, if you're going to distill down, and maybe the book is a representation of this, because the blog was kind of like the source material for this book that you probably Distilled and maybe wrote some new stuff for as well. What's been your best advice that has resonated the most with people over the years? Dan Moore Yeah, I mean, I think the book is about, I started writing the book in 2020. And so I would say about half the content of the blog wasn't written when the book was written. So it's not totally the same. I mean, I think the stuff that resonated the most was probably, I'd probably pick two posts. One is the surprising number of programmers who can't program and how... Nikita Shamganov Intriguing. Dan Moore Yeah, and this was based on kind of a comment on Hacker News where someone was talking about the, what's that, the Fizzbuzz test, right, where you just have to ask someone to be able to... Maybe I don't know whether all your listeners know about this, but it's basically you write a program, you print the number if the number is not divisible by three or five. If it's divisible by three, you print Fizz. If it's divisible by five, you print Buzz. And if it's divisible by both, like 15, you print both. And there was a comment on how people were surprised that this would stop anybody. And the unfortunate thing is when you've had a career as long as I've had that sometimes people who may be well-meaning, good, nice people are in over their heads and can't really develop To save them, you know, code their way out of a paper bag. And how do you deal with those people is an important thing to do because you still have a job to do. You do not know how they ended up where they were. And you know, you'd have empathy for them, but still get your job done. ([Time 0:12:35](https://share.snipd.com/snip/0c89d4af-6d42-41e9-9669-a29334d56b07)) - **Finding a Sounding Board** - Having a sounding board, even another new developer, can provide valuable perspective. - This can help you assess your own skills and understand if issues stem from you or the codebase. Transcript: Nikita Shamganov I think that is empowering. When I was a relatively new dev, I inherited some code. Jerod Sant I inherited a project that I had a very hard time understanding what it was doing. And I thought for a long time that's because I just didn't have the capacity to understand like real code looks like and does. And it took me, it was the kind of thing where like it run and then I would have to like modify it slightly for somebody who asks and I wouldn't touch it, you know, very afraid to change it. Nikita Shamganov And like over the course of a couple of years with that same code base, not working on it constantly, but just like fulfilling requests, fixing bugs. I advanced to the point where I realized, oh, this is bad code. Like I didn't have, I didn't have the knowledge to realize the reason why I can't understand this is because this is a hot mess. Jerod Sant Cause now I've seen some code that's good, you know, like that's like well factored and thought through. And it wasn't me in this particular case, at least it was just like, this is a hot mess of code that I inherited and I had no context for that, no ability to even judge what was good or bad. Nikita Shamganov I just thought I was inadequate. That was kind of demoralizing. Been there, ([Time 0:15:42](https://share.snipd.com/snip/15196977-1ea3-4829-81d6-32a3d64457af)) - **Saying No Effectively** - Learn to say no to avoid overload, especially as businesses often exploit salaried employees. - Practice saying "yes, and..." to prioritize tasks and manage expectations effectively. Transcript: Jerod Sant Absolutely. What else would it be on your short list if you're going to expand that to like maybe five things, three to five of like things that every new dev should have? Dan Moore I mean, I think figuring out how to say no to things in a way that's not how do I put this crumudgingly is a good skill to have. I think that it's very easy to want to say yes over and over again and to the point where you get overloaded. And I think that the unfortunate thing about businesses is that they'll take as much as you can give, especially when you're a nice salary employee. So I always say learn how to say yes and which is basically saying, hey, if someone loads you up with tasks and you cannot possibly do them or you can't do them all, then you say, hey, I was Working on a you just asked me to do B and C. What's more important because I'm not going to be able to do a B and C and having that skill to do that in a way that is still seems being a team player, I think is a really, really important Non technical skill to have for any self-rebelver. Speaker 7 What's up ([Time 0:18:33](https://share.snipd.com/snip/b1fd8188-d062-4013-b66f-9b22b323125c)) - **Skill Stacking for Value** - Skill stacking is about combining proficiencies to increase value, not just accumulating skills. - Become valuable at the intersection of skills, competing with fewer people. Transcript: Adam Stacoviak Yeah, I was looking at some of the ones that you were just in your list basically cultivate the skill of undivided attention or deep work. It's like non real new developer application. It's just more like if you're a skilled person doing things. This other one is skill stacking, which. Nikita Shamganov Who is that like habit stacking? Yeah, it's probably like that. Adam Stacoviak You know, where you gain some level of proficiency in a given skill and you do that enough times that you have a larger skill because you have skill stacked. That's my assumption. I didn't read it. Dan Moore It's actually slightly different. I think it's more interesting. I mean, that actually is an interesting perspective. Skill staffing is basically I may be like a solid B developer, right? Like, you know, I guess for your worldwide audience. I may be like a, you know, a good developer and I may be a good speaker, but if I can buy those two things, I can be I'm finding a much smaller audience or finding a much smaller number of people Who are both speakers and coders. And so the idea is you stack skills and you have value at the intersection of those skills and you're fighting fewer people who have all those skills. So I say an email marketer and a and a coder and a front end person is doing me find a lot fewer people to get a job and you'll have a more valuable set of skills together. Oh, yeah. That also makes sense as opposed to trying to be the very, very, very best speaker or whatever. Yeah. You know, I'm not going to fight with Tony Robbins, but he can't talk about Ruby on rails. Jerod Sant So yeah, exactly. You won't ([Time 0:23:32](https://share.snipd.com/snip/11f1b0d6-3ae7-4f8d-9bbe-3541bc194226)) - **Initiating One-on-Ones** - New developers should proactively request one-on-one meetings with their managers. - Frame it as an opportunity to ensure alignment, leverage institutional knowledge, and address challenges. Transcript: Nikita Shamganov All good advice. All good advice. So another one you have on your list is how to ask for a one on one. Jerod Sant That's not something I've ever done. Can you tell us about that? Yeah. Dan Moore I mean, I think it's something that's so important when you're a new dev. Well, everybody in the world is the most important person to them, right? I think that is just a true thing. And yeah, what you have to realize is new dev is that your manager wants to help you unless you're dealing with a toxic manager, right? And I'm going to set that aside, right? Like let's assume you found someone who actually wants to help you, but they're busy. And so coming into first of all, asking for a one to one, which is for your listeners who might not be familiar with is just like a weekly. A weekly, biweekly regular meeting. And it's can be, you know, you could do it with 10 minutes. That's probably a little short in my mind. Shouldn't be an hour, like 30 minutes is kind of a sweet spot, but it's a regular check in. And you as the new dev should manage that. Like your manager will come with things, but you should think about what you want to communicate to your manager, what you want from your manager, how to communicate your challenges. And not just your challenges, but like what you've done to adjust those challenges. And you're building that relationship with your manager so that when tough times come or when they have new opportunities, they think of you, right? So you're opening up those communication lines. And the important thing is, again, not all new devs are right out of school, but when you're in school, you know, the curriculum is fed to you. When you're in school, the teacher has a responsibility to take care of you. And a manager is not the same as a teacher. And you need to be very aware of that. Actually, ([Time 0:34:28](https://share.snipd.com/snip/680b7fd3-7c46-4cd9-a300-c8e7c5ee706d)) - **No Adults in the Room** - Unlike teachers, managers don't always have all the answers in dynamic software companies. - New developers should recognize this "no adults in the room" reality and take responsibility. Transcript: Dan Moore One of my other popular posts is there are no adults in the room, which is was a little disturbing to me when I realized it. But I think I came out of school and I had the idea that like someone knew stuff, right? Like you walk into a business and people know how to know that they know how to solve these problems. And that may be true in a kind of a relatively static business with like a really good lineage. And all I can say is I never been in one of those companies. All the software companies I've been in. People are discovering new problems and solving new problems all the time. And that basically means you look you look around and like people may have more experience than you, but you're all the adults in the room and you all need to take responsibility towards ([Time 0:36:09](https://share.snipd.com/snip/810c85fa-2c50-4ecb-91a2-921382aac5da)) - **Purpose of One-on-Ones** - One-on-ones for new developers build crucial manager relationships and facilitate communication. - This allows for addressing challenges, showcasing problem-solving, and revealing long-term goals. Transcript: Dan Moore An intelligent way. Adam Stacoviak What is exactly the point of a one on one? So if you're not getting it, I assume maybe you have to be a bad manager or someone who's immature as a manager. Maybe they're growing up to get and they haven't learned. What is the point of a one on one? You know, what's the goal of it? Dan Moore As the, I don't know how to describe it, the person being judged, I don't know what the underling, the non-manager, how do you describe that person? So are you saying what's the point of the one on one for the manager or for the person? Period. Adam Stacoviak You know, what do they want from it? You know, if I'm a new dev, what do I want from a one on one? What's the point of it for me? Is it so I can showcase my skill set? I can showcase, you know, what my expectations are, have clarity. What is the point of it? Dan Moore Yeah, I mean, I think that the point of a one to one for a new dev is to build a relationship with the manager. And that could involve... It's a better not answer. Well, I mean, it could involve like sending, you know, giving some status. I mean, my favorite thing when I am with a one to one is where someone comes in with a problem that they're having that they've tried to solve and they want my perspective on. And that could be a technical problem. It could be a business problem. But building that relationship because when things get hard and especially in a remote world, right, where you don't have some of the sinew, like the social like connection that you Can get in an in person office, you need to build that. And so I think one on one's can help you do that from a manager perspective, big win is not being surprised by something that someone is expecting is planning. I actually had a guy, I was doing regular one to one's with one of my developers and he comes in and he's, we're going to have to launch and, but it was our one to one. He said, Dan, I really want to go to clown school. And I was like, oh, clown school. Speaker 6 That's interesting. Dan Moore And I tried to learn a little more about why he wanted to go to clown school. And I think that he just didn't want to be a developer. And that was okay. And he continued to be a developer for me for another year or so. But I knew that like his heart was someplace else. Speaker 6 And that was fine. Dan Moore But I've had, I would have been blindsided if I hadn't built this relationship where he felt comfortable telling me about this. ([Time 0:40:40](https://share.snipd.com/snip/79a7e6ba-3d2e-4dc1-8560-fb6876db9b8b)) - **Why Not Management?** - Dan Moore shares why he prefers not to be a manager, likening it to different sports with different skillsets. - He emphasizes the difficulty of giving feedback and handling ramifications like firing someone. Transcript: Nikita Shamganov So I'll buy it. Jerod Sant Why don't you ever want to be a manager again? Dan Moore Because being a manager is the same as being a developer the same way that being American football players is the same as being a soccer player. Like they're related and, you know, there's some commonalities, but it's a whole different skill set. And I've seen people who are good at that skill set and want to work on that craft of people management. And then I've seen people like me who would much rather be in the trenches doing coding or writing documentation or doing whatever. I've tried engineering management twice and both times because I had the opportunity to do so. And I thought, I'll take a swing at it. And now I know that that's not a skill I want to spend time honing. And by the way, that's OK. I want all your listeners to know that like you can be a developer for 20 or 30 years and still be a developer. There's a adjacent technology positions like product manager, you know, startup CTO, technology trainer, these are all things where being a developer is going to help you succeed, But you do not have to manage people to move ahead in your career. That's something I wish I'd known earlier. ([Time 0:46:30](https://share.snipd.com/snip/65317122-cb85-401a-8cd6-6db1c227e8f0)) - **Evaluating a Job** - Assess job benefits, including non-monetary ones like skill development and domain knowledge. - Interviewing elsewhere helps gain perspective and determine if issues are company-specific or personal. Transcript: Jerod Sant I think it's healthy to know yourself and to find that out about yourself and not necessarily, you know, push that particular stone up the hill. Nikita Shamganov If it's something that you realize, I don't want to invest in this. Jerod Sant I want to invest over here. I enjoy that work. I mean, like you said, it's totally healthy to do that. One of the things you've written on that's related is like learning when to leave. This is kind of when learning when not to take on a role is what you're saying. Like how to say no in that regard. You've written about learning when and how to leave. I assume that means a position or an organization. And we have, I think in our industry, a lot of leaving, a lot of movement, I think for some very good reasons and then probably sometimes when it's unfounded or you know, folly. And so I would love to hear some like reasons when it's good time to leave, knowing when versus maybe leaving it at a wrong time or for a wrong reason, which you got in that area. Sure. Dan Moore I mean, with the caveat that like everyone's situation is different, right? Like, you know, I think that you shouldn't leave when there's still, well, first of all, I think it's all a square smile to assess the greater economic climate. You need to assess where this job fits in your life. And I've never been one for like a 10 year plan or a 20 year plan. But I think you can know, hey, am I trying to earn money here? Am I trying to learn new skills? Am I trying to, you know, get access to a new domain? Right? Like I think that if you're back to the skill stacking conversation, skill stacking occurs when you know about a domain as well. Right? If I know advertising or no real estate, like the domain and I know software, I'm going to be more valuable than someone who just knows software and goes to try to get a job at an advertising Company or a real estate company. So you need to look at what you need to, what you're getting out of the job. I'm also a big fan of making lists and I'm also a big fan of kind of understanding that the grass is now, now it was greener and it really can look greener when you are frustrated with the Job. So when you're thinking about leaving, you want to assess kind of as best you can all of the benefits that you have in your current situation. And then it never hurts to go interview, it never has to have coffee with someone and have a conversation about like their company or their aspect. Going back to the kind of the pair of programming conversation we had where you were talking about, man, if I just had somebody else to talk about this code, I would have realized it wasn't Me. It was actually the code. If you go talk to somebody else at your company, outside your company, you may learn that it isn't you, it's the company or you may learn perversely that it's you, right? Like that you weren't taking advantage of things or that someone else has a perspective that, wow, you're really in a good spot compared to where I am. I feel like this is a bit of a rambly answer because it's hard to give specifics. But at the end of the day, I think you need to kind of assess where you are. And don't just think about the dollar figures because I definitely move because of dollar figures. Think about what other advantages and disadvantages are in your current situation. And I also realized this is something that took me a while. You are going to spend the first three or six months of any job building credibility and you will have options that are available with you at your current job. If you have credibility there, like you have a reputation of being a someone who can get stuff done, you'll have options at that current job that you wouldn't have moved to a new position. Nikita Shamganov I ([Time 0:50:07](https://share.snipd.com/snip/9b167bae-f8ab-4520-98d2-b262b030a84f)) - **Churn vs. Longevity** - Churn in tech creates knowledge transfer issues and hinders deep codebase understanding. - Staying longer allows you to confront and learn from past mistakes, fostering humility. Transcript: Jerod Sant Think that there is a view in our industry, which is opposite of what maybe some other industries or maybe just what it was like historically, where it used to be like, if you looked at Someone's resume, like let me see your job history and they couldn't have it. They had a job and it was like six months here, 18 months, 12 months. Nikita Shamganov You're like, OK, this problem, this person can't hold down a job. Jerod Sant And so maybe they're hard to work with or they're not a good fit. It doesn't look good, right? In tech, it's almost been the opposite. We're like, there's a stigma against staying at the same place. Nikita Shamganov And people think like they should move now because well, it's been two years. I've been here two years. Jerod Sant And I understand that a lot of times, I think this is structural. It's a lot easier to get a raise by finding a new job than it is to actually you know, get promoted internally. And so go get that money, people. I'm not against it by any means. But what about that stigma? Do you think that that's appropriate? Do you think that maybe we need to like break that sucker? Because what I see a lot of is churn and what churn creates is like knowledge transfer problems. Everybody's perpetually a new developer, at least on this particular code base. And it just seems like it's creating more problems than it's solving. Nikita Shamganov And yet people have this feeling of like, I've been here for two years. Am I stagnant? Dan Moore Yeah. So there's a couple of things I want to put these power without the first is I think that absolutely depends on the section of the tech industry you're in, right? There are definitely companies out there that or organizations I can think of where people stay for decades. And it's a tech industry. They're still doing tech, but it's not. There's no stigma. The second thing I would think of is I think it's incumbent on companies, right? And I don't know why companies do that, why they will find 10 or 20% increase for someone who's coming in, but they can't find that for a raise. Right. For someone who might be able to do that same thing. And maybe I should say I do know because the employee who's already in the company has fewer options and doesn't have. Leverage. Yeah, exactly. So, but I still think it's a dumb thing for a company to do because they are promoting this churn culture. Jerod Sant Yeah. And which hurts them, right? I mean, every time they have to onboard somebody new. Totally. You do. Geneficiency is right. Dan Moore And plus you also get like, frankly, every time someone walks out the door, you lose a ton of human capital and you lose kind of cohesiveness. So I think to your point, go get that money, but also realize that again, I talked a little bit about credibility. I think I have done the thing where I moved companies and it was mostly when I was independent contracting, you get a lot of breadth, but not a depth, as I mentioned, but like sticking to A certain place for a while is going to give you just a deeper appreciation, a deeper understanding. And frankly, when you have to confront your mistakes that you made three or four years ago and you see them in your code base and you see them and get blamed, that the you were the person Who made that mistake, it's going to be a learning lesson in a way that thinking about somebody else's mistakes is just not going to be. So companies, please think about giving people retention pay raises that are significant because I don't know how you solve that problem without adjusting the money portion of it. ([Time 0:53:34](https://share.snipd.com/snip/37dc4976-d8c8-443d-973a-443805dd6320)) - **Essential Tools and Inclusion** - Learn your foundational software development tools well, like debuggers, version control, and text editors. - The tech industry needs diverse developers, so don't be discouraged from joining. Transcript: Jerod Sant Well, Dan, is there anything in particular we could talk about the, the creation of the book, you know, we could talk about that, but in terms of the content and the, and the message that You're trying to get out there to folks, is there any other one that you were hoping we talk about or that you talk about often, or you think you're like, you know, tent poles, what do they Call those things, tent pole features, holding up the tent? Speaker 6 Um, I mean, it's the two that I would leave you with, right? Dan Moore If, if this was, if you said, Dan, you know, give out two other messages and that's all you get. The first would be kind of learn your tools because tools that you use to create software, whether that's a debugger or version control or text editor, those are things similar to communication You mentioned, where it's kind of across different jobs. You know, I'm a VIM user and I use that like day in day out and that is applicable across a bunch of different languages. SQL is another one version control. So learn kind of some basic foundational tools and try to learn them well. And the second thing I would say is we need you. We need all kinds of new devs. There's so much software rewritten, even with kind of the magic of, of generative LLMs, like we still need different perspectives. So many problems need to be solved that I welcome anybody to become a developer. I, I, I'm not a fan of gatekeeping. That doesn't mean that everybody's opinions were at the same value, right? Like if I was playing basketball and you asked my opinion and you asked the bronze James's opinion, like you wouldn't value them equally and you shouldn't. But that doesn't mean that both of us wouldn't have some value to bring on the basketball court. Even if my value is just passed until LeBron James and let him do his job, I still have some value. So I would just say everybody who's thinking about it being a developer, you're welcome. It's a fantastic large field and you can be successful in it. ([Time 0:58:35](https://share.snipd.com/snip/cdaf8ca6-778d-4f23-a4e8-87229d66cb9b))