How to stand out as a new developer (and ask amazing questions) with Dan Moore from FusionAuth

How to stand out as a new developer (and ask amazing questions) with Dan Moore from FusionAuth

What do you wish someone had told you when you were just starting out? If you are a new developer (we’re not using "junior developer" here - listen along to find out why!), there are skills you have, skills you can transfer from somewhere else, and skills you don’t even know you need. You probably also have a lot of assumptions… and not too many people who can tell you whether they’re true. Dan wants to change that!


Who is Dan Moore? He is the author of Letters to a New Developer - a blog and book of advice he wishes he had gotten at the beginning of his career. Dan is a developer with twenty years of experience, currently working as a Solutions Architect at FusionAuth.


Timestamps

  • Introduction (00:00)
  • Why Dan started writing letters to new developers (01:22)
  • Junior Developer is a demeaning title (02:59)
  • Are you too old to learn to code? (05:11)
  • How to transfer your skills from one industry to another (06:26)
  • Things that surprised Dan as a new developer (12:23)
  • Nobody wants to work with a brilliant jerk 2(16:02)
  • What to expect in your first month on the job (18:14)
  • How to ask amazing coding questions that get answers (20:59)

Transcript

Alex Booker (00:00):
Hello coders, welcome to the Scrimba Podcast. On this weekly show, I speak with successful developers about their advice on learning to code and getting your first junior developer job. Today I'm joined by Dan Moore who wrote a book named Letters to a New Developer.

Dan Moore (00:17):
What I wanted to do is catalog some of the things that I thought were true that weren't, in a way that was easy to consume. And so I ended up writing a number of letters to a new developer that in the book are grouped by theme and hopefully, and I've had good feedback from people who've read it and people who've read the blog, will help illustrate aspects of a new job as a developer that aren't really obvious from outside.

Alex Booker (00:45):
This is such an important topic if you want to become a junior developer. It is hard to stand out based on your coding skills alone because as a junior you're quite new, but maybe you ask great questions, you understand how software is built, and you're an excellent written communicator. An overarching theme in this interview is that those things are more important than Dan ever realized. And Hey, if you are ramping up to get your first developer job, you are going to learn a lot about what to expect and how to hit the ground running and impress your team in your first month. Let's get into it.

Dan Moore (01:22):
I wrote a book. It's actually based on a blog and so you can go visit the blog. And well, 90% of the articles that are in the book are also on the blog. I did revise everything, had it reviewed by a number of people so it's different content but the topics are similar. But if you want to get a flavor of the book you can check out the blog, which will be forever free. The whole point of this was that I had certain assumptions that I had when I started out as a developer. I don't like to call them junior developers that feels a little bit demeaning, I call them new developers.

Dan Moore (01:57):
And so what I wanted to do was catalog some of the things that I thought were true that weren't, in a way that was easy to consume. And so I ended up writing a number of letters to a new developer that in the book are grouped by theme and hopefully will help illustrate aspects of a new job as a developer that aren't really obvious from outside. I started running it in 2018, 2019, and there were just so many people coming to meet up groups that I was going to and that I was talking to. Who were coming out of boot camps or other programs and just having a really hard time finding a job and I just wanted to help them as best I could.

Alex Booker (02:37):
Oh, really? That's amazing. And one thing I noticed about the book is that it really is like a series of letters. They're very pleasant to read. And I would also point out that it's quite digestible, right? How would you recommend somebody read your book?

Dan Moore (02:51):
Yeah. I mean, I think there's a couple ways, right? The first is put it by your bedside and just read one or two letters a night.

Alex Booker (02:57):
To send you to sleep you mean. Come on, Dan.

Dan Moore (02:59):
I mean, I just feel like they're all standalone. So it's not like a book with a bunch of different concepts or a one continuous concept where you have to put things together. You can actually read it, pick it up and put it down that was one of my goals. Another way you could read it would be to pick some area that you know you want to improve on, right? Whether that's community or learning, et cetera and just focus on that section and leave the rest for some other time. Yeah. Those would be the two main ways I would think that would make sense to read the book.

Alex Booker (03:30):
What is this about the term junior developer that you think is demeaning?

Dan Moore (03:34):
You know I was at a startup week event, gosh, probably 10 years ago and someone said the same thing. They were a speaker up on the stage. And I guess I feel like on the one hand it is accurate, right? Because you talk about junior varsity in sports if you're in the U.S, I don't know about other parts of the world. I don't think that a junior developer is junior in terms of their ability to provide value to an organization or to do work, I think they're just new in their career.

Dan Moore (04:06):
And so, I just felt like calling people new developers is more acknowledgement where they are in their career path. The other thing is that you can be a junior developer and be 60-years-old and we need those kind of people coming into the workforce, coming into the software world just as much as we need the 15 year olds and the 20 year olds. But if I was 60 I'm not sure I'd be thrilled about being called junior, it feels like new is just a more respectful way to deal with it.

Alex Booker (04:33):
Yeah. That's a fantastic point. In the Scrimba community, one of the questions that comes up the most is like, "Am I too old to learn to code?" And I always have a tremendous amount of respect for people changing career a little bit later in life. It takes a lot of courage to do that, especially when you're leaving another successful role. Yeah. Being called junior doesn't sound great, now I think about it. Do you remember maybe it was a year or two ago there was a bit of a trend going on on Twitter where more influential or experienced developers put in their Twitter bio something like, forever a junior developer. And the sentiment I think was that people were always learning. There's always something to learn. Do you agree with that sentiment?

Dan Moore (05:11):
Yeah, absolutely. Oh, man. Actually I want to take a step back and answer that question, if people are asking on the Scrimba community whether or not they're too old to learn to code. And the answer is no. Just a flat out no. A lot of people have this perception about development that it's heads down coding, banging in on the keyboard. And I think that there are some aspects of development that are like that, but there's so much that's about communication, about understanding a domain about being able to problem solve, being able to work on a team. And if you have prior experience doing any of those things, which is very common in other jobs, you're going to bring that to your software development career. And the ability to code those combined together can be a really, really powerful combination. So I just want to throw that out there.

Alex Booker (05:58):
You've tried a few different hats in your career, right? You've tried a few different roles within the developer space. Of course I'm talking about developer jobs in your case. But I've also heard of people who for example have been teachers and they've used some software provided to them by a school. And then when they've interviewed at a company that builds software for teachers and for of schools even though this candidate wasn't the best developer, they have a huge amounts of what I would call domain knowledge and also empathy for the end user that can help them a lot.

Alex Booker (06:26):
I suppose another way of looking at it is that every brand new person who's never worked a job before, they just can't possibly know the unspoken rules in a workplace and the etiquette and things like that. You don't learn those on a Udemy course or frankly at school, although maybe university is a bit conducive to that kind of collaborative environment. Could you talk about transferring skills from one place to another a little bit more because I think it applies to a lot of people.

Dan Moore (06:50):
Yeah, absolutely. I mean, I think that again people get hung up on code skills, but the same way that you can take a job and if you're doing React or you do your React project at Scrimba, and then you move on and you get a job doing React, there's going to be some value in the previous experience and there'll be some stuff where you just have to learn new things. There are new ways to do React, React is continually evolving. You may go to a company that's a few revs back or has built their own custom things on top of it, the same thing is true with interpersonal skills.

Dan Moore (07:22):
When you are working on a team as a teacher, or I actually know some people who worked in customer service for a long time who then became developers. There are some things that are cross-domain. So knowing how to work in a team, knowing how to say what you're going to do and then actually follow through and do it and ask questions intelligently, make mistakes but like only make them once these are all things that are really applicable in any job. Whether you are working in construction or in nursing or in real estate or in banking, these are all things where you're going to need to learn how to do that.

Dan Moore (07:58):
And to your point Alex, you can simulate some of that with project work sometimes but there's a lot of it you just have to learn. And my book is one of the ways that I think you can learn, right? Or from other people's experiences. Then there's the other piece which is maybe more interesting to some of your listeners is the domain piece. I worked at a real estate brokerage for a number of years as a software developer. But when you're building software for realtors, you need to be able to talk to realtors. There are things like loan terminology or other pieces of a specific domain knowledge.

Dan Moore (08:32):
And so if you're a software developer and you can talk in that vein, you're going to be able to build better software. Because you're not going to make assumptions and you're not going to have to be brought up to speed on that. If you were a nurse previously working in healthcare, you're going to have a lot better understanding of the particular aspects of it that are going to get codified in software. Frankly, in some ways you'll be a product manager's dream because they'll be able to hand you things at a higher level of granularity, rather than having to translate between what the user of your software needs. And what they mean when they say hospital bed and what that is represented by in the software system.

Alex Booker (09:11):
Oh, totally. Yeah, absolutely. And you can also then perhaps give feedback and things like that, which product managers might also appreciate. That's the term I haven't really used or really known before, cross-domain. And it shows that if you are changing career, maybe there's a temptation on your resume or LinkedIn profile to emit skills which you don't think are relevant or experiences you don't think are relevant. But what I'm understanding from you, Dan, is that actually they might be more relevant than people think.

Dan Moore (09:39):
Yeah. I think that software is a team sport. And this is something that's been happening for years and years. The idea of a coder getting a set of requirements and going off in a corner and building on a system and then handing that back to the client is something that honestly I haven't seen in my career in two decades. And maybe it was true before my time, that's very possible. But at this point now especially with agile in some areas, this is a bit of a dirty word, right? But when you are building software you're basically codifying business needs in a way that just gets done quicker and more efficiently and cheaper.

Dan Moore (10:15):
And so how does business get done? Well business gets done by communicating with other people. And so that has bled into software in a good way, I think, because you're actually being able to deliver value more regularly. And when someone says they want X and then you build a little piece of X, and then they say they want actually OX plus one you can actually make that shift. But all of that requires communication skills and understanding of the bigger picture.

Dan Moore (10:43):
And I will say as a newer developer, sometimes you may be given a little small portion of something and it may be your job to complete that and complete it well and complete it on time. And you may not have the whole big picture and that's okay too. But I think that if you can put yourself in the mindset of someone who'd actually be using the software or have user empathy for them either because you've worked to build that or because you have previous life experience that gives you that, you are going to be able to build a better project and better software.

Alex Booker (11:19):
If you are enjoying this episode of the weekly Scrimba Podcast, please do us a favor and share it with your friends on social media. Word of mouth is the single best way to support a podcast that you like, so thank you in advance. Next week I'm talking with a Scrimba student named [Miloge 00:11:37], who believe not used to work at Cirque du Soleil and travel the world until the onset of the pandemic. At which point he turned to Scrimba to learn to code. And recently I'm so excited to share he became a full-time developer.

Speaker 3 (11:49):
Anything that you see in theater that moves, that's basically automation. When you see performers flying through the air or something like that or any massive scenery moving around, that's basically what I've done and I love it. You deal with PLCs, programming PLCs, you deal with a lot of different softwares. Then on the other side you deal with mechanics, with electronics, with hydraulics, with random stuff just all the time. That's when I found a little bit of interest in coding because it's all connected and you want to know how it all works.

Alex Booker (12:23):
That is next week on the weekly Scrimba Podcast. I keep emphasizing weekly. You have to subscribe and see in your feed every week, you never know what you might see. So yes, subscribe in your podcast app of choice. Back to the interview with Dan. In our introduction, you mentioned that your expectations as a new developer didn't quite match reality. Like you weren't sure what to expect and that's a little bit of the motivation behind your book. What are some of the most notable misexpectations you had?

Dan Moore (12:53):
I can pick out a couple to share with you. One that's a really prosaic one is that I didn't eat lunch with my colleagues. I was right out of school trying to save money, and so I brought my lunch and I would go sit out on a hill just to get some sunshine. And I really thought that was a better use of my time and that was wrong. Because there were things where it would've been better for me, both more fun I think in some ways, but also just better for me as a career path for me to interact with my colleagues. Because lunch or other times like that, social times are a way for you to engage with your colleagues where the pressure is maybe not so high.

Dan Moore (13:38):
And I'm not saying you need to go and party with your colleagues all the time or go spend a bunch of money you don't have to go do lunch, but take advantage of those social opportunities because when things get tense or when you need something from somebody, even when you want to just know who to ask the right question of, the social connections that you have fostered in non-work environments or work adjacent environments will pay dividends. That's one. Another was that again, just back to the team thing, I thought that coding was really the primary part of the software development position. And I quickly learned that coordination between developers and customers and communication in that way was far more important for a successful project, right? Anyone can code something up, but guess what? If you code the wrong thing, then you have just basically burned some money.

Alex Booker (14:33):
Going into coding interviews, they're called coding interviews, we think we'll get judged on our coding skills and like, why do we need three or four steps to judge our coding skills? But probably the whole process is equally a kind of, I'm reluctant to use this word even though it makes sense but a culture fit. Which I guess is just a lazy way of saying how well you're likely to get on with people based on your shared values and things like that, but also your attitude. And I suppose one belief I've built, why I've done the Scrimba Podcast and met successful Scrimba users is that even if your coding skills aren't the best, you can make up for it a little bit if you bring such a great attitude to the interview and to the job.

Dan Moore (15:10):
It's worth kind of dawning that the world of software is vast. And so there are absolutely positions where you need to have those algorithms down pat, either because they're big companies trying to measure thousands of candidates or because it's a company that's pushing the boundaries of hardware or software. But there are very, very, very many more, at least in my experience, companies where willingness to learn, good attitude, communication skills, and decent coding skills will get you in the door and get you a job that is a comfortable, great position where you can learn a lot and be a great contributor. So I don't want to say that you never need to be able to ace those coding skills. But I think that for the vast majority of my jobs if I was choosing between someone who was, how do I put this without cursing? A jerk.

Alex Booker (16:00):
Oh, sure.

Dan Moore (16:02):
And could kill it on the coding side versus someone who is a decent coder but is very personable, very affable, meet commitments, doesn't talk down to people or condescend to people I know who I'd pick 99% of the time. I'd pick the second person.

Alex Booker (16:19):
Yeah. Those are the good qualities and they're like nobody wants to work with a brilliant Jack, I think. I think that's the quote pretty much.

Dan Moore (16:26):
Totally.

Alex Booker (16:26):
We are talking about junior devs there. And the truth is if you know everything, nobody knows everything even the developers don't know everything about coding or their language. But as a junior you certainly don't know much. And so you're not really just being judged on your ability to do the job then, but your ability to learn. If you have a bit of a I know it all attitude, well you just don't have potential to grow in that role and it makes no sense.

Dan Moore (16:47):
You're absolutely right. And actually that's one of the letters I wrote was that especially for newer developers you're really getting hired for your potential. As you get older and older and more expansive or more and more experienced and more expansive, then I think you're hired more for what you can bring right away. But lots of times you want to show your potential to learn, your curiosity and those are really great attributes. And the other thing I would say is that there is a lot of value when you're a new developer and working on a job of keeping track of things that don't make sense to you. Because when you've been in a system for a long time you may have assumptions or you may have things, tasks, or design decisions that are done in a certain way just because they always were done that way.

Dan Moore (17:36):
And so one thing I always love especially when it's a new developer, whether they're senior or less senior is I say, "Hey, yo. Keep track of what doesn't make sense to you and don't blurt it out. Every time that you run across something doesn't make sense to you keep track of it for a month or two, and then let's have a meeting and talk about it." Because it may make more sense after that month, right? Because you're done drinking from the fire hose or the fire hose is turned down a little bit or it may not. And it may be something that we should change we just haven't thought about it enough. Because you bring those new eyes I think that's a super valuable thing.

Alex Booker (18:14):
Dan, let's take our listeners to the promised land. I think the majority of people listening are on the path to getting their first new developer job. If we had to imagine we're in that position where we just got the job, what are some things that we should expect in the first month?

Dan Moore (18:32):
I would hope that you have a decent onboarding process because that can be one of the hardest pieces. There's hardware onboarding where you're given a piece of hardware like a computer and monitor and whatnot, there's legal onboarding so making sure that you know how you're going to get paid and sign the employee handbook and all that stuff. And you may laugh because you may think, well, what kind of company wouldn't have this all dialed in? And I'll tell you, small growing startups or small companies may not have a dialed in. Big companies probably will, but you definitely want to make sure that you get all that known.

Dan Moore (19:08):
Knowing things like, can you on side projects on your own time. That's actually something you should probably ask in an interview if that's important to you, because some companies want to claim all of the IP that you generate. And then there's the actual technical onboarding where you're learning about the system and you're trying to find out what your team does or what you do if you're not on a team and how all the pieces fit together. So those are the three pieces of onboarding you should think about. One piece of advice about this is I get interviews are exhausting, especially when you're getting a lot of nos it's mental exhausting, it's tough to be doing all this stuff.

Dan Moore (19:43):
But if you can just put in a little bit of extra effort that first month, I think you're going to stand out. I don't mean work 80-hour weeks. Don't set yourself up to be abused, but just come in 15 minutes early and leave 15 minutes late. And just do a little bit of extra reading on the weekend. Getting that reputation as someone who just goes a little bit above and beyond will help you far into the future. I definitely had that experience in my first job. And I will say that everyone's busy but people notice when you put in a little bit of extra effort. So the onboarding and the, I call it over-indexing where you just put in a little bit extra are really going to be things I would expect for that first month. Or I would advise for that first month.

Alex Booker (20:23):
People like to help people who help themselves. And if you're showing up a little bit early, staying a little bit late. Not only that but to your much earlier point about getting lunch with your colleagues, I've often found for it is a similar group of people who work late and they tend to really like working there and they like knowing their co-workers. So if you're there a little bit late or a little, maybe not so much early while people haven't had their coffee but more so a little bit later people might just say, "Oh, you're here late. What are you working on?" If you're not someone who can easily strike up a conversation, it's good to have a topic to talk about. I like how this is coming together, Dan, that's a good idea.

Dan Moore (20:56):
Awesome. That's a really interesting thing to bring in that thread.

Alex Booker (20:59):
I almost wanted to ask this question to you as soon as we started the interview because it's something that's so interesting and important to me. In the Scrimba community on our Discord channel, we have a specific channel or a few specific channels where people can ask for coding help. In my experience as someone who's a self-taught dev and had to rely a lot on strangers on Slack Overflow and wherever else for help, I had to really learn how to construct a good question and how to prove that I'd done a little bit to help myself and make it as easy as possible for other people to help me. One thing we don't do a good enough job of in the Scrimba community is teaching people how to ask good questions. And so based on some of the things I've written by you, I was hoping you could do us the honor and teach people a little bit about how to ask good questions, both in Discord, Slack Overflow, or even in your first job.

Dan Moore (21:51):
Asking questions is one of the fundamental things I think new developers need to be good at. And I think there's a couple of different pieces to it. One is, don't be ashamed to do it. So one of my rules of thumbs when I'm dealing with newer folks is I say, "Hey. Take 15 minutes, 30 minutes try to figure something out." I want people to take the time to learn on their own, right? And this gets to one of the things you were talking about, Alex, about Scrimba's benefits, right? Is you can stop the video and you can tweak things and learn on your own, which I think is super important.

Dan Moore (22:21):
But what I also don't want to have happen is have you spend four hours chasing things down a rabbit hole, chasing topics and Googling all these different things trying to figure things out when I can take 15 minutes, draw a picture, and answer your question in a way that conveys that information effectively. That is actually a better use of the company's time and effort for me to make that change. So point one for asking good questions is don't be afraid to ask questions. The second thing is I would say is, don't ask the same question twice. When you ask question, listen, learn it, and however you need to codify that do so. So some people keep a journal, some people keep a wiki, some people you have a personal Slack. I tend to blog.

Dan Moore (23:03):
Even better you write the answer down in a way that's public to the other members of your team. Or if it's an open source project or something that you can expose to the outside world, the whole outside world, that will solve your problem in terms of submitting that information for you and then it will also solve that problem for everybody. Those are both kind of sidestepping the actual question of how to ask a really good question, but I think they're important preferences. A really good question is specific, shows, as you alluded to Alex, that you put in some effort, and is not just one and done. Let me break those apart.

Dan Moore (23:40):
So it's very specific, so don't ask like, "Should I use React or Angular?" That's a question that's going to be really hard to get a good answer to. What you really want to say is, "I'm trying to build a real estate application that is going to be mobile and on the web and it needs to interact with this particular database." And get as specific as you possibly can. If you're asking technical questions that can include error messages, avenues you've tried, other articles you've read, so build out a question and that also shows anybody who's looking at that question that you've actually put in some effort.

Dan Moore (24:16):
And funnily enough when you start to assemble this really specific written question, you may find things that you're like, "Oh, wait." I can research that little thing too." Or, "This might be an answer." And sometimes you don't even actually need to ask the question. By the very act of being detailed about the question you can answer it yourself. And the last thing is, if you do end up asking a question then you should not just throw it over. It's on you to pursue and answer that question. Now the context matters for that, right? You don't want to ask a question on public mailing list and then 15 minutes later respond back and say, "Hey, has anybody had a chance to look at this?"

Dan Moore (24:53):
But if you're in a team environment, I could see posting a question on Slack and then 30 minutes later if no one's responded to it say, "Hey, I'm really looking for help on this." But at the same time you can also continue to do that research. And hopefully in a new development environment, if you're a new developer, you will have a mentor or a buddy or a manager where you can say, "Hey, I asked this question. No one's responded. What's the best way for me to get a response?" And that manager may say, "Oh. Let's schedule a meeting or let's talk on a call or you should ask Joe or whatever." That idea of you owning it from asking the question well all the way to pushing it to completion, I think is really important because software developers have a lot of autonomy but we need to earn that as well. And you earn that by pushing things to completion.

Alex Booker (25:42):
Yeah. It's not good enough to be like, "Oh, I've been stuck and nobody helped me." You should try for yourself, but for about 10 to 15 minutes-

Dan Moore (25:50):
I mean, talk to your manager about what their level of comfort is. Some managers may want more time less. I just want to say that's my rule of thumb.

Alex Booker (25:57):
... I think as a rule of thumb that's perfect though. Any shorter than that you might be drinking from the knowledge well too much. Like you want to put forth the minimum effort. But you're absolutely right, no manager wants you to spend four hours going down a rabbit hole because if you don't know the answer after 20 minutes, there's a few reasons and there's probably a few ways to accelerate that. And the second point you made is when you ask a question don't just take the answer and apply it, try and codify it somehow. And I think there's so many good reasons to do this. You're such a valuable teammate.

Alex Booker (26:25):
Every good team should have documentation, right? But nobody really wants to write for documentation. They have to like, "Oh, no. This person, this new developer has been doing it." They're going to love you. They're going to really appreciate it and it's going to be a good learning experience for you too. And I like what you do, Dan, which is basically blog in public. Because especially as a new dev this is true even if you haven't yet got a job, you're now creating a bit of a surface area. People can find you and you can help other developers in your position make friends and things like that.

Alex Booker (26:53):
The third point be as specific as you can. If people say, I've got an error can someone help? Share the error message, please. Share the specific error. It's impossible for someone to help you. I do sympathize a little bit for as a new programmer you don't always know what the other person doesn't know and show what you've tried already. It earns you some good faith first of all, people are more likely to help you. And if you've already said, "Oh, I've read this article." They're not going to waste time recommending it to you in case it's the obvious solution. And yeah, pretty much touched on it along the way which is, if you ask a question own it till the very end. This is your point exactly, Dan. But do your best to follow-up and make it happen because that's how you earn the autonomy as you say.

Dan Moore (27:35):
That was a lot cleaner than what I said. So thank you, Alex.

Alex Booker (27:37):
No, not all. I think it's just so good it's worth repeating twice, honestly. I think it's one of the most valuable skills any developer can have.

Dan Moore (27:44):
Definitely. And I would say part of that reason is that you're not going to stop asking questions when you're a mid-level developer, whatever that means. I ask questions all the time, and so this is something that will follow you. Again we were talking a little bit about transferrable skills. This is something that will be useful to you at every job you ever work in. Like learning how to really dig in and ask the right question or ask a question well is going to be a very useful skill long-term in your career.

Alex Booker (28:11):
Absolutely. Dan Moore, thank you so much for coming on the podcast.

Dan Moore (28:14):
Thank you very much for having me.

Alex Booker (28:16):
That was Dan Moore, author of Letters to a New Developer. You can find a link both to Dan's blog where some of these letters exist for free, as well as the book for purchase in these show notes. Remember again to please subscribe to the Scrimba Podcast, both to see interviews with inspiring and insightful guests like Dan but also to support the show. This episode was edited by [Yan Osancvich 00:28:38] and I am your host, Alex Booker. You can follow me on Twitter @bookercodes, where I share highlight from the podcast and other news by Scrimba. See you next week.