The Changelog: Software Development, Open Source - Dear new developer (Interview)

Episode Date: January 4, 2024

Hello 2024! We're kicking off the year with Dan Moore, author of ‘Letters to a New Developer’ — a blog series of letters of what Dan wished he had known when starting his developer career. We discuss the value of online communities for new developers, the importance of communication skills, and the need to stay relevant in a rapidly changing industry. Dan shares his best advice for new developers, including the importance of saying no, leaving code better than you found it, and the value of skill stacking. So much wisdom and advice in this episode!

Okay, 2024, we are here and this week on The Change, we're joined by Dan Moore, author of Letters to a New Developer. This is a blog series of letters of what Dan wished he had known when he started his developer career. We discuss the value of online communities for new developers, the importance of communication skills, and the need to stay relevant in a rapidly changing market. Dan also shares his best advice for new developers, including the importance of saying no, leaving code better than you found it, and the value of skill stacking. There is so much wisdom and advice in this episode kicking off for 2024. A massive thank you to our friends at fly.io,

the home of changelog.com. Launch your apps near your users. They transform containers into micro VMs that run in 30 plus regions on six continents. Check them out at fly.io. What's up, friends? I'm here with one of our good friends, Faras Aboukdij. Faras is the founder and CEO of Socket. You can find them at socket.dev.

Secure your supply chain, ship with confidence. But Firas, I have a question for you. What's the problem? What security concerns do developers face when consuming open source dependencies? What does Socket do to solve these problems? So the problem that Socket solves is when a developer is choosing a package, there's so much potential information they could look at, right? I mean, at the end of the day, they're trying to get a job done, right? There's a feature they want to implement, they want to solve a problem. So they go and find a package that looks like it might be a promising solution. Maybe they check to see that it has an open source license, that it has good docs. Maybe they check the number of downloads or GitHub stars. But most developers don't really go beyond that. And if you think about what it means to use a good package, to use a good open source dependency,

we care about a lot of other things too, right? We care about who is the maintainer? Is this thing well-maintained? From a security perspective, we care about, does this thing have known vulnerabilities? Does it do weird things? Maybe it takes your environment variables and it sends them off to the network, meaning it's going to take your API keys, your tokens, like that would be bad. The unfortunate thing is that today, most developers who are choosing packages and going about their day, they're not looking for that type of stuff. It's not really reasonable to expect a developer to go and open up every single one of their dependencies and read every line of code, not to mention that the average NPM package has 79 additional dependencies that it brings in. So you're talking about just, you know,

thousands and thousands of lines of code. And so we do that work for the developer. So we go out, we fully analyze every piece of their dependencies, you know, every one of those lines of code, and we look for strange things, we look for those risks that they're not going to have time to look for. So we'll find, you know, we detect all kinds of attacks and kinds of malware and vulnerabilities and those dependencies. And we bring them to the developer and help them when they're at that moment of choosing a package. Okay, that's good. So what's the install process? What's the getting started? Socket's super easy to get started with. So we're, you know, our whole team is made up of developers. And so it's super developer friendly. We got tired of using security tools that send a ton of alerts and were hard to configure

and just kind of noisy. And so we built Socket to fix all those problems. So we have all the typical integrations you'd expect, a CLI, a GitHub app, an API, all that good stuff. But most of our users use Socket through the GitHub app. And it's a really fast install. A couple clicks, you get it going, and it monitors all your pull requests. And you can get an accurate and kind of in depth

analysis of all your dependencies, really high signal to noise, you know, it doesn't just cover vulnerabilities, it's actually about the full picture of dependency risk and quality, right? So we help you make better decisions about dependencies that you're using directly in the pull request workflow directly, directly where you're spending your time as a developer. Whether you're managing a small project or a large application with thousands of dependencies, Socket has you covered. And it's pretty simple to use. It's really not a complicated tool. Very cool.

The next step is to go to socket.dev, install the GitHub app, or book a demo. Either works for us. Again, socket.dev. That's S O C K E T. Dot dev. so we are here with dan moore from letters to a new developer thanks to our community member and longtime listener jamie tana for requesting this episode thanks jamie i had not come across dan's blog but now i have and i immediately was like oh yeah let's do this let's get dan on the show so here he is dan thanks for coming on man hey thanks so much for having me and thank you jamie yeah thanks jamie thanks for being here so

letters to a new developer no longer active so we're late to the game. You know, you've, you've retired or you've, I don't know what you'd like to call it. You finished this blog, but a long one. Tell us about it. Yeah. So in about 2011, 2012, I wrote a ebook about a technology that maybe all I've heard of called Cordova and spent a lot of time on about a 50 page ebook, had a lot of fun, sold some copies. And then immediately the company I was working at stopped using that technology. And so I was kind of burnt and I waited for a couple of years and I said to myself, I'll probably never do a book again, but if I do a book again, I'm going to do something that's evergreen.

And then I started working for a consulting company in 2018 and started to get the bug to write a book and immediately said, well, what would be helpful to me? And at a consulting company, you deal with a lot of new devs. Sometimes you bring people in. Sometimes you just talk to people. You're recruiting folks. And so I thought, well, I've been a developer. at that point. I'd been a developer for almost 20 years. What could I tell people that would be helpful to me? It would have been helpful to me when I was starting out. And I also thought, there's no way in heck I'm going to write a book. I'm just going to start a blog and see whether I have any kind of gas in the tank, whether I have interesting things for people to read. And so

I started this blog in September 2018. And as you alluded to, I finished it up in September 2023. And the reason for that is that my life has changed. I don't interact with new devs in the same way I used to. My career has shifted a little bit. And frankly, I think that it's good for projects to end, right? 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. I agree with you, but I find that very hard to execute on. I was sad, right sad, right? Like when I, when I wrote the thank you post, I was, I was also happy, right? Like at the same time, I was like a little bit relieved.

Yeah. Yeah. But, um, it is, it is hard to do. And I've actually closed up some other projects recently too. And I don't, 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 that's kind of the thing I think about. Like I focus on, oh, I have this other thing

I really want to do. And this new letters to developer has helped a lot of people. And I'm committing to keeping it up for years, but I don't think it's right for me to be adding to it anymore. What was some of the process to add to it? How did you bring on new writers? Was it all written by you? Probably not.

Letters to developers probably seems like it's contributor driven in some way. How did you do that? Yeah. So when I originally started out, I was writing weekly and I was writing some short form pieces that were entirely there. And I was also writing some kind of riffs, right? Kind of taking it back to the original 2000 blogs where everyone was like, excerpting people, other folks. And then pretty quickly, I realized that I have a certain perspective. And obviously, I think my perspective is valuable. Otherwise, I wouldn't have started the project up, but that other people had way different perspectives that were useful, too. And so I I think in the first year, I maybe had one or two folks I asked. And I started out asking people that I knew. I started out asking people

that I was familiar with that were in different situations, right? I can think of one person in particular who had worked for like a gigantic software company. And I've never done that. And he wrote a great post about how to interact with people at job fairs. And I've never done that. And he wrote a great post about how to interact with people at job fairs. And I've never been to a job fair in my life because all my jobs have been at smaller companies where you do the interview cycle or something like that. They're never going to send someone to a job fair. But he had experience on both sides of the job fair table, as it were, the actual real table. And so he wrote a great post about that. After a while, after I kind of had some, a number of people who'd shared it and I'd done some self-promotion, I started to get a little more traffic. I actually started to reach out to people that I didn't know, but that I admired, right? I think Jamie actually has written one, your community member and my community member. And I remember, I think I reached out to him and I would start out and it depends on the person. Some people I asked, I basically asked them, Hey, I'd love for you to write for my blog. Here's kind of the audience. Here's the size,

here's topics that are good. And some folks were willing to write new content. Some people were just willing to like, let me cross post content. And I was happy either way, because the whole point was to expose basically my audience of new devs to a new source of wisdom. And then also, frankly, to lift up some people, right? And be like, Hey, not that I have a huge platform, right? But it was definitely something. And I wanted to, there were people in particular, I can think of who I felt they had a good message and I wanted to just promulgate it further. So when you think about new devs, are these people who are in school, in a boot camp, or they've already landed that first job, or they've maybe been working for a couple

of years but still consider themselves juniors? Or is it the whole umbrella? Who do you actually think about when you're writing? Yeah. 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. Even 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 office.

And so, you know, or maybe George W. Bush, depending on how you slice that. But certainly things have changed since then, right? So what it is really about is how to help people succeed when they have a job and attributes that will help them when they have a job. So it is that kind of from someone who's thinking about software development as a possible career, right? And curious about like what that looks like, not from a technical perspective, but from like a day-to-day perspective, or how do I succeed? Or what are attributes that can help me as a software developer? All the way up to, I'd say someone even three to four years in their career. And then the other kind of audience, and I've definitely had people buy the book or pass off articles, is the mentor, right? Who is looking for something that maybe is a little bit,

something they can share with a mentee. And again, also provide a different perspective, because mentors are great at talking to mentees, but they are bringing their own perspective. And this site and book can help you provide a different lens towards some problems. 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. 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? 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. But yeah, 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, you know, how intriguing. Yeah.

And, 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. And so there was that post. The other I would say is always leave the code better than you found it was another one that got some really good feedback. And that was just really a question of, you know, as a dev, when you especially when you approach a new project, it can feel like, how do I put this politely, sometimes when you walk into a

new project, it feels like there's everything's on fire. And that can be really disheartening and frustrating, especially when you're new dev and you're just trying to get your head around software development in general. But just like you can always leave a park or physical location or a house or a room in your house better than you found it. But just by doing a little thing, you can help improve the overall health of a project by just doing small things, right? Like just writing one test, just documenting one thing, just making one diagram, just asking one question. And I think that felt empowering to new devs. Yeah, I think that is empowering. When I was a relatively new dev, I inherited some code.

I inherited a project that I had a very hard time understanding what it was doing. And I thought for a long time that it's because I just didn't have the capacity to understand what 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 asked and I wouldn't touch it, you know, very afraid to change it. 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. I didn't have the knowledge to realize the reason why I can't understand this is because this is a hot mess. Because now I've seen some code that's good, that's 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 yeah what was good or bad i just thought i was inadequate and that was kind of demoralizing been there man until i realized it then i was like yeah have you more on the front end stuff like just weird things happening in rails this one application i was working on for

i won't name the company i was a contractor and it was just like front end forms coming from different places and just it was just really the front end was, this is also the era of bad front end anyways. Like it was still maturing. And I think it's still kind of almost bad. It's getting better, of course. But the iteration to now is much better than it was 10 years ago. And it was just maybe bad ways then. I don't know.

It was just hard to follow everything. I feel like every time I touched it, I broke it. I couldn't really do a lot of stuff in it. The CSS was mangled and this is before BEM and any other thing that you could even do to apply components to a site, a page or whatever. It's tough. I think that's a real advertisement for finding a mentor or having a pair with somebody who's more experienced.

Because all it would have taken is somebody else to look at that code and say, no, man, this is terrible. Like, I understand why you can't understand it. And my light bulb would have went on immediately. Instead, it took a very long time to realize. I mean, to me, this is, it's hard to pick just one thing that I would want for every new developer, but like one thing would be a, just someone to a sounding board. Right. And it could be,

honestly, it could be another newer dev. It could be someone who's slightly ahead of you, but like, my guess is that if you'd had another dev that you could like point to and be like, Hey, is this,

is this offer? Is this me? You know, and you know, maybe you make it more polite than that, but like that different, is this, is this offer? Is this me? You know, and you know, maybe you make it more polite than that, but like that different perspective is just going to help you so much. And it'll just accelerate things for you. Absolutely. What else would you be on your short list? If you're like going to expand that to like maybe five things, you know, three to five of like things that every new dev should have.

I mean, I think figuring out how to say no to things in a way that's not, how do I put this curmudgeonly, is a good skill to have because 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 salaried 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've 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 seen as being a team player, I think is a really, really important non-technical skill to have for any software developer. What's up friends?

This episode is brought to you by our friends at Neon, on-demand scalability, bottomless storage, and database branching. And I'm here with Nikita Shamganov, co-founder and CEO of Neon. So Nikita, imagine you are a tour guide. Give me a tour to the world of Neon. So let's look at a modern developer. As people say, never bet against JavaScript. So more than 50% probability

this person is writing JavaScript and TypeScript. Using React, Next.js, deploying their code on a platform like Vercel, and really care about design. So working with Figma, working with a local designer, or maybe starting to work with an AI designer and using technology like Vercel just shipped called vZero. And then you got to store data somewhere. So you go to Neon or use Vercel Postgres, which is powered by Neon. You push a button and now you're able to write and read from Neon. And then that kind of just works out of the box. The majority of your time you spend crafting

your application, crafting the front end. And then the database is just kind of like, it's just kind of there, and just kind of works. And you don't think too much about it. And when you run previews, when you run next versions of your software, you can send your collaborators, your other engineers on your team, or your product managers or designers, a version of your app, the version of the future that you want to debate if you want to comment on. And it's fully sandboxed, you know, from your front end to back end to the database. That's like a good part of this world. The world is obviously much bigger than just building front end apps. There's also back end apps, there are Python apps, there are Java apps, and all of those things. We're perfecting the world for the world that I just described. And we think that

the rest of the world will follow. And the rest of the world is Java apps, REST apps, backend apps, queues, scheduling, AWS, Lambda, Kubernetes, containers. Again, the tech world of the backend is just enormous. But I think perfecting this first world that I described will create a standard in developer experience that the rest of the developer world will just follow. So you have Vercel, Postgres, Powered by Neon. You've got Neon as an integration to Vercel. You've got Neon out there at neon.tech as self-serve where anybody could just go and sign up and start up right now. You're optimizing for this new standard, but what's the response been like? What's the community saying? What's the community's response? We are lately onboarding close to 2,500 databases a day. That's more than one database a minute of somebody in the world

commenting in either directly or through the help of our partners. And they're able to experience what it feels like to program against database that looks like a URL and that program against database that can support branching and be like a good buddy for you in the software development lifecycle. So that's exciting. And while that's exciting, the urgency at Neon is currently is unparalleled. There you go. If you want to experience the future, go to neon.tech, on-demand scalability, bottomless storage, database branching, everything you want for the Postgres of the future. Once again, neon.tech. it's like life skills almost yeah i was looking at some of the the ones that you were just in your list basically cultivate the skill of undivided attention or deep work that'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... Ooh, is that like habit stacking? Yeah, it's probably like that. Probably. You know, where you gain some level of proficiency in a given skill and you do that enough times, now you have a larger skill because you have skill stacked.

That's my assumption. I didn't read it. It's actually slightly different. I think it's a more interesting. I mean, I mean, that actually is an interesting perspective. Um, skill staffing is basically, I may be, uh, like a solid B developer, right? Like, you know, I guess for your, uh, for your worldwide audience, I may be like a good developer and I may be a good speaker, but if I combine 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 be an email marketer and a and a coder and a front-end person is you're going to be fighting 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 tonybins, but he can't talk about Ruby on Rails.

Yeah, exactly. He won't get that. Sit at the intersection of multiple things and you become kind of like, you just become more valuable as you multiply those things together, basically. Yeah. I mean, I think, Adam, what you're talking about is stacking skills over time and the value of being in a place. And that's

actually an interesting thing I've found, because I've spent my career like half between consulting where you get to move between different projects and you get like you're spread wide, but your understanding is like thin in some things. And then other times in products. And I think there's value in both kinds of experience, but your kind of skill stacking,

I think was much more like you're in a product or you're in an area and then you just keep adding your expertise and maybe you move a little bit to the side, but you get more. Was that what you were kind of referring to or did I misunderstand? Basically, that was my assumption, but I incorrectly assumed what your post is about. So I'll just eat my feet right now. But basically, I found this in my career. I can apply my ability to be a people person, my ability to be not really afraid of confrontation. And I don't mean like fighting somebody. I mean like hard situations. I don't find myself that.

I mean, I'm nervous in the moment. There's still nerves involved, but I don't find myself avoiding it because I have fear. And then I find myself with certain skills to help people. And when you combine certain things like that over time, these are all non-programmer skills, but now I can apply it to our business here, which is very programmer driven or focused on software developers to help our company thrive. I've taken skills that I've stacked over, you know, my whole career, basically, you know, how to write well, how to communicate well, all these things stack up to make me a better individual for my team, you know? So that's, that's kind of what I was doing,

skill stacking, but yeah. I mean, honestly, I think that's true of probably any profession, right? Like, I think that like, if you're a carpenter or a plumber or a lawyer and you have all these other skills about dealing with conflict and being a communicator, you can almost swap out that inner skill and you'll still be better at X, whatever X is, if you're a better communicator or maybe more valuable is a better way to put it more flexible what i've realized over the years i didn't realize this as a young person is like how communication is like the i want to call the trump card just because that word has been sullied in the minds but it's it's a cross referential like it's like just the best skill that helps in like every niche, every area of the stack, every business. And like, if you add that to whatever you're doing, you are ahead of the game or you're ahead of where you were for sure. Like that's a skill you want to stack and it moves with you. So in software, one of our problems is we invest in skills that become irrelevant. And that's a real challenge. I mean, it's not something to take in lightly. And it's a difficult thing is like to see what's coming next and to be at least well versed in it,

if not competent, if not excellent at it, and not wasting a bunch of time on something that's going to go away. Like your Cordova book that you wrote and your company decided no more Cordova, you know, that's kind of just like a sunk cost at that point, unless you're going to take your skills elsewhere. And that's been a real challenge. And one of the reasons why we exist even, and why I got involved in the change log back in the day was like just trying to stay relevant, know what's going on, keep up with the trends. Do you have advice for new developers on that front? Like how to invest in things that are going to last or how to float above that area where you can become like, I spent six years becoming the best jQuery developer in the world. And now everybody wants React. I mean, this is even that's a dated reference. But you know, like that, that happened. It's happened to all of us. And you've lasted a long time in this industry, Dan. Totally. Yeah, advice for that. Well, so first, I'd like to say, I do remember that early in my career, I remember realizing

that writing software was much more about people than it is about code. And being like, because I came out of school and I thought, oh yeah, it's all about getting the proverbial, go in the corner, write your code. But almost all pieces of software have users who need to have their needs met and no one really writes software except for four people, right? Like whether you're doing it for money or for open source for fun, like, you know, so I would just kind of set that to the side. But when you start talking, that was something that I just want to say, like, I actually, I think you have even a blog post about that where it's like software is for people, not for, not for code as far as kind of staying

current. You know, I think that there's for code. As far as kind of staying current, you know, I think that there's a couple of ways you can kind of hack this, right? Like the first is, you know, you kind of mentioned jQuery. You know, there's still a ton of sites out there. You can probably get a job writing jQuery, right? So you need to think about like what you want out of software development. Do you want to make the investment

to stay kind of on the front lines or to stay, you know, 10% behind the people who are kind of pushing things forward or to be someone who's helping companies that frankly, you know, might not be doing a thriving job market, but it definitely is something you can make some money in. If you decide you want to be at the tip of the spear or 10% or 20% behind it, I think you really just have to prepare to spend some of your own time. You can, depending on where you are in your career, try to pick companies that, you know, allow you some time within the corporate structure to, to do some R and D or some education. But I think that especially if you don't, it's always tough to give, you know, tell people to spend time out of work, right. Because

we all have other constraints, but even just reading something, right. And even just like having kind of a high level understanding like when i um i took a class about aws or i yeah i took a certification and the value of certification is not necessarily knowing how to do everything the value of certification is actually knowing that something exists so if you're part of a community if you subscribe to some newsletters and all you do is like say, oh, that React thing is going to be a big deal, or not even a big deal, but maybe that's something interesting, and you know about it, and you know kind of where it fits in, right? You're not

suggesting people use React for server-side database interactions. Then when something comes up, you can say, oh, there's a new front end thing. Have we evaluated React? Right. And this is, again, this is not a conversation you have now. It's a conversation you have five years ago. But you need to be kind of aware of, at least aware of it. Does that make sense? I don't know.

What do you guys, what are your suggestions? I think so. Yeah. Adam? I like what you were saying about being behind people like this idea that you know there's this i suppose it's life in general but this idea to keep up right and as a developer especially yeah exactly like the joneses whether it's skilled or or materials you know this idea to keep up essentially and we said that early on too with our tagline like open source moves fast

keep up and it was meant to be kind of snarky because it was kind of hard to keep up and i think we end up especially as new devs you end up like chasing different you know squirrels and shiny objects and you're not really which skills to build and you're three years deep and you've got a smorgasbord of like maybe mediocre skills no offense to the people who have done that but like just because you're chasing things but this idea of like staying 10 behind the people that are innovating and pushing forward you know kind of maybe staying in the jquery lane maybe you're not shouldn't do that maybe that's probably not good advice today but just the idea of staying what's like a little bit behind the trend line so to speak so that you have a maybe some margin some space some operational

space to maneuver, whereas somebody who's sort of steeped deep in something that's basically dead or dying, and they've invested fully, well, they're all in on the wrong thing, basically, and you still have a chance to sort of diversify. I mean, I definitely have seen plenty of cycles of like the new thing comes out, and the consultants all rush in, and they all write the books, and doing like the hello worlds and like the, the kind of the base layer. And you can make a lot of money as long as you're a consultant and you're kind of doing this and you're getting up to speed quickly,

but then you have to go find that new, new thing, right? Like the people who are making boatloads of money as AWS consultants five years ago, can't be doing that now. Now they have to specialize or do a different cloud or something like that. And that can get exhausting. I think to your point, like if you stay 10% behind or 20% behind, you can see where the consultants have gone and then you can see where the company's invested too. right? And then you can kind of be like, oh, you know, now it's time for me to make this switch, but you, and you won't make as much money

as the consultants, right? And you won't have the fame or you won't be able to write like the easy blog posts, but you'll be able to read those blog posts and you'll be able to get up to speed quicker. And you'll know that like people have made a more substantial investment in them. By people, I mean companies or people willing to pay you money.

All good advice. All good advice. So another one you have on your list is how to ask for a one-on-one. That's not something I've ever done. Can you tell us about that? Yeah. I mean, I think this is 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 what you have to realize as a 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 it, is just like a weekly, biweekly, regular meeting. And it 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 the 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 address 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, 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, one of my other popular posts is there are no adults in the room, which was a little disturbing to me when I realized it. But I think I came out of school and I had the idea that someone knew stuff. Right. 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've 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 solving those problems i had that one pulled up actually i was i thought it's kind of interesting to think that there's no adults in the room and uh you know it's kind of perspective taking which you've said here in the post you said there's two ways to look at it in this in this angle of basically no one knows their doc what they're doing because everyone's sort of learning the business domain and they're doing the best they can etc and you pose it as this you say problem oh my gosh no one knows what they're doing what kind of place is this that's one thought or the other which is uh opportunity excellent i can see that folks are gromping towards solving problems i can see i can uh put some help into the place.

Let's put my nose to the grindstone and see how I can help, essentially. And that's essentially perspective taking, which is you can either be negative or positive about a situation. Like, hey, sure, no adults, not meaning that there's literally no adults, but people who are still grappling with what's going on, how it works and doing the best they can. And you can either find opportunity in that or get upset and leave or just show up and don't give your best or, and don't progress even as well. There's a Steve Jobs quote that is in the same realm. He was speaking about invention, I think, but his sentiment here, it is Steve Jobs said everything around you that you call life was made up by people that were no smarter than you. And you can change it. You can influence it. You

can build your own things that other people can use. And there's an empowerment to realizing that like all the, the rules of this business or like the way we do things and like all that stuff was just made up by somebody else who isn't necessarily smarter than you. They were just there when the thing needed to be made up and maybe it was well reasoned and that's exactly how we should do it. And so let's, well, let's question that and then validate. And if it is, we'll just keep doing it that way. But maybe it had other constraints at the time that no longer exist. And we're fools to just continue to do this thing that no longer is applicable, but we do it because the previous people did it. That's kind of that no adults in the room is like,

we're all on the same level here. We can just question this stuff. And maybe it was a really good answer, but maybe there's not. And when there isn't, there's a huge opportunity for improvement. So I love that. Yeah. Going back to the one-on-ones, Dan, how do you, you said it's like, I think that's a really powerful thing. And it seems like something that most of the time the manager would institute, like the one-on-ones. And you said the advice is like how to ask for one-on-ones. So as a new dev, how do you actually, because it's probably intimidating to ask for that

or you feel like you're, like, how do you advise people to actually get that thing going? Yeah, I mean, I think, first of all, you can send them the link to my article. Um, I mean, I mean, I think that what you need to do is put yourself in your manager's shoes, right? And your manager is going to succeed when their team succeeds. And again, I'm, I'm setting aside the toxic empire building manager. And so what you want to do is you want to frame it as, Hey, I want to have some time, some of your time to make sure that I'm addressing things that you want, that I'm, I'm

blocking myself in the best way I can, that I'm taking advantage of your institutional knowledge. And if you can't, I think asking for a week, like 30 minutes a week, that might be a non-starter for some folks. Like I know some folks manage like 30 people, which to me is, I can't imagine how you do that effectively, but it's possible. So start small, like talk, ask, ask for that first meeting and say, Hey, you know, I just really liked to like, after that first month or that first couple of weeks be like, Hey, I just want to make sure we're on the same page. And then say, can we make this a regular thing and ask for it? The managers that I've dealt with that were good managers wanted to help me succeed. And so you just need to think about knowing enough about what they need to succeed to ask them in an intelligent way. What is exactly the point of

a one-on-one? So if you're not getting it, I assume maybe you have maybe a bad manager or someone who's immature as a manager. Maybe they're growing still yet and they haven't learned. What is the point of a one-on-one? What's the goal of it? As the, I don't know how to describe it, the person being judged, I don't know,

with the underling, the non-manager. How do you describe that person? So are you saying what's the point of the one-to-one for the manager or for the person? Period. 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, so I can showcase, you know, what my expectations are, have clarity? What is the point of it? Yeah, I mean, I think that the point of the one-to-one for a new dev is to build a relationship with the manager. are, have clarity. What is the point of it? 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, 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 to me 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 connection that you can get in an in-person office, you need to build that. And so I think one-to-ones can help you do that. From a manager perspective, a big win is not being surprised by something that someone

is planning. I actually had a guy, I was doing regular one-to-ones with one of my developers and he comes in and we're going out to lunch, 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. That's interesting. 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. And that was fine. But I've had, I would have been blindsided if I hadn't built this relationship where he felt comfortable telling me about this. And that's something that comes out of one-on-one purely from a manager's perspective. What's up, friends? This episode is brought to you by our friends at Sentry. Check them out at Sentry.io. S-E-N-T-R-Y.io.

Code breaks. Fix it faster with Sentry. Don't just observe. Take action. The only app monitoring platform out there built for developers that gets to the root cause for every issue. 90,000 plus growing teams use Sentry to find their problems fast. GitHub, Disney, VMware, Airtable, Autodesk, monday.com, Miro, Tunnel. I could just go on literally 90,000 plus teams trust Sentry to fix their problems fast.

But how they do that, they have error monitoring, session replay, performance monitoring, code coverage, all the things it takes to make an application run well in production, Sentry has got you covered. Again, check them out at Sentry.io. That's S-E-N-T-R-Y.io. And make sure you use our coupon code change log to get $100 for your error monitoring with century.

Once again, S E N T R Y dot IO century dot IO. I'm glad you responded with that because relationship is so important in that scenario. So, I mean, I get that part. I thought, well, how am I doing? What's my performance like? Can I make sure you know how I'm performing? And here it's just like basically the relationship, which is super crucial to any sort of scenario where you have a management to a manager scenario where you've got to be managed. You're part of a team.

There's expectation but you can't really advance and they can't help you advance unless they understand who you are and have a relationship with you. And I've been in places where it's like I didn't know I guess now that I think about it now that i'm hearing this advice from you I'm thinking maybe that's why I left because I was like well i'm not Really seeing how i'm advancing here. I don't really have awareness of what i'm doing right or wrong And i'm just like there's just no feedback loop. So there's something missing. I'm not sure what it is as a new person essentially

So i've got to I got to take my skills elsewhere. I've got to take my opportunity elsewhere and I just bail basically if you're not getting that kind of feedback loop and there's no relationship what's the point of staying around I mean at the end of the day there's this old chestnut people don't leave jobs they leave managers and people have left I mean I'm not the perfect manager

and I can talk a little bit more why I never want to be a manager again if you all want to hear that but like people can leave people can how do I put this play? Like I'm okay with someone not wanting to be managed by me as long as they know me. But like, to your point, Adam, like if you don't even put the effort as a manager and as a new developer to like build that relationship, you're gonna have a really hard time. You don't even know whether or not it might have been the right position for you because you'll get frustrated or burnt out or you

won't have that feedback that you need to improve. So I'll buy it. Why don't you ever want to be a manager again? Because being a manager is the same as being a developer, the same way that being an American football player 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 skillset. And I've seen people who are good at that skillset 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 okay. I want all your listeners to know that you can be a developer for 20 or 30 years and still be a developer. There's 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. What's the problem with managing people, I guess, that for you, what is it that you don't like about it in particular?

Is it just the necessary people skills? What is it that, you know, give me a specific for it, just to be clear. Yeah, I think it's all fun when everyone's doing well. And then when someone's not doing well, you need to course correct and give expectations. I mean, to the point of having to fire someone or lay someone off. And that's just something that I'm not sure I will. Well, that's one example of something that a task that I find unpleasant. And I think most managers find it unpleasant, right?

Like it's never fun to do that. But I think some people are better at giving feedback and dealing with the ramifications of having to fire someone than other people are. It makes me think of that movie Up in the Air. Have you seen that one, Adam? George Clooney goes around, and his entire job is to lay people off. And it's so unpleasant that they bring in an outside consultant,

which is the nastiest way you could possibly do a layoff, right? And he's the only person in history, of course, he's a fictional character, but he's the only person I've ever seen who takes somewhat of pleasure in the act of axing people because nobody likes to do that i've seen the movie i need to go re-watch it now that you uh mentioned it because it's been a while that i forget the premise yeah you almost ruined the plot for me oh i'm sorry almost well that's the that's not a ruin that just is the plot well isn't julie roberts in it too or like some other

female cast i don't remember. There's definitely some females. He's a kind of a ladies man. The thing that's different about it, I think it's like pre 9-11 even. So like, for sure. He loves to fly.

He's like the most frequent flyer. But, and it makes, it kind of glorifies flight, which I think is like a crime against humanity because you can't glorify flight. It's like one of the worst things we do. But back then it was like enjoyable and he had all like the special ego and all the special places and et cetera. Because you can't glorify flight. It's like one of the worst things we do. But back then it was like enjoyable.

And he had all like the special ego and all the special places and et cetera. And he didn't have to take his shoes off and his belt and everything. But anyways, I digress. But I do want to say one other thing. Like another aspect that I find tough that I think other people enjoy when you're a manager is you have to take joy in your team members' successes. And I don't know, of of course I like to see team members succeed, but like that becomes your whole thing, right? You're not doing the work anymore. You're enabling other people to do the work. And again, I think that's a skill you can gain. I think it's a

good skill to have some aspect of, but I think that real EMs, the real successful engineering managers I've, I've dealt with my life, like just love to build the team and bring the people together to do the thing. And I just tend to like to do the thing. Well, 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. If it's something that you realize, I don't want to invest in this, 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 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 at a wrong time or for a wrong reason, what you got in that area. Sure. 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 worthwhile 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 get access to a new domain? I think that if you're back to the skill stacking conversation, skill stacking occurs when you know about a domain as well. If I know advertising or I know 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 not always 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 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 hurts to have coffee with someone and have a conversation about their company or their aspect. Going back to the kind of the pair 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 aren'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 rambling 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 moved because of dollar figures. Think about what other advantages and disadvantages are in your current situation.

And also realize this is something that took me a while. You are going to spend the first three to six months of any job building credibility. And you will have options that are available to you at your current job. If you have credibility there, like you have a reputation of being someone who can get stuff done, you'll have options at that current job that you wouldn't have if you moved to a new position. I 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 you're like okay this problem this person can't hold down a job and so maybe they're hard to work with or they're not a good fit and it doesn't look good right in tech it's almost been the opposite where like there's a stigma against staying at the same place. And people think like they should move now

because, well, it's been two years. I've been here two years. 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 break that sucker? Because what I see a lot of is churn. And what churn creates is 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. And yet people have this feeling of like, I've been here for two years. Am I stagnant? Yeah. So there's a couple of things I want to tease power with that. 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 the tech industry. They're still doing tech, but 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 for someone who might be able to do that same thing. Or maybe I should say, I do know because the employee who's already in the company has fewer options and doesn't have- Less leverage. Yeah, exactly.

But I still think it's a dumb thing for a company to do because they are promoting this churn culture. Yeah, which hurts them, right? I mean, every time they have to onboard somebody new. Huge ineffic them, right? I mean, every time they have to onboard somebody new, huge inefficiencies, right? 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 independently contracting. You get a lot of breadth, but not a lot of 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 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. That's a really interesting point. I've never considered that moving jobs swiftly like steals from you the humility that working

on the same code base for a long time ultimately brings because you never have to live with your mistakes. You leave them for the next person. And so maybe there's even a little bit of arrogance that builds because you don't see your own folly, which I've had. I used to work on client work, and so I had a lot of that thing where I would come in, do some work, and leave. Leave it for somebody else. Or I had long-term contracts, too, that were maintenance mode.

But now I've been working on change log software pretty much only for years. And I'm mad at myself constantly. And it's a good thing because it keeps you humble. And you learn from those mistakes. So that's interesting. I never considered that with regards to job hopping. I swear I just saw this recently.

I'm trying to place where I saw it. It was like almost a version of this conversation to some degree where with like bugs and whatnot, that if you move along, you don't have to worry about putting out those fires or dealing with what's left behind. Essentially, you could just move on and greenfield, greenfield. It's nice to be in greenfield because you can create all the newness and all the brand new things. You're in that startup boat where it's always brand new creation and you never have to worry about, well, was that truly a wise choice in the beginning? And obviously not every choice we'll make will be wise long term. There's some things that will turn into tech debt and become a problem for the next team or whatever it might be.

But I swear I just saw this recently. It was just like this. It might have been in our Slack. I swear it might have been. Was it us? I hope it wasn't us because I swear I just saw this recently. It was just like this. It might have been in our Slack. I swear it might have been. Was it us? I hope it wasn't us because I just had an aha moment and if I had it before, then I'm losing my marbles. Well, it's quite possible, but yeah, I don't know.

Well, Dan, is there anything in particular we could talk about the creation of the book? You know, we can 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 ones that you were hoping we'd talk about or that you talk about often, or you think are like, you know, tent poles, what do they call those things? Tent pole features, holding up the tent. I mean, I guess the two that I would leave you with, right. 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 to be written, even with kind of the magic 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'm not a fan of gatekeeping. That doesn't mean that everybody's opinions worth the same value, right? Like if I was playing basketball and you asked my opinion and then you asked LeBron James' opinion, like you wouldn't value them equally and you shouldn my opinion and then you asked LeBron James' 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 pass it to LeBron James and let him do his job, I still have some value.

So I would just say everybody who's thinking about being a developer, you're welcome. It's a fantastic large field and you can be successful in it. Well said. Where's the live bar right there? Wisdom for sure. So you have letters to a new developer as a book out there. It's not a copy and paste from the blog. It's something brand new for people.

So if they've listened to this conversation and liked it, there's something new for them out there. This is a good recommend for folks. What's the best place to go to? What's the URL for this thing? Is it just on letters2atnewdeveloper.com slash book? What's the URL? I think it's letters2atnewdeveloper.com slash the book.

But it's available on Amazon and Barnes & Noble and IndieBound and Bookshop and A-Press. Everywhere. Okay, cool. Yeah. Go to Amazon. Go to anywhere you can buy a book. Buy the book. Worst case, Google it.

Or always good old trusty notes, right? Those show notes are there and they're editable. So if for some reason we get the link wrong, you can go into GitHub. You can fork that repository and put back your code change and boom, shakaboom. You got to commit just like that. Well, Dan, thank you so much for going through all this, man. It's been fun to talk about that. I don't always get to commiserate about my early failure days

of when I wanted to leave a manager or just these different scenarios. It's almost like I've forgotten about them. But I'm happy to cover them here with you on this show today. So it was fun. I'm happy to bring up your memories, Adam. Bring up your bad memories. Thank you. So there's a book out there that you can read and we've linked it up in the show notes.

So check that out. Letters to a new developer in blog form, archive, of course, and book form. So that's a treat. And tons of advice today here from Dan. So cool. So cool. Okay, so we're back in 2024. We've mentioned on social media and in Slack and soon on a podcast next week

that we're relaunching Ship It along with Justin Garrison. And it's gonna be fun. It's a brand new take on the show. The same which you love, but maybe a little different. But the same great podcast you love. Hear from your friends at Changelog. Now to a Ship It podcast again near you. So if you're on the Master Feed, hang out there.

If you're on the Plus Plus Feed, hang out there. You'll get it. But if you're not on those feeds and you want Ship It, go to shipit.show and subscribe. It's that easy. Also for our Plus Plus subscribers plus subscribers yes there's a bonus first show out the gate this year bonus for you of course and dan shares with us how he made the book if you're not a subscriber to changelog plus plus change that right now at changelog.com slash plus plus 10 bucks a month month, $100 a year.

Drop the ads, get closer to the metal, get that bonus content, and of course, directly support us. And by the way, it's better. Once again, changelog.com slash plus plus. Once again, a big thank you to our friends and our partners at Fly for helping us produce awesome podcasts. And also to our friends at TypeSense. They are amazing.

And, of course, to the Beat Freak in Residence Break Master Cylinder for those beats. They're so good. So good. Okay, that's it for this show. We'll see you next week.