Dear new developer

So we’re 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’ve retired, or you’ve – I don’t know if you’d like to call it; you’ve finished this blog. But a long one. Tell us about it.

Yeah. So in about 2011-2012 I wrote an eBook about a technology that maybe you all have 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 years, and I said to myself “I’ll probably never do a book again, but if I do a book again, I’m gonna 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 I immediately said, “Well, what would be helpful to me?” 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 can I tell people, that would have been helpful to me when I was starting out?” And I also thought “There’s no way in heck I’m gonna write a book. I’m just gonna 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 when I wrote the thank you post. I was also happy at same time.

Right. Relieved, perhaps…

Relieved, yeah. 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 that’s kind of the thing I think about. I focus on “Oh, I have this other thing I really want to do, and this Letters to a New 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.”

[00:08:02.05] 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 then I was also writing some kind of riffs, kind of taking you back to the original 2000 blogs, where everyone was 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 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 asking people that I was familiar with that were in different situations. I can think of one person in particular who had worked for 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 been to a job 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 gonna send someone to a job fair. But he had experience on both sides of the job fair. Table, as a word; the actual real table. And so he wrote a great post about that.

After a while, after I kind of had 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. I think Jamie actually has written one, your community member, and my community member… And I think I reached out to him. And I would start out - and it depends on the person; some people, 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 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, and be like “Hey…” Not that I have a huge platform, but it was definitely something, and I wanted to – the people in particular I can think of, who I felt they had a good message, and I wanted to just propagate it further.

So when you think about new devs, are these people who are in school, in a boot camp, or have they been working, 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 2010, 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 a New Developer, instead of letters to a Junior Developer… Even though I understand that you can’t swim upstream the entire time, and that’s what they’re commonly called, people who are new in their career.

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, Bill Clinton was in office.

Oh, wow.

Or maybe George W. Bush, depending on how you slice that. But so many 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, and curious about what that looks, not from a technical perspective, but from a day to day perspective, or “How do I succeed? 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.

[00:12:05.23] And then the other kind of audience - and I’ve definitely had people buy the book, or pass off articles - is the mentor, 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 came to you and said “Thanks, Dan. This particular letter helped me succeed in this way or that, or get a raise, or be more confident…” What do you think are – if you’re gonna 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…”

[laughs] That’s hilarious.

Intriguing…

Yeah. And this was based on kind of a comment on Hacker News, where someone was talking about the FizzBuzz test, where you just have to ask someone to – 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 [unintelligible 00:14:24.10] 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’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’ve found it” was another one that got some really good feedback. And that was just really a question of, as a dev, especially when you approach a new project, it can feel like - how to put this politely…? Sometimes when you walk into a new project, it feels like everything’s on fire. And that can be really disheartening and frustrating, especially when you’re a 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 a physical location or a house or a room in your house better than you’ve found it, but just by doing a little thing, you can help improve the overall health of a project by just doing small things. 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’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 it ran, and then I would have to modify it slightly for somebody who asked, and I wouldn’t touch it… You know, very afraid to change it.

[00:16:13.27] And over the course of a couple of years with that same codebase - 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 what was good or bad. I just thought I was inadequate, and that was kind of demoralizing…

Been there, man.

…until I realized it. And I was like – yeah, have you?

More on the frontend 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 frontend forms coming from different places. This is also the era of bad frontend anyways; 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’s 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. It’s tough.

Yeah. 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 “Nah, man, this is terrible. 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 one thing would be just a sounding board. And honestly, it could be another newer dev, it could be someone who’s slightly ahead of you, but my guess is that if you’d had another dev that you could point to and be like “Hey, is this off, or is this me?” and maybe make it more polite than that, but…

Sure.

…that different perspective is just gonna help you so much, and it’ll just accelerate things for you.

Absolutely. What else would you be on your shortlist, if you were gonna expand that to like maybe five things, 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, 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 gonna 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.

It’s like life skills almost… 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.” 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 –

Oh, 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’ve skill-stacked. That’s my assumption, I didn’t read it.

It’s actually slightly different.

Okay… [laughs]

Let’s hear it.

I mean, that actually is an interesting perspective… Skill stacking is basically I may be like a solid B developer… I guess 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’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.

I see.

So you’re an email marketer, and a coder, and frontend person - you’re gonna 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 very, very, very best speaker, or whatever. I’m not gonna fight with Tony Robbins, but he can’t talk about Ruby on Rails, so…

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 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 half between consulting, where you get to move between different projects, and you’re spread wide, but your understanding is 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… Is that what you were kind of referring to, or did I misunderstand?

Basically. That was my assumption, but I incorrectly assumed what your post was about, so I’ll just eat my feet right now… But basically. I’ve found this in my career - I can apply my ability to be a people person, my ability to be not really afraid of confrontation at all… I mean, fighting somebody… I mean, hard situations.

Yeah. Having those hard conversations.

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 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. So that’s kind of what I was [unintelligible 00:26:52.14] skill stacking. But yeah.

I mean, honestly, I think that’s true with probably any profession. I think that 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. Or flexible.

What I’ve realized over the years - I didn’t realize this as a young person - is how communication is like the… I won’t call it the trump card, just because that word has been sullied in the minds… But it’s a cross-referential – it’s like just the best skill that helps in every niche, every area of the stack, every business… And 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. That’s a skill you want to stack. And it moves with you.

[00:27:57.27] 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 be taken lightly, and it’s a difficult thing 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.” That’s kind of just like a sunk cost at that point, unless you’re gonna 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 Changelog back in the day, was 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 to React.” I mean, even that’s a David reference, but… You know? That happened; it’s happened to all of us. And you’ve lasted a long time in this industry, Dan.

Totally.

Do you have 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. Because I came out of school and I thought, “Oh yeah, it’s all about 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 for people, right? Whether you’re doing it for money, or for open source, for fun… So I would just kind of set that aside, but when you started talking about that, it’s just something that I want to say… Actually, I think you have even a blog post about that, where it’s like “Software is for people, not for code.”

As far as kind of staying current, I think that there’s a couple of ways you can kind of hack this. The first is, you know, you kind of mentioned jQuery… There’s still a ton of sites out there; you can probably get a job in jQuery. So you need to think about 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 10% behind the people who are kind of pushing things forward, or to be someone who’s helping companies that, frankly, might not be doing the most exciting things, but still have applications that are making money? There’s still people out there hiring for Perl. I wrote Perl in 1999, and I wouldn’t say it’s a thriving job market, but it’s definitely 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 allow you some time within the corporate structure to do some R&D, or some education… But I think that, especially if you don’t – it’s always tough to tell people to spend time out of work, because we all have other constraints… But even just reading something, and even just having kind of a high level of understanding…

When I took a class about AWS, or – yeah, I took a certification… And the value of the certification is not necessarily knowing how to do everything. The value of the 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; 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 frontend thing. Have we evaluated React?” And this is, again, not a conversation you’d have now, it’s a conversation you’d have five years ago. But you need to be kind of aware of – at least aware of it. Does that make sense? What are your suggestions?

I think so…

[00:32:00.16] Yeah.

Adam?

I like what you were saying about being behind people. There’s this – I suppose it’s life in general, but this idea to keep up.

Keep up with the Joneses.

Yeah, exactly. The Joneses. Whether it’s skills, or materials, this idea to keep up, essentially. And we said that early on too, with our tagline - “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 ended up – especially as new devs, you end up chasing different squirrels, and shiny objects, and you’re not really sure 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 – just because you’re chasing things. But this idea of like staying 10% behind the people that are innovating and pushing forward… Kind of maybe staying in the jQuery lane; maybe you shouldn’t do that, and maybe that’s probably not good advice today, but just the idea of staying a little bit behind the trendline, so to speak, so that you have 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 the chance to sort of diversify.

I mean, I definitely have seen plenty of cycles of the new thing comes out, and the consultants all rush in, and they all write the books, and they’re doing the Hello worlds, and 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 [unintelligible 00:33:31.12] But then you have to go find that new new thing, right? 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, if you stay 10% behind, or 20% behind, you can see where the consultants have gone, and then you can see where the company is invested to. And then you can kind of be like “Oh, now it’s time for me to make this switch.” And you won’t make as much money as the consultants, and you won’t have the fame, or you won’t be able to write 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 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?

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.

Yeah.

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. And I’m gonna set that aside. Let’s assume you’ve found someone who actually wants to help you, but they’re busy. And so first of all, asking for a one-to-one, which is - for your listeners who might not be familiar with it, it’s just like a weekly, bi-weekly regular meeting. And you could do it with 10 minutes - that’s probably a little short, in my mind; it shouldn’t be an hour… 30 minutes is kind of the sweet spot. But it’s a regular check-in. And you as the new dev should manage that. 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. 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.

[00:36:09.29] Actually, one of my other popular posts is “There no adults in the room”, which was – it 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. You walk into business, and people know how to solve these problems. And that may be true in kind of a relatively static business, with a really good lineage… 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 around and 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 thought it was kind of interesting to think that there’s no adults in the room. And it’s kind of perspective taking what you’ve said here in the post; you said “There’s two ways look at it”, in this angle of basically no one knows 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 is opportunity. “Excellent. I can see that folks are grappling towards solving problems, and I can 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, 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 all the rules of this business, or like the way we do things, and 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.” We’re all on the same level here, we can just question this stuff… And maybe there’s 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 then. I think that’s a really powerful thing, and it seems like something that most of the time the manager would institute, 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. [laughter]

There you go. A shortcut.

[laughs] I mean, I think that what you need to do is put yourself in your manager’s shoes. And your manager is going to succeed when their team succeeds. And again, I’m setting aside the toxic, empire-building manager. So what you wanna do is you want to frame it as “Hey, I want to have some of your time to make sure that I’m addressing things that you want, that I’m unblocking myself in the best way I can, that I’m taking advantage of your institutional knowledge…” And I think asking for like 30 minutes a week - that might be a nonstarter for some folks. I know some folks manage 30 people, which to me is - I can’t imagine how you do that effectively, but it’s possible.

[00:40:10.01] So start smallest talk. Ask for that first meeting and say “Hey, I’d just really like to–”, after that first month, or that first couple of weeks, be like “Hey, I just wanna 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, 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, the underlying? 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 that person?

Period. What do they want from it? 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 skillset? So I can showcase what my expectations are, have clarity? What is the point of it?

I think that the point of the one-on-one for a new dev is to build a relationship with the manager. And that could involve…

There you go. That’s better not answered.

Well, I mean, it could involve giving some status… I mean, my favorite thing when I am with a one-on-one is where somebody 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, where you don’t have some of the sinew, the social connection that you can get in an in-person office, you need to build that. And so I think one-on-ones can help you do that.

From a manager perspective, the big win is not being surprised by something that someone is planning. I actually had a guy – I was doing regular one-on-ones with one of my developers, we’re going out to lunch, but it was our one-on-one, and 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 his heart was someplace else. And that was fine… But 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 in a one-on-one purely from a manager’s perspective.

I’m glad you responded with that, because relationship is so important in that scenario. I mean, I got 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’s just like basically the relationship”, which is super-crucial to any sort of scenario where you have 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, and I’m not sure what it is as a new person, essentially… So I’ve 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 – I mean, 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 about why I never want to be a manager again, if you all want to hear that… But people can leave – people can… How do I put this politely? I’m okay with someone not wanting to be managed by me, as long as they know me. But to your point, Adam, if you don’t even put the effort as a manager and as a new developer to build that relationship, you’re gonna have a really hard time. You won’t even know whether or not that might have been the right position for you, because you’ll get frustrated or burned out, or you won’t have that feedback that you need to improve.

So I’ll bite… 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. They’re related, and 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 to engineer 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, 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, 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 – give me a specific for it, just to be clear.

[00:47:51.20] 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 – well, that’s one example of a task that I find unpleasant. And I think most managers find it unpleasant. 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 Yp 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 a pleasure in the act of axing people… Because nobody likes to do that.

I’ve seen the movie. I need to go rewatch it now that you mentioned it, because it’s been a while. I forget the premise… Yeah, you almost ruined the plot for me.

Oh, I’m sorry. Well, that’s not ruined, that just is the plot.

Well, isn’t Julia Roberts in it, too? Or 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…

For sure.

…so he loves to fly. He’s like the most frequent flyer. And 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 ego in all the special places etc. 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. another aspect that I find tough, that I think other people enjoy… When you’re a manager, you take joy in your team members’ successes. And of course, I like to see team members succeed, but that becomes your whole thing. 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 dealt with in my life 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 find that out about yourself, and not necessarily 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 learning when to leave… This is kind of like learning when not to take on a role, is what you’re saying… 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 folly… And so I would love to hear some reasons when it’s a good time to leave, knowing when, versus maybe leaving at a wrong time or for a wrong reason… What have you got in that area?

Sure. I mean, with the caveat that everyone’s situation is different. I think that you shouldn’t leave when there’s still – well, first of all, I think it’s 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, right? If I know advertising, or I know real estate, 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’re getting out of the job.

[00:51:56.19] 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 kind of, as best you can, all of the benefits that you will have in your current situation, and [unintelligible 00:52:14.17] have coffee with someone, and have a conversation about their company, or their aspect.

Going back to 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 realize 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. 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, 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 had a job and it was like six months here, 18 months, 12 months, you’re like “Okay, this person can’t hold down a job. 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, where there’s a stigma against staying at the same place, and people feel 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 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 like knowledge transfer problems… Everybody’s perpetually a new developer, at least on this particular codebase, 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 apart with that. The first is I think that absolutely depends on the section of the tech industry you’re in. There are definitely companies out there, or organizations I can think of, where people will stay for decades. And it’s the 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. 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 –

Has 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, and which hurts them, right? I mean, every time they have to onboard somebody new - huge inefficiencies, right?

Totally. And plus, you also get – 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…

[00:56:04.26] 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 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, and 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 codebase, and you see them in git blame, 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 code mistakes is just not going to be.

Right…

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 steals from you the humility that working on the same codebase 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 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 mean, I had long-term contracts, too; they were maintenance mode. But now I’ve been working on Changelog software pretty much only for years, and I’m mad at myself constantly, you know? [laughs] And it’s a good thing, because it keeps you humble. And you learn from those mistakes. So that’s interesting… I’ve never consider 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, 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 mode, 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 you 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.

Was it us? I hope it wasn’t us, because I just had an a-ha 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, we can talk about that… But in terms of the content 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 talked about often, or you think are like tent poles… Or what do they call those things? Tent pole features, that hold up the tent.

I guess the two that I would leave you with, if you said “Dan, 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 a text editor - those are things similar to communication you mentioned, where it’s kind of across different jobs. 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 some basic foundational tools, and try to learn them well.

And then the second thing I would say is we need you. We need all kinds of new devs. There’s so much software being written. Even with kind of the magic of generative LLMs, we still need different perspectives. So many problems need to be solved, that I welcome anybody to become a developer.

[00:59:53.06] I am not a fan of gatekeeping; that doesn’t mean that everybody’s opinion’s worth the same value. Like, if I was playing basketball, and you asked my opinion, and then you asked LeBron James’ opinion, 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.

Words to live by 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 LetterstoaNewDeveloper.com/book? What’s the URL?

I think it’s letterstoanewdeveloper.com/thebook. But it’s available on Amazon, and Barnes and Noble, and IndieBound, and Bookshop, and Apress.

Everywhere. Okay, cool.

Yeah.

Go to Amazon, go 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, chicka-boom. You’ve got a 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. To bring up your bad memories.

Well, thank you. [laughter]