PRE-RECORDED SPEAKER: Collaboration between different disciplines in your organization can be difficult, and finding clarity and alignment on both the right problem to solve and the right solution design is even more so. We each approach improvement from our own (limited) perspective, without taking into account the whole story. How is that effective?

Paul Rayner's EventStorming Facilitation Virtual Workshop is a multi-day online event that promotes collaboration between different disciplines in order to solve business problems in the most effective way.

This virtual workshop with Paul consists of 4 sessions on Sep 28-Oct 1 from 9am-Noon (CDT) each day. To register and get 20% off your ticket, visit virtualgenious.com/events and use the code VGGTC.

In this highly hands-on and interactive virtual workshop, you'll learn advanced EventStorming facilitation skills spanning from large scale business discovery to collaborative solution design at the team level.

Once again to get 20% off your ticket, visit virtualgenious.com/events and use the code VGGTC.

JACOB: Hello, and welcome to Episode 197, Greater Than Code. My name is Jacob Stoebel and I'm here with my cohost, Rein Henrichs. 

REIN: Thanks Jacob and I'm here with our guest Dan Moore. 

Dan Moore has over 20 years of experience as a developer. His roles have included employee, contractor, community member, engineering manager, and CTO. He currently leads developer advocacy at FusionAuth, a Denver company, building software to handle authentication, authorization, and user management for any app. In 2018, Dan started a blog exclusively focused on helping new developers “level up” and has published over 150 posts to help them improve their skills and avoid common mistakes. He resides in Boulder, Colorado and you can find them on Twitter @mooreds. 

Hi, Dan. 

DAN: Hello. Thanks for having me. 

REIN: Yeah, welcome to the show. So, you know what's coming. What is your superpower and how did you acquire it? 

DAN: Yeah, so I spent a little time thinking about this, thanks for – because I've listened to some other episodes and had a great answer prepared and then I asked my wife and she said, “Oh no, it's totally this,” and so, it's my ability to keep calm and I've been in some really stressful situations. I'm happy to talk about some of those, but instead of freezing up—and this is mostly in a business context, I can definitely freeze up if my kid has a bloody broken arm or something like that. 

But I step back and take a deep breath and then I think about how to solve a problem, how to fix it. I don't throw up my hands. I don't say what was me. I don't get frustrated with other people or, I keep that down. Everyone gets frustrated in other people, but overall my ability to keep calm and focus on solving the problem rather than taking it as a personal afront or being frustrated or being a defeatist.

And I was thinking about where that came from and I think part of it is just how I was raised. My parents are from the Midwest and just kind of super stolid folks and I remember one time I left the parking brake off of one of our cars and it rolled down the driveway into a neighbor's fence. And I wasn't yelled at, they were obviously unhappy. It damaged the fence, it damaged the car, but they just said, “We need to solve this problem.” And that idea of we need to solve this problem is really something that I've taken to heart in my life. That's just a guiding principle for me.

REIN: What do you do with the frustration that you feel? 

DAN: Well as a Midwestern person would do, I stuff it down. No, I think that it's important to acknowledge it and as I've got older, I do acknowledge that I take a little bit of time. But you can do that on your own, you can do that by taking a walk and then sometimes, I've actually taken to – I don't journal per se, but I definitely will. If I'm faced with a frustrating situation at work, I will write something in a Google Doc and just have that dated. 

So I guess, that's how you have the frustration is I kind of write it out, internalize it, and then set it aside after a certain period of time. I recently got laid off and I felt really sorry for myself for about an afternoon and then I went to brush up my hands and went to work, trying to find a new job. 

JACOB: I feel like that is a terrific lesson for new developers, particularly new developers that are—I don't like the word self-taught—are not coming from a traditional background because speaking as someone who comes from that background as well, you have to sort of find the mindsets of this is a problem that is given enough time and energy, I can figure it out and that took me a long time. I was really convinced well, maybe I can write this program, but there's no way I could do that thing over there and I think that self-efficacy you're talking about is really valuable. 

REIN: So I'm actually interested in that. So you're saying that it took you a long time to feel that you were powerful and knowledgeable enough to tackle kind of any problem? Is that what you’re –? [crosstalk]

JACOB: Yeah! I set a barrier, a completely arbitrary one, for myself. I was just not someone that sort of said, “I want to be a developer,” and then started the journey. I learned about writing code to solve other problems other than finding a job and as I was doing it for a little bit, I was thinking to myself oh, does this mean I want to change careers and get a job as a developer? No, I couldn't do that. I can write a Python script to arrange data in a spreadsheet, but I couldn't do that. That's not for me. But I had no evidence for that. I just sort of set a barrier and the truth is, I could now be two years further in my career if I hadn't done that. So I just think that's a really, really important thing to learn. 

DAN: Yeah, thank you. And I think that one thing that's worth saying is that if you're facing the problem and you don't buckle down and study for it, you're guaranteed not to actually solve a problem. And now there are problems that may be intractable, or you may need to reach out to the resources, team members, pay consultants who have solved this problem before, whatever, which doesn't really [inaudible] new developers, that's more people with ability to hire a consultant. 

But if you can't accept that mindset or find that mindset, you're definitely not going to make progress. I think of Zen and the Art of Motorcycle Maintenance where they talk about finding the right mindset before you start working on the motorcycle and if you can't find that mindset, you've defeated yourself already so.

REIN: What's the first piece of advice that you give to new developers?

DAN: If I had to pick just one, I would say that you're being hired for your potential, not for your ability to deliver, especially in the first five years of your career, and so what you want to do is you want to maximize that potential and you want to maximize how to display that potential. And I have a couple of suggestions on how to do that. We can dive into later if we want, but I think a lot, especially as Jacob was saying, the people that come out of nontraditional backgrounds are expecting to be able to walk in and drop code, or they feel the pressure of having to do that at their first job in their first week and I'll say as a senior developer, it's rare for me to do that. 

Yeah, I want to ship code on my first day, but any time you walk into a system, even if it's a React, vanilla react, a single page application and you just came out of a React bootcamp, or you just finished a bunch of Reacts course, there's so much variation both in the technical system and then in a bigger way, especially since this focuses with podcast, the organizational system, the people and just writing the code is not enough to get stuff done, unfortunately. 

So I think being hired for potential and think about ways to optimize that and then realize that when you're dropped in, everyone has a whole new system to learn and you have to be prepared for that.

REIN: Do you have any advice for getting started a new job? How do you figure out what you're supposed to do? How do you learn the systems and things like that?

DAN: Sure. So kind of a guiding principle I have—and unfortunately, you only get one chance to be a new developer at a new job and my experience with that is 20 years ago. So I can talk about what I did there, not necessarily intentionally, but I can also talk about what I do as I come into new jobs as a more experienced developer. 

But I think as a new developer or as a new employee, it's really important to what I call over-index which is kind of like overclock a little bit. It's always important to bring your best self to work, but I think you have a little more latitude as people know you. And so, I think that first month is a really great time for you to shine and you can shine in terms of taking extra special care when you write a commit message or staying a little bit late or doing a little bit extra reading on the weekend. 

I don't want to force the cult of hustle, the cult of overwork. But I think that extra effort in that I know where you could shine, write down the name of every person you meet so that you can refer to them by name when you see them again. That extra effort you take in that first month will set your reputation for the rest of the time at that company. And you can change reputation overtime at a company and good companies look at results, not just what you do the first month. But I think taking extra time and doing a little bit of extra special shine and extra special effort will pay dividends further on. So that's kind of one generic piece of advice. 

REIN: There’s a psychological effect that first impressions are a natural thing.

DAN: Hundred percent. 

JACOB: What do you think are some things that will surprise someone on that first job?

DAN: Things that surprised me because I have a hard time generalizing—I have a certain lived experience. But one thing that surprised me is that the code is not that important. We kind of alluded that earlier, but the solving the actual business problem or organizational issue is way more important. And that sometimes it can be done with code, sometimes it can be done very elegantly with code, but lots of times it can be done with a manual process or figuring out why you're doing the thing you're doing and taking a different path to that goal. Maybe it's a third-party service. Maybe it is determining that the business shouldn't try to achieve that goal at all. 

Now, again, as a new developer, you probably have a little bit less sway unless you're in a small organization, but asking questions to get to the underlying root of what you're trying to solve, rather than taking the instructions you're given and like an automaton, typing out the code is going to make you more valuable employee. And frankly, I think it'll make it a more enjoyable job for you. So that would be one of the things I would say would be a surprise.

REIN: Yeah, if there's something that seems like a bad idea, then either it is a bad idea or you don't understand why it's a good idea.

DAN: Yeah, and I have never found it to be a bad idea to ask a question respectfully. I think bagging on code or saying, “Hey, it’s a dumb idea because we'd learned how to do it differently in my education is not constructive.” But asking, “Hey, what are the reasons for doing this?” and the person who's directing you to do it will either have a really good set of reasons, in which case you'll learn something or they'll be like, “Huh, that's a good question,” and then they'll go dig into it further, hopefully and come back with an answer that's either “Yeah, we should do it for these reasons” or “You're right, it's a bad idea.”

REIN: Yeah. I think it's really important to try to understand is that everyone is coming to work to do a good job and if you look hard enough, you can generally find reasons for things that aren't either stupidity or malice.

JACOB: Yeah. We had an episode long time ago, before I joined the podcast, that was talking about code hospitality and it sort of related being new to a code base as being new to a city and the person that's showing you around is sort of your tour guide and how it's your job as being introduced to a new code base is not dissimilar from being introduced to a new culture. And it's not really your job – it's your job to understand better and not pass immediate judgment or come in this, “These are how things should be fixed.” It’s just your job to sort of learn the full story and be respectful of your host. So yeah, I thought that was a really interesting way to put it. 

DAN: I love that and one of the ways I've put it is that you will definitely run across code that you roll your eyes at, or you say, “What on earth was this person thinking?” I've done it and I've had people do it to my code. And the thing that you don't have, when you look at it, is you don't have the full context in which that code was written. You don't know about deadlines. You don't know about budget. You don't know about the way the code has evolved over time. And so, you're not going to be very effective if you hire people by the color of their shirt, you shouldn't evaluate code by the first time you read it because you don't have that context. But I love the city guide analogy because that makes it personal, too.

REIN: I also don't like this code. Would you like to know how it got this way?

JACOB: Yeah, it was our first year.

REIN: And why we haven't changed it yet? 

DAN: Exactly.

JACOB: I would like to say, we talked a little bit about not pressuring yourself and not kind of come in and immediately deliver code or feeling like you can’t know everything and that you can't figure stuff out by staying within those arbitrary boundaries. Jacob mentioned that. I think it's also interesting as I look over my career that it's okay to accept your weaknesses, too. And I think you should try new things continually, but if you try new things or you're trying things over and over again and you're continuing to not be good at them, then you need to evaluate, do I want to put in the time and the effort to be good at them or is it better that I pick something else that I enjoy and happened to be good at and spend more time getting better at that?

An example of that for me is engineering management versus communication writing. I do a lot of writing and communication in my current job. I've been an engineering manager a couple of times and both times, I was promoted internally, I ran a team and I would not say that I was the best at it. I felt like I wasn't improving and I wasn't enjoying the process. And so yes, try new things. Yes, push your boundaries. But listen to what the world is telling you, too. It's not like you have to be a hundred percent good at everything; no one expects that of you.

REIN: There are a lot of organizations where management is the only path for engineers. This is unfortunate because they're different jobs and becoming a good engineer doesn't automatically makes you a good manager. I think it's really good to know that there are things that either you don't think you're good at or that you don't enjoy doing and to make a decision for yourself about how you want your career to go, where you want to spend a third of your life. 

Some time ago, I decided that management wasn't for me and that I wanted to stay an individual contributor and one of the reasons for that was that there were aspects of management that I didn't like, but another was that I wanted to stay closer to the work. I wanted to have an impact from a similar position as the other people who were doing the work. So I wanted to be a peer rather than a manager.

DAN: So, one thing that I've said before is that management and engineering are kind of like American football and regular world football, or soccer. They overlap in some ways. They're similar concepts; you're both scoring goals or points and there are players on the field, but it's a whole different set of skills. 

I agree with you that, especially at small organizations, it's hard to – you’ve stayed there for a while, you're promoted, you're maybe a team lead and then you're – I mean, I stepped into director of engineering roles and that was in some ways because the opportunity opened up and I wanted to try it, but in other ways it was because it was upper out in terms of salary, in terms of responsibility. And I agree with you, I think that's shortsighted. I think that we should think about ways for strong individual contributors, especially those who've tried management, and then stepped back. In some ways, those are the best people to be managed.

REIN: There are some companies that have a parallel IC ladder that goes all the way up through architect and so on. They are out there. You can find them. It is nice to not be stuck at senior engineer for your whole career. Of course, for a lot of people, senior engineers, I think they're trying to get to. But what makes a senior engineer, what makes them senior? 

DAN: So I have a blog post I'll drop. I think senior engineer is an overloaded term. It's an overloaded term. There's 15 different kinds of senior engineers. A senior engineer at a small consulting company is going to have a different set of skills and abilities and job requirements than a senior engineer at Google. But the one thing that I see over and over again, across different types of senior engineers, is just the ability to look at a problem in a larger context. 

So you own the whole problem, you own solving it, and you are focused on the actual implementation. Although, you may move up and down the stack and do implementation details, but you really have that sense of ownership and you poke your head up periodically and look around the organization and think of other places you can add value or your team can solve problems with so you’re connective tissue as well. But I like to think that newer developers or junior engineers really are handed kind of problems in senior engineers, understand problems, find problems, and solve problems. 

JACOB: Yeah, and I think it's interesting how—and this is not particular to our industry—the longer you stay with the company and grow with the company, whether you're a manager or not, you're going to find yourself doing manager like duties. Because if you're the senior developer that worked on and knows the most about the CI/CD pipeline, you're probably going to spend a lot of time talking to people, helping them troubleshoot, going to meetings about where to go with it and suddenly, that's going to feel like being a manager. 

And I think it's interesting how quickly you can find yourself being the most knowledgeable about something at your company, whether it's this tiny little corner of the code base and that people might be coming to you for it. You might be telling people what to do about it. I've definitely been surprised about that.

REIN: I will say, I think it can be a little bit of a trap to become the subject matter expert at your company on some important thing. And I think one of the things that a senior engineer should be looking to do is to delegate to level other people up so that they can take on those responsibilities and then you can focus on the next thing. Because the thing that was the most important thing for your company two years ago is probably not the thing that's the most important thing for your company today. So if you always want to direct your impact where it can be the most valuable, you have to learn how to get things up. 

JACOB: Yeah. Now that I feel comfortable in this area, I want to teach two other people to do it and that's a really good point. 

DAN: Definitely. I just love to write stuff down like, I love runbooks and all those other pieces of documentation not just for other people, but for future me, but it really is a good step to step away from things. I mean, I will say you mentioned about impact and wind up working the highest impact thing. I think you're actually looking for the union of what's the highest impact thing you can do that you are enjoying, or you could conceivably enjoy because I've definitely done some high impact things like stepping into management that I didn't enjoy. 

I tend to be a people pleaser and so, I think it's important for developers, wherever they are in their career to say, ‘Yeah, I'll try this. Maybe I'll try this management thing for six months,” or “Be the CI/CD expert for six months, but I'm going to keep tabs on my happiness. I'm not going to fall into this just because the company needs me to do this.” You don't want to play a role for your career and get really good at something that you hate—hate is a strong term. It's all technology, even just something that you dislike or that you aren't excited about. We're lucky enough, a lot of people that they can do some self-direction in their careers. So take advantage of that, don't stumble into things, or maybe I should say, stumble into them, try them and then evaluate, don't continue with them unconsciously.

REIN: So for a junior engineer who's trying to become a no prefix engineer or for an engineer trying to become a senior engineer, how does it change as you advance like, what your manager is looking for, what you need to demonstrate to get promoted and so on and what stays the same?

DAN: So what stays the same is that you need to continue to take on new challenges and succeed in them. I think you need to continue to communicate well, which I scope it down to say what you're going to do and then actually do it. So communicate the problem and then execute against it. I think those couple of things are going to be – I mean, I would be thrilled if I had any direct report that did those couple of things like, took on new challenges and then was good at executing them and communicate the difficulties they had. 

I think again, scope keeps coming up, but as a newer developer, your scope is just smaller. You're expected to know fewer things. You're expected to be handed work, maybe on a platter, depending on your environment. It might be a bigger or smaller platter, but I do think that being able to execute quickly against problems, being able to pattern match, being able to know when you should look for a library, look for a third-party solution, look for your own, write your own code. 

Those are all things that I think change over time. Don't expect someone who's really new to know that they should have looked for library. They're probably going to tell them that, but I would expect kind of a no prefix developer to be able to look around and realize that they shouldn't write their own MVC framework. They shouldn't even start that process. They should know the universe of solutions. Well, not the whole universe. But know that there are solutions out there and then evaluate them and have some way to evaluate them intelligently.

JACOB: And have some experience with anticipating what the trade-offs will be for any given decision or just having instincts that there will be – to ask yourself what the trade-offs will be because there always are. We'll have some problem, no matter what decision we make, and having at least some intuition about well, I think if we choose to do this, we're probably going to be having this problem in six months, but if we do the other thing, we'll have this other problem. 

DAN: I like to think of it like looking around corners or the chess master analogy where I'm okay at chess. I might look one or two moves ahead, but someone who's more experienced might look five or six moves ahead. In all reality, a senior developer is a new developer who has time and mistakes mixed in and that's what you're paying the premium for. You're paying for their mistakes that they've made on other people's dime. That's why I couldn't get hired as a senior developer at Google, probably because I don't have the experience that the senior developer Google needs, the context it needs. So you're absolutely right that the looking around corners piece is a really key thing. 

REIN: If you want a single metric for how senior an engineer really is, how many mistakes they’ve made, isn’t it?

DAN: That's a good one. That’d make me really depressed to think about if I wrote down how many mistakes I made, but actually that would be a great interview question. I think that'd be – especially the second or third interview when you have some trust built up, because asking about mistakes that they've made is kind of like, “What's your greatest weakness?” like, you don’t want to play that as a candidate. 

But I think if you would have an honest conversation about a mistake they've made and how they've rectified it because that's the thing about mistakes. You don't just get to make mistakes and then drop your mic and leave. I mean, you have to acknowledge them, rectify them, and then try to make sure you prevent yourself or other people from making them in the future. That, to me, would be an interesting interview question. I've never actually asked that in an interview but.

JACOB: If a new developer gets that question or any one gets that question in an interview, what's a good way to go about answering that? 

REIN: I think my greatest flaw is that I work too hard. 

DAN: Yeah. I'm a perfectionist. I'm a perfectionist. Well, first of all, I think if you don't feel safe talking about a mistake in an interview, that's actually a really good warning sign. If you feel like it's a gotcha question, that indicates to me that they aren't very good at interviewing or that that kind of organization doesn't really like mistakes, in which case, red flag. So setting that aside, assuming you feel like you can actually answer that question, I think that the same way with the greatest weakness, you turn it into a strength. You want to say, a mistake. I would pick something that is big, but not too big and then I would talk about how you fixed it. 

So an example from my life is I was working at a startup. We had a payment system, our customers were getting payments from their customers, and then we were passing that on to them. So it was kind of a pass-through model. So that was a really key piece of our infrastructure and I screwed up how we calculated things and the actual details of how I screwed up don't really matter. 

What happened is, I discovered the screw up. I talked to my team about it. I then fixed the screw up, so I wrote tests against the system to make sure that up would never happen again and then I called the customers and I said, “Hey, here's what I did. Here's how much money this cost you. We’re figuring out how to get that money back to you.” I don't honestly remember whether – it was far enough back in time that we just wrote it off because it was hundreds of dollars. It wasn’t thousands of millions. 

But the point is, I went there and we talked about how we solved a problem. They didn't really care, but I talked about internally, like the test that I wrote to make sure this would never happen again. So that's how I would answer that question if someone asked me in an interview. You don't just say, “Oh, my biggest mistake is that I screwed up a payment system and cost my customers money.” You say, “And then I took these steps.”

JACOB: Yeah.

REIN: You might just add, “And this is what I learned.”

DAN: Great point, “This is what I learned.” And in some ways, you could even, if you want to be really proactive or if you're a more senior person, you might say, “And this is how I prevented everybody else in the organization” or better yet “the world from making these mistakes.’ “I wrote a blog post about it.” “I usually use the library.” 

Again, for a new developer, that's a big ask, but I think that how I learned from it and whether that's writing it in your journal, writing a script that you don't do it in the future, or just studying, whatever the issue was so that you can really deeply understand why you made that mistake really puts a bow on it.

REIN: So there's a thing that a friend of mine told me once. Edward Kmett, who wrote a hundred Haskell libraries and is very good at writing code, he said that he always looks for this solution that other solutions factor through. So he always tries to find the most general solution to a problem. 

DAN: I'm not a Haskell person, so I'm not familiar with that term. But I mean, I understand the generalized solution. I think that one thing that you want to be careful of is you want to do that at the right time. If I'm writing a shell [inaudible] to load some data to a database table once, I don't want to use the most general solution and write tests for it or anything like that. 

So you do want to pick a solution that is appropriate for the problem and this gets back to what Jacob said about trade-offs and being a mature engineer is about understanding the trade-offs and saying, “Well, gosh, I'm doing this one time. I'm going to write this in Bash and maybe I'll check it in and if people start to use it again and again, then I'll turn it into a Python script and I'll test it” or whatever. I do think that you do want to try to solve a problem that at the appropriate level of effort. 

REIN: I think another way he meant it is so he's a data structures person, so if he's trying to solve a problem with a data structure and that data structure has certain access patterns, he wants the one that has better asymptotics and better constant factors and all the algorithms. If it exists, he wants to find it and use it. He doesn't want to find the less good solution on some dimension when the better one exists.

DAN: So again, I think that's a really good sentiment. The unfortunate truth is that the universe, Rein is like, I could spend all my time trying to understand the npm ecosystem and probably still not get through the whole thing. So at some point, you need to know when to stop, to stop the algorithm when have I satisfied. So… [crosstalk]

REIN: I think that might actually be the thing that makes him a senior engineer is knowing when it makes sense to look for that solution.

DAN: And when to stop. 

REIN: Yeah. I think you're exactly right. He finds these incredible solutions, these data structures. So one thing he does is he moderates papers like computer science papers’ subreddit. I mean, he does that so he can get access to all the good papers and so, I learned a lot from him about how to do research, about how to sort of build a mental catalog of solutions. And I think that's what he's really good at is knowing when it makes sense to pay the cost to look harder, like you’re saying.

DAN: Yeah. I feel like probably the first five years of my career, I spent learning—I'm using big air quotes—“the right way to do it” and that might mean the right tool or the right design pattern. And I think the phase I'm in right now is sort of learning to be okay with writing ugly code when it suffices. It's definitely a process, but I think what it's coming down to is like, is this meeting the business goal at this particular time and if this is leaving any technical debt and [inaudible] is it worthwhile? And then I can go write beautiful code on the weekends for fun.

REIN: Yeah. There's also a big difference between someone who's writing a library where they want to present some solution that's going to be used by thousands of people. So all of the work he does to make the library better in that way is magnified versus you're writing an application and you just need to get the thing that works to solve the problem. The other thing is understanding the significance of context.

DAN: Well, it's interesting because as I look back over my career, I think that there's this spectrum of pragmatic versus perfectionist in what you actually enjoy, too. So Jacob, I mean the fact that you're being forced to write code that isn't perfect to meet the business need, it's good that you're taking one for the team. That may indicate that if that happens for a long, long time, that may indicate that this is not the right job for you, or that you might need to shift things. 

And so, I actually tend to be more pragmatic and get stuff out the door and that means that all of the things being equal, I'm probably shipping lower quality code than I could if I spent more time polishing things out. Again, if you're producing a library, because that magnification effect, or if you're working on a product or something like that, it makes more sense to invest because it's going to be amortized across greater numbers of users.

So I think that actually new developers can use this to guide their career, too because different companies have different standards. Just frankly. Code that you're going to write for Google, you're going to need to think about a lot more things because it's executing against or executing on lot thousands of servers for millions or more users. Whereas, you go to a startup and you're just cranking stuff out to deliver something that you can actually test against the market. 

And so the quality of code—again, I'm not advocating writing garbage code. I just think that anyone who pretends that there's not a difference in quality between those two scenarios is not lived either of them is my guess.

REIN: I will advocate writing garbage code.

DAN: Bold, bold statement.

JACOB: Me too.

REIN: So the most general version of this, here I am doing that thing, is what Erik Hollnagel calls the efficiency-thoroughness trade-off. So he researched this in the context of human factors and safety science and so for him, the efficiency-thoroughness trade-off, the relevance for him was around how do we manage risk? So how safe do you need to be to be safe enough? That sort of a thing. And the answer is, you make an efficiency-thoroughness trade-off. You could be more safe. If we wanted to be safe, as safe as possible, we would never leave the house, we would ever handle knives, et cetera. 

So we're all making this trade-off in how safe we need to be to do our jobs, to live our lives, and this is true for how – all of the things we've just described can be thought of as trade-offs. But I think you have to get good at making those. A build/buy decision is one of those. I think getting good at recognizing and making efficiency-thoroughness trade-offs is one of the key skills for anyone ever, but especially for engineers, because we make so many of them like every line code we write. I could do this better, but it would take longer. How many tests are enough tests? How pro forma does it have to be? How much should I optimize?

DAN: Yeah, and at the same time, I think that you need to – certainly, I would assume most people certainly are thinking about that every line of code they write. It becomes intuitive and that's one of those things that it's like muscle memory for an athlete where you just think okay, I have this understanding of kind of where we are and it's a gestalt and I'm going to take actions against that in terms of thoroughness and efficiency and back to the mistakes and accept that I might make a mistake. And guess what, accept that if I pick the wrong library or if I don't search far enough on the one side or I searched too far on the other side, those both have ramifications, but I tend to adjust and I can help fix that issue.

REIN: Have you noticed that when you were writing code and you have to make a decision about how to structure some class or some other thing, that you're not actually being analytical about the decision? You're not thinking of five different options and comparing them most of the time. What you're actually doing is you think of a thing and then you decide whether it fits the problem, then if it does, you do it. 

Gary Klein studies this, he called it recognition-primed decision-making and the interesting part about it for me is where does that idea come from and that's where the recognition prime bit comes in. So we use our experience, we use the mistakes we've made, we use our experience in similar sort of rhyming situations to come up with a candidate and then we evaluate the suitability of that candidate. Not against everything else that we could possibly do, but just against the problem itself and it turns out if humans were actual analytic, rational decision-makers all the time, we could never get anything done. 

DAN: It’d just be analysis paralysis all the time because the universe of decisions is too big and people sometimes ask, I'll talk to nontechnical folks who have an idea and they'll say, “What should I build this in?” or “What should my team pick?” And the answer is often, “What do they know?” Because that’s, I wouldn't say it's 90% of battle, but depending on situation, it may be half the battle because for a lot of solutions, the actual implementation details don't matter. I mean, they matter to us working on it, they matter long-term, but lots of times I'll be talking to people just starting up and the answer is just to get them out the door as quickly as possible so you can get real world feedback.

REIN: I can never remember the author of this quote and I can never remember the exact quote, so I have to paraphrase it, but it's, “A computer isn't a hard drive and a graphics card, a computer is a screen and a keyboard and a mouse.” That is what a computer is. So we interact with everything in our lives through representations and so in this case, the implementation details are hidden by the representation. So the customer doesn't care that it's in rails, the customer cares that it does the thing they want.

JACOB: Yeah, exactly and I think that's a really good tip for new developers on their first job is you may have learned typescripts, but there's so many other factors in deciding well, should we rewrite this in typescripts? Well, how many people have sat down at the company know typescript quality [inaudible]? How much work would you have to invest just to get the app to build in typescripts before you can even think about enjoying the benefits of it, in terms of increased efficiency, and I think that is something that just comes with experience. 

DAN: I think there's actually another level, which I'm kind of two minds about, and the two other questions you might ask to the manager are: how excited are the developers about using typescript and how many other developers can I hire who use typescript? Because if you're looking at a long-term project, those other things have to factor in. I'm not a huge fan of letting developers just pick whatever flavor of the month they want to influence something in, because I think that leads to problems down the line. 

But I worked at a company where I was the director of engineering and it was a Java company and I just said, “Hey, everything has to be implemented in Java, Java, Java, Java.” That constrained our hiring market and I'm not sure it was the right solution when we were confronted with the problems that were different enough that another language like Python would have been a better fit. So there's so many dimensions to balance around any technology issues in trade-off. Those are two more that I could think of around Xscript for an application.

JACOB: Yeah and it's your job to be thinking about the developer at your firm now because a developer, or perhaps not even a senior developer, is necessarily going to be thinking about how will this affect someone who [inaudible] this year. I mean, they should be, but they might not have that experience or they might be having other constraining or other competing interests going on that have led them to choose Python. 

But I mean, I think something that we don't always think about when you sit down to write new code is we're thinking about like, am I setting or reinforcing a best practice in the future and does this best practice, is it actually reflective of the company as a whole, or is it really [inaudible] that I'm interested in and what are the long-term consequences of that?

PRE-RECORDED SPEAKEREIN: We'd like to take a break in the show to let you know that today's show is sponsored by strongDM.

Managing your remote team as they work from home? Managing a gazillion SSH keys, database passwords, and Kubernetes certs?

Meet strongDM. Manage and audit access to servers, databases, and Kubernetes clusters, no matter where your employees are.

With strongDM, easily extend your identity provider to manage infrastructure access. Automate onboarding, offboarding, and moving people within roles. Grant temporary access that automatically expires to on-call teams.

Admins get full auditability into anything anyone does: when they connect, what queries they run, what commands are typed. It's full visibility into everything. For SSH, RDP, and Kubernetes, that means video replays. For databases, it's a single unified query log across all database management systems.

strongDM is used by companies like Hearst, Peloton, Betterment, Greenhouse, and SoFi to manage access. It's more control and less hassle.

strongDM. Manage and audit remote access to infrastructure.

Start your free 14-day trial today at strongdm.com/SDT

REIN: Sometimes when we think about being a senior engineer, we think about taking on big projects and having this huge impact in that way. Sometimes I've found that some of the stuff I do is a smaller thing that has more reach. So I kind of think of impact as being a combination of breadth and depth.

As an example, I fixed a problem with the way we were testing logging and this fixed like 5,000 specs. Well, it fixed like 500 specs, but it also gave people a new way to write these specs that didn't break. So the problem was that if you added a new assertion somewhere else in a different file, it could break the logging test and I found a way to fix that and this was a small thing. It was like the actual file that implemented it, it was like 50 lines, but it solved a lot of small problems for a lot of people. 

DAN: Yeah. I think that's a different kind of senior engineer or different aspects maybe of being a senior engineer is to provide that leverage across an organization and over time, too because you didn't just sell the problem for one little thing, you solved it for forever, or at least until the logging framework changes or whatnot. 

REIN: Yeah, and I could have just fixed the way I was writing my test. But what I noticed was oh, this is actually happening all over the place and if we just do it slightly differently, it doesn't have to anymore. 

DAN: Right, and that's the great thing to think about scope. A junior engineer or a newer developer with the same knowledge base or the same ability to do the research might have solved it at a smaller scope, but you had the ability and my guess is, that you also had the connections and the political capital to be able to push this up to be more of a standard, right? And that’s the – [crosstalk]

REIN: Yeah, actually the hard part wasn't writing the thing, the hard part was getting people to realize that there was a thing now.

DAN: When I started out as a new developer, I thought that the code was the most important thing and what you just said, Rein is getting people to know about the code is in a lot of ways more important than the code itself or on par because if you have perfectly beautiful tested, lovely code that no one knows about, what have you done? Well, you've solved your problem, but you haven't helped anybody else.

REIN: And if I solve that problem perfectly for everyone and no one knows about it and no one uses it, then I didn't actually do that. So do you have any advice for how, if I’m let's say, a junior engineer and I come across some small problem like this and I think oh, I have an idea that could help the organization, what do you do? How do you actually get people to care about that thing?

DAN: That's a great question. First of all, it's going to totally depend on the organizational dynamics. Something that is a product company or a consulting company will have totally different approaches to this scenario. So, first of all, I would say it'd be good to one, make sure you actually solve the technical problem. That's kind of a given because if you think it solves a problem, but it actually doesn't, then you end up with egg on your face. So that's the first step. 

I think going to and building relationships outside of your team in a formal way, which if you're a hundred percent remote, that can be difficult in different ways, but having those relationships will allow you to maybe show this to people on other teams or to show this to people at different levels and say, “Hey, I have this thing that I think will help. What do you think of it?” If your company has an open source culture, then you could open source it and kind of expose it that way. If you have a side project, you can use it on. 

But I think proving that it will actually solve a problem and then talking about it in whatever means your company uses to communicate, which points out kind of the preface is that you need to understand how your company communicates, and people to ask that question of or people have been there for a while, your manager. A great question one-to-one, if you don't have anything else to talk about is, how do ideas get disseminated around here? I think that your manager should – if your manager doesn't know how ideas get disseminated again, that's a warning sign like, they should know.

REIN: It's easy to look at this. I mean, we're sort of talking to or about junior developers, but how successful they are in that situation has a lot to do with the organization. Probably more than them themselves. You can do everything right in that scenario and nothing happens in some organizations. So I would sort of also make this a challenge for leaders; how do you build an organization in which that good idea can get traction?

DAN: Yeah. I think that good organizations look at where – have a way of evaluating ideas and mapping them and that is actually interesting point is the junior developer may, from their vantage point, have a solution that solves a problem. But somebody else from a different vantage point may realize that it actually causes different kinds of problems. 

So what you want to have is not necessarily a way for every idea to get implemented, but it's just a way for every idea to get evaluated and had a conversation about it. And guess what, if you have a junior developer come up with a great idea and they shout and it goes into the abyss and nothing happens to it, they're not going to come up with their other ideas. Whereas, if you have a conversation about it and you say, “Hey, we can't implement an app because of a, b and c but please come up with your ideas,” they're going to continue to have great ideas and continue to share them with you.

REIN: I think that's a great point. There's a difference between the importance of trying things and the importance of finding solutions. It can be very worthwhile to try something that doesn't work.

DAN: Just having an audience of your peers to be able to tell it to. This is something I learned because I think even the very low stakes accountability—it's not even accountability, it's just like I know I learned better when I know that I have to present some kind of deliverables to another person. Even if that deliverable is just like, this is a five-minute talk about what I learned. And I think when peers can sort of form that community where they sort of encourage each other and become a sounding board for each other, that idea that we're talking about that you might come up with, a management can form a team where people are just free to share those ideas with each other and help each other learn. I think that's maybe even a bigger win.

JACOB: I love the idea of a peer group. Two kind of things where I've seen that happen in my career are brown bag because it's super easy to organize a brown bag and it works so many other skills and the other is if you don't necessarily have peers at your company is, and maybe this is me being Pollyanna, but I encourage everybody to start a blog because you can write that. I'll tell you, you actually really learn it when you're trying to explain it to other people on the internet and you don't know who that's going to help in the future. Like I've had totally random people stumble across things I've written on my blog and say, “Oh, thank you, this really helped” or “This message meant a lot to me,” and to me, that's super inspiring and encouraged me to do more. 

But that's a way you can kind of find a peer group and you could use something like dev.to or Hashnode or something like that to kind of combine those two things. But I love the idea of group accountability being a way to drive learning and make it learning deeper.

REIN: So I'm really interested from your experience as a manager, a director, a CTO, and so on, how do you make an organization where junior engineers can thrive and grow?

DAN: I don't have a lot of good experience in that, unfortunately. I've mostly worked at smaller organizations, so I can speak to how I tried to structure things there. The CTO piece, I put that on my resume and my bio because it's true, I was a CTO. But just like there are different kinds of senior engineers, there are different kinds of CTO. I was a CTO of a two-person startup and that's totally different than it being a CTO of a 10, 50, a 100, 500-person company. So I was really a founding engineer, even though my title was CTO. 

But as far as helping junior engineers, when I've been director of engineering, I think putting the roadmap of successes and it's a really uncomfortable thing to do because things are so fluid. But I think doing things like ownership of tasks and saying, “Hey, you can complete a ticket without asking anybody.” The goal is not to have people not ask; the goal is to get someone to the point where they're comfortable doing that. So setting out goalposts that they can kind of check off and say, “Hey, this is” – 

I've gotten to a certain level because part of the frustration I think as a new developer is, things are so fluid you don't really know how you're progressing and so, putting some real goalposts there, I think would be helpful. 

The other thing is, I always have this rule of don't spend more than 30 minutes banging your head against a problem before you ask somebody. I think that is really important for me to kind of foster that culture of help and communication and I think that rule doesn't mean that someone's going to give you the answer within a 30 minutes. It just means that you should do some research, you should try to find the solution and then if you can't, throw up your hand and ask for help. 

And that helped maybe someone rubber ducking with you and maybe someone saying, “Oh, you actually should just go over here, it's totally documented in this other document you didn't know about because you're new this company organization.” Or it could be somebody saying, “Gosh, I don't know. You need to figure this out.” Or “Maybe I can Google with you a little bit.” But having that stopping point, I think for new developers prevents them from heading down a rabbit hole and spending five hours researching something that somebody might be able to help them with. 

REIN: Thank you. So you talked about starting a blog, you yourself have a pretty good blog. It's pretty cool and I understand that you're turning it into a book?

DAN: So I did actually just publish it. It came out August 16, 2020, for those of you listening five years from now, and it was a really great experience to take the blog posts, rework them, add new content, put them into ten-minute sematic chapters and then get them reviewed by other people I respected and go through the book publishing process. I have yet to actually hold it in my hand. I'm hoping to get some copies of this week, but a tremendous amount of work and I have a tremendous amount of respect for anybody who does something that's less episodic. Like, my letters are all a couple of pages long and I group them by scene, but they're not really contiguous. I don't have character development or I don't have a thought that I have to kind of bring through 10, 20, a 100 pages. Book writing is hard. It's hard.

REIN: So it's an edited collection and then what was the work like to turn it into a book?

DAN: So I basically wrote some software, it was garbage software, to pull down RSS feed and turn it into text files and then I used Word and I basically gathered them into chapters and then I read them and reread them and reread them multiple times, multiple passes to make sure that things flow together well, that it was not missing any important concepts, and then I ended up writing more stuff, more letters that I hadn't published on my blog previously. 

Yeah, that was other interesting things there. I included a selection of other people's contributions because one of the nice things about my blog now that it has a certain amount of following, a certain amount of traffic, people actually want to write for it, which I think is a really interesting thing for me because one, it brings different perspectives to the blog and two, I can actually elevate different voices. I'm trying to reach out to underrepresented people and make sure that if they want to write – I mean, I realize I'm not offering a job. I'm offering a chance to write for free. So it's not a golden opportunity, but it is a platform of some kind. 

So I pulled some of those folks, some of those letters into the book, and I just liked that because one thing I've realized as I talked to new developers and I talked to people on podcasts and I talked to other people about developer careers is that the context matters so much and so white male middle-aged hetero in the US, my context is one thing and so, I love to bring in other voices to provide other perspectives.

REIN: So how big is the book? How many blog posts did you write?

DAN: It's about 10 chapters, about 210 pages, 215 pages. So I actually don't know the count of the blog posts that made in the book versus the ones that didn't, but the short chapters, like 15 pages on community, I think and your role as a developer in the community and the longest is on career and it's fun because—well of course, I think it's fun, I wrote it—there's super tactical advice like somebody wrote a letter about how to appear at a job fair because this person has worked at bigger companies and goes to job fairs regularly and I haven't been to a job fair in I don't know, it's been years and years since I went to job fair. But current situation outstanding, eventually job fairs will happen again and for a new developer, that can be a really great intro into a company that they might not have an opportunity to work at otherwise. 

And then there's some stuff that's super strategic like, how do you learn and how can you find out the best way to learn, which the answer spoiler is mostly just try different things and see what resonates. We can stop talking about the book. I just wanted to – I know it's one of the, I would say, crowning achievements of my life. Like I would say doing a startup that actually made money, writing this book and then surviving as a contractor for years are probably some of the crowning achievements of my professional career.

REIN: Can we talk about the community part? That sounded really interesting. What was that about?

DAN: Sure. So, and actually I had a reviewer say thank you for including that because a lot of technical books don't really focus on that. But I basically talked about the different kinds of communities you can be part of and how they can help your growth as a developer and I talked about things like meetups or online communities. I know that a lot of people don't like Hacker News very much and I think that it's okay in small doses like Twitter, but I think that communities like that can really accelerate your career. One, in terms of just making you aware of the universe of possibilities; we talked about trade-offs and knowing how to evaluate things. The first step to evaluating something is actually knowing that it exists and then you can take other steps. Hacker News has been important to me in terms of that, other communities are as well. 

So I talk about meetups. I talk about conversational hooks. I talk about online tech communities. Oh, great posts about you get what you give kind of a give first post and actually, this is something I'd like to mention. I think it’s so important as a new developer that you take care of your work community. I think a lot of people only reach out to their former colleagues when they're looking for a job, which I think is a totally legitimate thing to do like you're looking for a job, reach out to your former work community. 

But it's way better to reach out to them proactively and give them value, keep in touch with them, go to coffees with them, send them links that are interesting. There's a lot of low effort things you can do to keep your work network alive and interested in you. Maybe initially just aware of you. And then when it finally comes to switching jobs, it'll be like a warm intro as opposed to a cold sales call. I haven't talked to you in five years, “Hey, can you give me an intro to whatever person?” 

So I just like to provide that and I think that more developers should do that. And I don't think it needs to be sleazy, I don’t think it needs to be scummy, I don't think it needs to be transactional, but I think like any other relationship, you should be conscious of your work relationships. 

JACOB: So you get questions from your audience or your readers? 

DAN: Some I had one person talked to me about how they should prepare for a Facebook interview, which I was the wrong again, context like, I've worked in small companies most of my life. I Googled around a little bit and I told them. I was honest. I said, “I don't really know.” That’s one of the things about writing a blog, if anyone's thinking about that, is that you'll spend a lot of time writing stuff and you'll get very occasional bits of feedback. I had people at meetup say, “Hey, I really appreciate it, but not too many questions.” I'd love questions. If anyone's listening to this and you want my advice; advice is one of my favorite things for people to give and I'd love to give advice so happy to answer questions.

REIN: What, from this conversation, would you want a junior developer to take away the most?

DAN: Sure. I think that the one piece of advice that I would want a junior develop your takeaway from this is build your mental muscle around trade-offs and thinking about trade-offs and even going so far as to ask people. When you see a decision that you're questioning, think, ask, don't just ask them why a decision was made—we talked about that earlier. But ask what the trade-offs they consider for. I think that would be a great thing to help you internalize that. 

And I always say that there's two ways of learning something. If you are told the stove is hot and if you touch a stove and you will remember them differently. But even though, when you ask them about the trade-offs that they're thinking about, you're in that first phase of ask, learning a stove is hot, you can still pick up useful information from it.

REIN: I like that a lot. I think the flip side to that, for senior engineers, is to get good at externalizing your thought process.

DAN: Definitely. 

JACOB: My reflection in just thinking about talking to junior developers. So many junior developers now, or just developers in their first job, are not coming from a computer science background. We’ve been thinking a lot how there are experiences that you, new developer, have that people with more coding experience don't and your new employer might find are actually more valuable than five extra years of coding experience. And they could be, for example, from if you came from a previous career, if you majored in something else in college, if you just have a life experience that's different from most other developers because you're not white, you’re not male, et cetera, et cetera and hopefully, those experiences will be valued by your employer. But I think that those unique experiences can absolutely be shaped into being excellent at your job as much as what you know about code.

REIN: I think my reflection is that we've been talking a lot about what junior developers can do to grow, to learn, to improve and I think it's really important to point out that a junior developer is working in a context that has a lot to do with shaping how they think, what they think about, what they can do, what they can't do, what is easy, what is hard. And so, I think the flip side to asking junior developers to consider trade-offs more or to do any of these things, is how would you as a leader make a context in which that's an easy thing to do. I know I'm sort of a broken record on this one, but the context we're in when we're thinking change is how we think.

DAN: Cool. So on that point, I would say that if you're a new developer and you're interviewing a place, you want to suss out as much of that context as you possibly can because you want to ask how do people progress, what's the learning support like here? Because if you have a choice between a job that pays well but you're the only technical person there, or the support system isn't there, or that doesn't pay as well, but actually will provide the ability for you to learn and grow and be mentored and whatnot. I don't understand your financial situation and I don't judge you for taking the higher paying job, but I can tell you, you'll be better served in your career long-term by taking the lower paying job where you can learn more. 

That's not my reflection. My reflection is actually a personal to-do. Like, it was really interesting to me to kind of talk about the trade-offs and how you make those decisions and I had kind of arrived at some of the things I said here empirically, through my own life and it was really interesting to hear what Rein said about efficiency-thoroughness trade-off and recognition-primed decision-making. So my reflection is, there's some theoretical knowledge out there that I would be benefited by reading more about and learning more about. So I'm excited about that. 

REIN: Cool.

DAN: Thank you. Thank you for having me. This is a really interesting discussion, I really appreciate the time so.

REIN: Yeah, thank you for coming on. 

JACOB: Thanks for coming on. Yeah, I think this is like a really, really great fit for our show.

REIN: Yeah. I think it really demonstrates why we call the show Greater Than Code because all of the things we were talking about were very explicitly okay, there's the code, but look at all this other stuff. 

DAN: Yeah.

REIN: Thank you so much for joining us. 

DAN: Yeah. Thank you very much.