Ep 12 – Mastering Communication As a Developer – w/Tim Bourguignon

Tim is a Mentor, Consultant, and Podcaster at DevJourney.Info.

What we talked about:

  • Most rewarding interactions with Developers
  • What is exciting about building things
  • The Hard Part about software development
  • Communication
  • Mob and Paired Programming
  • Talking to different groups and their languages.
  • Mentoring
  • Listening and Re-Phrasing
  • You can be a mentor even if you are one step ahead.
  • Do you have to code 24×7 to be successful?


Long Lost Art Of Mentoring Presentation



Douglas Hirsh: [00:00:00] welcome to another episode of the junior to senior dev podcast. I’m Douglas Hirsch,
Tyler S. Lemke: [00:00:06] and I’m Tyler Lemke. And today we’re here with Tim . Did I say that right Tim? Or did I totally mess it up
Tim Bourguignon: [00:00:13] almost right?
Boom. The French would say no from the burgundy regime. Yeah. Bugging you. Okay.
Tyler S. Lemke: [00:00:19] Okay. Well, I tried at least I didn’t do it super American, so
Tim Bourguignon: [00:00:22] I tried my best to good. You did good.
Tyler S. Lemke: [00:00:25] So Tim is a, he’s a mentor. He’s also a podcaster. he’s a consultant. And would you like to introduce yourself to him? What, what, what, what do you define yourself as, I guess what’s your identity.
Tim Bourguignon: [00:00:37] Okay. I guess you, you read almost everything up, so I’m a people person. I’m trying to connect people together. I’m an engineer at heart. I’m not allowed to code anymore at work. I’m not sure if that’s a good sign. basically I, I transitioned more towards the people side and trying to get people who stuck with one another.
being as a consultant, being in my company as a chief learning officer, being as a mentor and evenings, or whenever I can not being a podcast host, that’s always the same thing. Getting people to talk with me or with each other.
Tyler S. Lemke: [00:01:11] That’s great. Looking at your, so your, your PA if you want to go check out Tim’s podcast is Jeff dev journey.info.
And it’s really interesting cause there’s, I see a lot of overlap between our two. I haven’t checked out all your episodes or anything, but I think it’s interesting that you’re so
Tim Bourguignon: [00:01:26] you kind of.
Tyler S. Lemke: [00:01:28] Through your podcasts, from what I gathered, you tried to get, a very diverse background of people’s journeys into different, sections of software development so that, your listeners can, try to maybe copy their process or no, no.
The different things that are out there is that kind of, your motive with your podcast.
Tim Bourguignon: [00:01:44] Absolutely. Absolutely. So I come from a very traditional background. I have a, an engineering degree, a master’s degree in engineering with specialization in computer science. So really with what you, what you imagine is the computer scientist.
when you look at it from a, from a 20,000 miles away, but. In reality, we’re the, the anomaly nowadays. And I discovered this the hard way I was consulting for a German bank and they asked me to do some job interviews, throwing candidates at me, and I was doing the interviews and after 20 interviews as well.
Well, let’s, let’s, let’s press the big post button and, and rethink the whole thing. It just wasn’t going great. I wanted to reject never one of them and nah, no, it was, I was not supposed to be this way. And so I picked up my phone and started calling people I knew from conferences and et cetera, and asking them tips.
So when you. Search for someone. W what are you looking for? What’s important for you? What’s, what’s a good developer. And beside getting interesting tips, I started getting stories and realizing all the things. I didn’t know, people coming from bootcamps and who were talking at giant conferences in front of, hundreds of persons and, people who had a career before 10 years, 15 years doing something else, entirely being a nurse, for instance, and suddenly said, well, I need the flexibility of being able to work from anywhere and move around and still be able to do the same job.
So let’s go with developments. Why not? Hmm. I was just abashed. That was just completely new you to me. And I’m very curious by nature. So I started recording this and asking more questions and even more questions, right. Asking my guests, Hey, do you know us, someone that has an interesting story and we’re now a hundred.
18 episodes in, and I’ve still have people to come in and I have new stories that I’ve never heard. And I just want to hear them all. It’s a bit like Pokemon, so I would say, but it’s, it’s, it’s, it’s, it’s, it’s fantastic journey. It’s fantastic journey for me as well. So yeah. That’s the deal behind the podcast.
Tyler S. Lemke: [00:03:51] I think both Douglas and I really enjoy the aspect of getting to know people. And w w we actually Douglas, I met at, Add some, add some meetups and we connected. The second time that we’ve met is when we really connected and started understanding how much we, shared a shared very similar ideas and, and kind of, with a learning and, and software development and things like that.
But, yeah, I think it’s fascinating. There’s, there’s tons of questions that we have for you, but I think it’s, I think it’s a fascinating to get to understand other developers and to, A tick to dig more deeply than kind of the surface level that you get from maybe just social media, how what’s the most.
now you’ve done, you talk a lot about it, mentoring, and you talked a lot about, podcasting at least in your, the episode 100 where he actually, where you actually interviewed, by the, I forgot, I forgot his name.
Tim Bourguignon: [00:04:41] I’m sorry. Say,
Tyler S. Lemke: [00:04:44] okay. Yeah, he was the first person you interviewed on, on the, on, on your podcast.
Right? So that’s pretty, I like that. I love that type of symbolism and stuff, but the. What’s what’s the most rewarding thing to you? What’s the most rewarding relationship? Is it, is it surface level stuff? Is it going deeper? Where do you find the most? the most rewarding interactions you have with developers is on your podcast.
Where, where are those most rewarding interactions?
Tim Bourguignon: [00:05:09] I, I wouldn’t pinpointed at a geographical location or a special situation. it’s mostly. When you, you, you manage to trigger interest. That’s that’s the most rewarding. I try our to always leave the discussions I’m I’m involved with, with an open door at the end, and try to, to leave something open, or we talk about the subject, whichever that is, it can be technical.
It can be a metal level. It can be organizational whichever. And at the end of it, I tried to open the door again. So if we managed to close a topic and we, we had the feeling, we understood everything that I tried to throw a curve ball the end and say, Hey, there’s more and more. And that person, a couple of days, a weeks later, Comes back and say, Hey, I float about this and this triggered me to research a bit more into it and, and come back to me that that is the most rewarding.
This is, I did my job. I helped this person grow. Without me being there, guiding and, and, and holding them your hand. And this is the most rewarding. So mostly that is in a, in a mentoring discussion or, or at work with my teammates, with my, my, my colleagues, whichever, there’s always the beginning, some kind of, of hierarchy, relationship I’ve been in the company for 10 years.
I’m in the top management now. So. I’m always seen as well. I’m one of the old guys and when a newcomer comes in, there’s always, well, how do we relate to one another? And you kind of push them and they don’t know how to, how to behave with you, et cetera. And there’s a lot of, of, yeah. Guiding and really, really being beside them for a while.
And at some point, yeah, they just leave and come back. And this is, this is really the best, this really the best. So it can happen everywhere. It cannot be everywhere that can be with my mentees. It can be with my mentors when I try to, to step up and push them as well. That can be with my boss when I tried to coach him.
which is not always like, but. I tried to do it anyway. Oh, it can be with my colleagues or maybe with you today. We’ll see. Yeah.
Tyler S. Lemke: [00:07:22] I’m waiting for a waiting for the curve ball. You’re going to leave at the end. So we actually, we actually, we tee it up. We tee it up for you though at the end. We are. So I think you’re going to have a good thing
Tim Bourguignon: [00:07:31] looking forward to that.

Tyler S. Lemke: [00:07:38] You let’s, let’s start off with your background a little bit. I know inside the episode you talk about when you were growing up as a kid, you were into, video games and you had to learn you kind of learning English because all the video games are in English, which it’s kind of a funny paradigm.
Cause you don’t think about those things when you come from. You know, when you come from the States or whatever you do, like you don’t even think about, Oh, I have to go learn this other language, go have fun. And I think I would have been the same way probably. maybe I would have been too lazy, who knows, but, you said you were really interested and you want it to be an architect, like a real architect, not a software architect when you’re a kid.
what interests you so much? I don’t know if I got this from the episode. Maybe you saw said it, but I was thinking like, what, what interests you so much about building things? What, what gets, what gets you excited about that?
Tim Bourguignon: [00:08:24] I think it’s having something in your mind and seeing it, take shape afterwards and in real life, as much as software nowadays can be in real life.
But anyway, but when we’re talking about real real buildings, it was really having this idea in your mind, trying to translate this onto paper or whichever software. When, when I was still interested in there, it was more people than software and then into software and then seeds, emergency devolve.
I just renovated my house and we had the same process going from my ideas and then laying this down on paper and then trying to see how that could happen and then seed. Happen in real life and see them emerge this thing that this process, I find it very rewarding and very fascinating. And I guess it’s exactly the same thing that you have in software.
You start with an idea, you have this, this, this giant construct in your mind, that can be, an architecture, high level architecture. That can be a low level architecture. You can be talking about classes. You can be talking about patterns, whichever, Level of granularity you are you’re at, and then you try to conceptualize this and slowly, there is something real that emerge as real, they can being software.
And, you always, yeah, I have this complexity of, of, transferring those information to somebody else. So when you’re talking with another architect in the real world, building of buildings or, or talking to, to the, the persons who will, actually build the, the construction of the end or, with all the developers.
That’s exactly the same thing, Frank, to, to, to convey those ideas and do the ideas you have in your mind and, and see them, come to fruition. So I guess this process is, is what I’m, I’m I’m in love with, and yeah. That’s yeah, that’s, that’s why I stick to this, technical field that I love, because that’s always this, this, this challenge.
Will I be able to, to tell it in the correct way, will I be able to, to translate those informations and. There’s a game that I always do when, when I have newcomers with me, I do a bootcamp for the young, the new hires in my company, and I get them for one day and we’ll do some kind of AMA. So ask me anything sessions with some, some of the developers from the company.
And the first thing I do with them. Is I gather, something like, like five items from office supply, some posters, a couple pencils and stuff like this. And I get this in two copies and I put five items in front of one person and five items, one other person, something like five meters away and just turn them back to each other.
And I, as I put the. The items in the special position, whichever that is the post is sunk down under, and then the pencils and crisscrossed on top of et cetera. And I asked the first person to describe what’s in front of them. And the second one should be a I’ll should build it and just replace the items so that they are in exactly the same position.
It’s just five items, five items that we know exactly how to identify it’s pencil it’s it’s post-its I don’t have the old English word for that. yeah, I’m French and I live in Germany by the way. I think we didn’t see this. and so the, the, the newcomers or the highest. They have a really hard time explaining how to place those five items.
And I use this always as a metaphor to tell them communication is going to be the hard stuff. Now you’re talking about post-its and pencils. Just imagine you talking about abstract classes, about things you cannot manipulate, and you have a hard time drawing on a white board. And now you expect that.
You’re just saying one sentence, you just, heritage from this and compose with this, and then yeah, you do this pattern and everybody should be able to understand that right away. Never ever. So that’s, that’s the game that I love. And I love to put it in upfront to say, Hey, pay attention to this. This is gonna, this is what can, is going to bite you in the end and not the technical stuff, not, how do you really implement this thing?
It’s going to be, how do you talk with all the persons
Douglas Hirsh: [00:12:31] and, you know, thinking about that, even, even down to two. A product owner, communicating to, to development. It comes down to how do we communicate this stuff? I actually, I now have a new exercise. If you don’t mind, if I take this from you. Cause where I teach, I happen to teach at a 20 week long coding bootcamp.
So that is, that is something that I do. And I hadn’t even thought about an exercise that would, that would show the students.
Tim Bourguignon: [00:13:00] That,
Douglas Hirsh: [00:13:01] when you started talking about like, you know, how we form pictures in our head, I thought you were going to go down the creativity exercise where tell me what you could do with this, you know, with these five things, give me, give me a description and then you totally just correct called me, right there would you said, Oh, and I asked him.
Them two to describe, and then the other person not seeing the, the way it was to put it in the same places and whatnot. So, yeah, that is, that’s actually a really good exercise. and I see, I actually see that a lot, that communications piece is very important to get down in, in the journey as we, as we go along as developers.
It’s the one thing I think it’s the one thing that we, That we don’t really communicate enough with, with our juniors as they’re getting ready to come into the field. Is that, is that it’s not exactly the technical stuff. It’s, it’s this hard stuff of talking to people. And, I just wanted to say, when you talked about that, how like, it’s so weird how, how we are, where I was going down one path with what you were, even what you were talking about, and then you were like, no, I’m kidding.
Just you just weren’t listening. That’s what Douglass do that. Deep listening stuff. You know, that was that. Yeah, that was, that was kind of, the thing that I w I wanted to kind of bring out there and really hone in on a little bit, because it is communication. A lot of it is, and there’s so many points in the development path where communication really does have problems.
And it really does cause problems.
Tim Bourguignon: [00:14:38] Go ahead, man. Amen to that. I, I do a lot of coaching in, in agility and, one thing that you can do as well. I have no idea how this game is called when, when I flustered something in your ear and you flustered it to somebody else and somebody else flustered further along and at the end, you listen to what, what the message is at the end of the chain.
What’s this game golden phone. Telephone. Okay. So you play telephone and you realize always with a sentence that, but he knows that it’s guessed completely distorted in the end. And now you try to do it with some kind of field engineer, then product management, then a PO or proxy product owner, then somebody as like a team lead.
And then the scrum team, if you’re talking about scrum, So you have five persons talking to each other, playing telephone in a professional context and trying to get the ideas of the client all the way to the devlopment team. How should that work? It’s just exactly the same as what we’re doing in kindergarten and it doesn’t right.
Douglas Hirsh: [00:15:43] It doesn’t, I mean, I have Epic, I’ve got Epic stories about that. Like the one time when I was in logistics and, and, we were trying to make a custom change for a client and. It would come to me from the product manager three times Douglas do this and I would do exactly what they would say. And they come back and they’re, you know, the client was not happy with it.
You know, the custom, the custom software that we, that we did for them. And, and eventually it was like, Hey, can you just let me talk to them? Like, can I just talk to the person, making the request? And when the person actually told me what their problem was, I was like, boom. Absolutely. You know what this is?
I think that’s definitely like what y’all told me. Let me go do this. I’ll have it done in a day. We’ll get it out to them. Yeah, it is. It’s crazy. The, the amount that communication actually does get in our way. Now, let me ask you something then. So we’re talking about this, How have you found like any good techniques or skills for, I know you could illustrate it to the newcomers that are coming in.
Hey, this is the hard part, because let me show you the hard part by making you try to assemble these, these pieces together without seeing it, but how have you managed. or have you had to, or have you been able to improve that process in the company that you’re in, where people are trying to get messages down to the developers and it has to go through all these people, how.
Tim Bourguignon: [00:17:13] That that’s a good question. as soon as you have a running system, then you have to pay attention to are to how you criticize, how you bring feedback and everything, but, you don’t do it. The secret is you don’t do it in one step. You go, you go with, added step-by-step. So you try to, to improve the system a little bit at the time.
So yes, you can improve just system as well. You just try and stop talking to people. Yeah. You, you try to, to get the, the developers one step further, toward the product. If we’re talking about in this context that we’re discussing about, you get the developers one, one step further. I worked for, for Siemens for a while and, one of the exercises we were doing was, Every month.
So almost every month, one of us was in the field was, at a hospital. I was working on now on, linear accelerators for four okay. Cancer treatment and a month, one of us within the field. And every months, one of us was experiencing what our field engineers were skiing and saying what’s the, the technicians were experiencing with our machines and doing so we’re reducing.
The, the amount of, of, hoops, from the customer, the real customer using our machine. So not the patient, our customers were the, the technicians and, all the way to, to what we were doing in the end and reducing this one step at a time. So if you were able to relate. To what those technicians were living.
Then you were more able to go to, to understand what’s happening and, and at some point step up and, and be the product manager yourself, or be beside the product manager when they talk to the customer, et cetera, and doing you reduce this distance. But. It’s it’s a, it’s a long process, especially in those giant companies with a, with a very, very stable and, and, complex hierarchy and some metrics organizations, and you have to go through and do as many hoops to get to the customer.
But. Just talk to people and
Douglas Hirsh: [00:19:07] that’s really, that’s actually a hard thing to do. In some situations. I actually worked at one company where it was passed down. Hey, you know, you’re, this was at a, a, what is it? A gas station. So petrol yeah, gas station and, What we would do is once a quarter, we were supposed to go sit with, with the support center who was using our software and once a year, supposed to go into the field to the actual service stations and observe what they were doing.
And. That’s good and bad, bad, because feet aren’t what they, once were. I worked in retail as a, as a, a teenager. but when I tried to do it again in my mid twenties, I had my legs almost died the first year I did. Cause I hadn’t stood up on my feet and entire day in
Tim Bourguignon: [00:19:58] like
Douglas Hirsh: [00:19:59] almost a. Like almost a decade when they had me do that.
And then it’s like, Hey Douglas, you’re going to stand up and you’re going to your it. Wasn’t just observing. I actually went there and put the shirt on and I was behind the counter dishing out cigarettes to people. That’s a, that’s a fun, that’s a, there’s a lot of fun in that. Cause everyone has their own.
No one, I, I, you could not tell me a cigarette. I’ve never spoken in my life and I wouldn’t know what any of that stuff was, so they’d have to go, okay. Here’s how we’re going to handle this problem. I’m going to point at you tell me which way to take my finger to get to the one you want. Go down am five, left three, you know?
Yeah. Communication. That was how I was delivering cigarettes. You could see what you want. I have no clue what it is. If you tell me, so let’s use that communication to do it, but that was. I’ll tell you, man, do you service the, working in the service of the service desk and working in the gas station was probably the least fun part of, of that job.
Cause it just, I wasn’t physically built for that stuff anymore. I used to, I could stay on my feet. Like I did like nine, eight, nine hours a day. I was standing on my feet when I worked in retail, but when I tried to do it again as a. In my twenties, it just wasn’t my legs. Weren’t having it. I felt it for two days after that, man, it was like, Oh, but no, I get it.
How did you feel doing that? Was that, was that cool for you to jump in there on the field or
Tim Bourguignon: [00:21:24] it, it was very humbly, I would say. the field was specially hard. And so, when, when you see, a technician spending hours preparing a plan to, to, To irradiate, basically your patient and just telling you a way this patient is really young.
And then she has breast cancer and I want to do the best I can. So every half of a millimeter counts, and then you realize, okay, we’ve been fighting internally to, to gain even more accuracy to us, tenths of a millimeter. Yeah. That makes sense. The real difference. And then you see it with your own eyes.
And then two hours later, this patient walks in. And you can relate. You really you’re really sold the technician, work hard to prepare the plan. And then the patient comes in and you know, your machine is going to do execute exactly this and that. That was very humbling and eye opening. And so, I love these field trips.
It was really, you could relate to what you were doing and I must admit I haven’t, lived through this, ever since, nothing came close to that. to that, that cake back then.
Douglas Hirsh: [00:22:29] I think when you see that you see like, your, your, your work is saving lives, right. You’ve done the work you’re doing. If you can get it to a 10th of a millimeter, then, then you actually can CA might be able to do a little bit better than, than it was before.
That’s. That does sound like that would be an amazing, like you could walk back and go. Yeah, that’s cool. I wish I had stories like that where I could say that stuff was saving people’s lives. but no, I mean, that’s. That’s really cool,
Tim Bourguignon: [00:22:56] but even, I guess, even Baron and saving lives, it’s when you see that you’re using are, are being helped, is I said it before.
our customers are not the patients. Our customers, the people we wanted to help inherently are the patients, but the people wanted to help. Other technicians are the ones that have a tight schedule and have to go through five patient an hour and have to keep the schedule going and going and going and going day in, day out.
Those are the real people that we help. And if we manage to get them to do their job faster in a more efficient way or in a more effective way where they have less trouble. this, this is what’s really matters. Of course, that’s cherry on the cake. it’s in the field of saving people. That’s, that’s, that’s bonkers, but seeing those people deal with machines every day and, and seeing the joy in their eyes when they receive a new version and the see, okay, we know that it’s going to help us.
This is, this is the real stuff.
Douglas Hirsh: [00:23:58] Yeah, I think it’s that seeing people use your, whatever it is, whether it’s machinery or software, I’ve had a couple of experiences where I’ve written software, that people stayed in for eight hours a day. I got to meet those people and sit with them and they told me how bad the last.
Package they had. And when we custom did something in house and I was the one who did it, like it was my product. So I mean, I wrote the whole thing and I’d sit down with them and, and, you know, take them through it. And they’re like, Oh wow, it does this and that. And like, yep. It does all that. So you’re good to go.
You let me know if you need anything. I’ll, I’ll try to get, you know, we’ll try to go through the process. Actually. We didn’t have a process. That’s, you know, you just let me know if you need something and I’ll, I’ll try to see if I can get it in there. Of course. Then we created a process after that. There you go, you live in, you learn developer at the time.
It was, I just wanted to be helpful is what I was trying to be. And I realized after that, that I was opening myself up for a lot of pain. Yeah, no, in this communication thing, I think we’re, I think a lot of what we’re talking about today does come down to communicating with people. Although I think you’re probably one of the best people that we could have had on here talking about communications.
Tyler S. Lemke: [00:25:09] I, I think it’s, I think it’s interesting. It reminds me of, I think I want to go deeper into that because I had another idea, but I think that asking more about communications is going to be really, Interesting. So for what you were talking about before was, you’ve probably heard of empathy mapping.
I went to a, we have a
Tim Bourguignon: [00:25:26] local.
Tyler S. Lemke: [00:25:28] Company here called improving. And they do a lot of meetups. And one, one was called empathy mapping where you kind of take the persona and kind of try to understand how, what they feel and what they do. Do you have any other activities that might be beneficial to, you know, up and coming developers that they can maybe try to do in their companies or try to help them become better communicators that you might be able to share with us?
Tim Bourguignon: [00:25:50] if I may, I’d like to step back once, before doing all these exercises, like empathy at being like, like personal was profiling. Yeah. Like trying to, to match your feelings in a team, et cetera. I love pair programming and even more and more programming because those are the, the Sen boxes where you can.
Try communication, in different ways without having the pressure of doing communication in a formal way, without trying to map things, trying to do it formally, et cetera. So if, if, if we talk about mob programming, that’s basically the whole team sits in front of one computer. Was a giant screen, as big as you can, as big as it gets and one keyboard and one mouse and you rotate, at the, the keyboard.
as fast almost as you can, some say four minutes is the maximum. You should do. some go a bit, a bit beyond this, but, basically you rotate really quickly. And what happens is that you’re forced to communicate. You’re forced to do this brain to brain communication and what you will realize very, very fast.
Is that expressing your ideas so that somebody else can type it can really get it on the screen is really, really hard. You can do this in pair for me as well, with the real navigator driver, roles. So the driver is only typing and navigator is trying to get the driver to do something. in the, in the pear port, in the mob programming way, it’s even more on steroids because you have something like, like five people trying to get one driver.
So they have to communicate even more. And this is really your sandbox. This is really the greatest exercise you can get in, getting to a consensus, exchanging ideas and trying to make sense of all their ideas on the fly. And then try it. Steve, Tom, someone to word, I’m getting this on paper and you don’t have to do any, any meta gaming around it.
It’s really either you, you will manage it or you will just fight. Till the end, but if you manage to make such a pair programming or more programming session successful, then you have overseeing you need. And that that’s for me, the greatest, starts. And, and if you can keep it up and continue doing this, this is all you need.
This is great. This is absolutely great. Have you tried this.
Douglas Hirsh: [00:28:24] I’ve
Tyler S. Lemke: [00:28:24] I’ve done pair programming before, D Douglas and I we’ve talked about trying to do that, recently together. And so, but I do have a followup question. Have you, how much have you done it before Douglas?
Tim Bourguignon: [00:28:37] I
Douglas Hirsh: [00:28:37] wouldn’t say that I personally worked somewhere for a little over maybe a year and a half that we did a pair programming.
And I would say it was one of the best environments that I had worked in. I think from a productivity standpoint, it stopped, fully understood that when we say that we want to put two developers in front of this one computer. How much things really do improve that I got some of the like most work done in the least amount of time.
When, when there were two of us, I believe I firmly believe that we pumped out more productivity than, than two developers as working together as two developers when, when we work together. So fully agree with that. And the communication piece too, is is that. Now, now the driver navigator, if it really is down to like the person who is, who is doing the driving, listens to the person doing the navigating, I don’t know.
I’m not sure if we did that a hundred percent. Right. I’m you know, I’m thinking that that person was thinking for themselves too, you and doing some stuff and having a discussion with me and, and we, we were doing things and then we would switch and I would have the keyboard. The advantage that the other person had was they were in the code base a lot longer than me.
So if they were doing the driving. they kind of knew what was going on, but when they flipped around, they had to start talking to me about things. Right. They could, they didn’t, it wasn’t all in my head. And that’s the difference, Tim is that if you take someone it’s a really good way to break somebody up into a code base, right.
Because if you don’t take the keyboard away from them, And let them do the driving that you have to do the communicating. So you, yeah. Just hit the nail on the head.
Tyler S. Lemke: [00:30:14] Okay. Canberra came back would be shaking his head at you right now. Joking Douglas
Tim Bourguignon: [00:30:21] direction. Yes. Up
Tyler S. Lemke: [00:30:24] and down and side to side. But, So I have a few follow ups cause I was actually talking to another developer is about as much experience as me.
and they, they were interested in going to a company that does paired programming, but one of his biggest,

his biggest fears was what happens if I have to, if I pair a someone I don’t like, I think I’m going to hate that environment. Right. So that’s one thing I wanted to follow up with. And then I have a second followup question is.
I love the mob programming and pair programming. I’m totally on board. how do you get, how, how do you convince your boss to even let you do it? Right? Cause that’s you see that as a big blocker? for a lot of people on here, because we have, we come from different company cultures that accept certain things and don’t
Tim Bourguignon: [00:31:10] so, so let’s, let’s take them one after the other.
So how about when you’re with somebody you don’t like, well, Buckle up and go through it. the, the best thing you can do is be professional and try to find something to learn in, in this case. I have to be honest. Yes. Sometimes it’s not fun. Sometimes you just want to quit and just stop doing this pair programming.
if you’re not working from home, there’s also some, some, some personality, traits that’s that’s, you, you don’t have any more in, in working from home. So bodily, hunters and stuff like this. somebody who who’s. just, just ate something very spicy and, just doesn’t, doesn’t say it’s with your, with your nose or something like this.
It’s sometime hard, but I guess if you have enough empathy and if you try to, to build it up with your colleagues after some, sometime this goes away. And, if you’re in the team, then it’s even easier. Cause you try to rotate this. So you’re not going to be with this person for the whole day, or you’re not going to be with this person for the whole week.
You’re you’re trying to rotate and get everybody to get their hands and their eyes on a piece of code. So you get the best of all the words. If your team is diverse enough. Then you get the newbies to look at it and work with the architect maybe. And then you have, you’re a designer, taking the seat of a developer as well.
And, and, and maybe bringing some of the different ideas in there. And maybe you have one person that was more, more, tuned to, to taste it testing and breaking things. And they coming in and, and, and look at this another way. And so. You get all those personalities, I’m looking at the code and, if you do this well, then this problem you are, you advocate is, tends to be less important.
It doesn’t go away. And that’s true. Sometimes it’s, it’s a bummer. But, you can sometimes work around it. So, and, and talk, talk one another. If you’re, if you’re harnessed and, and, and say, what’s, what’s bugging you and say why it’s not going and doing great, then, then most of the times, you can work things out.
Douglas Hirsh: [00:33:15] Yeah, don’t eat the onion sandwich, please. During lunch, that really
Tim Bourguignon: [00:33:19] causes me a problem. Yeah,
Douglas Hirsh: [00:33:21] I know that some people might take that as a pretty offensive, but I will say Tim, from someone who did work in a company that really believed in pair program, I mean, we were on one week sprints and we changed our pairs every, every week, but we did work with that person.
So we took a story in and worked through it. We, we stayed with the same. On the same pair, but then the next sprint would come around. We would get, we would rotate around. We did never worked with the same, the same other developer. And if you did like try to gravitate that way, then upper management would go, no, you can’t do that.
Like, we need to, you need to stop doing that. You’ve got to work with someone else. And I knew someone who tried to do that and they came in and they’re like, no, you can’t do that. You got to switch. And I actually liked everyone on my team, so I appreciate it. Being able to switch out and work with all those people.
Tim Bourguignon: [00:34:12] So I had that second
Tyler S. Lemke: [00:34:13] load. I had a double, double, double barrel question there for ya.
Tim Bourguignon: [00:34:18] yep.
Tyler S. Lemke: [00:34:18] Yeah. About the boss or the company. How do you convince them?
Tim Bourguignon: [00:34:22] So the best thing is to first become Vince yourself. That’s you want to do it because there is nothing. Whereas in trying to sell something that you’re not convinced stuff to somebody else.
And so I would say try it under the, under the hood start doing it. like an exercise. I’m not sure if you do Qatar’s sometime you just sit. Together and for half an hour to do some, some kind of exercise and just try something else, try something out. that’s you can do half an hour a day. Come on.
You can, you can do this without having to report to anyone and you can try this and, and get your chops going and understand that. Hey, that’s, that’s interesting. Or maybe there’s another one that is the, the Christ’s crazy crisis mode mode. When the hits the fan and something is going wrong. And then your boss is going to accept that all hands are on one keyboard to solve one problem.
And you’re just doing more programming is just because, there’s a crisis on our hands. And so you’re doing what programming, and then you can talk to you about software and say, That was good. Wasn’t it. So, well, why shouldn’t we do this a bit more often? Maybe not every day, but just a little bit more, a little bit more.
And at the end of the week, you’re doing one, one day of pair programming or more programming every week, and then you can go to two and increase this. so, first have to be convinced and then do some baby steps.
Tyler S. Lemke: [00:35:42] So I love that it’s like the underground underground, a pair programming there. When you first start, don’t see, I tend to ask, I think I tend to give you a lot, like more like, Oh, I have to ask my boss when I’m doing all the time, but I think it’s smart just to do things sometimes and try it out, especially if, you know, it’s better to ask for forgiveness than permission.
Is that what you’re saying?
Tim Bourguignon: [00:36:02] Exactly. I’m I’m the master of asking forgiveness.
Tyler S. Lemke: [00:36:06] You need to write a book on that so I can read it learning a little more.
Tim Bourguignon: [00:36:09] Okay. That’s probably my French roots speaking, just doing stuff the way we want to do it. I love it.
Tyler S. Lemke: [00:36:18] So what’s
Tim Bourguignon: [00:36:19] your, do you mind,
Tyler S. Lemke: [00:36:20] giving us some of your secret sauce from consulting and, and sharing some more of, how you teach developers to be a great developers or, I mean, I don’t want to give away too much, but, would you mind sharing anything that might be pertinent to maybe individuals that they can implement themselves?
Tim Bourguignon: [00:36:35] Sure. Sure. So, secret sauce of consulting, I guess the, the, the it’s not secret at all, but that’s the secret sauce of consulting is you have to, I’m not sure if it’s the correct word you have to, to, get to where your clients are at. So you don’t, start by telling them well, there’s Ducker and there’s communities and you can do old your, your software on containers, and it’s going to solve all your problems.
If there are not even in CIC D yet, if the don’t even didn’t even go out of their, of their, Platform thinking or stuff like this, then you’re just talking way over their head. And so don’t do this, try to evaluate where they are at and start there. If it’s, if it’s that high up, then go there and talk to them with this vocabulary.
But if it’s not, then you have to find the right focal purity, the right level to start talking to them. And this analogy of consulting goes for everything you do. When I started talking with my son who was seven years old, I don’t talk to him the same way. I talk to the devil I work with. We can have conversations on almost the same topics, but I have to find a whole different way of speaking to him.
And there’s this myth heifer for, Oh gosh. Who, who. Coined this, I don’t remember. It’s the, the elevator metaphor. And so architects, all the ones going all the way up to the top management and speaking their vocabulary and then all the way down Bruce, and they have to speak old, the, a levels in between.
So they are, they’re just writing this elevator just left, help him down and talking right differently at every levels. And this is the, the, the, the secret sauce of, of, architecture or software architecture. And I guess this applies as well, where you are, you have to find the right context and the right words to speak to those persons.
If you’re on a podcast, you have to find who is the audience and talks to them this way. If you are not in doing a conference talk, you have to try and and find who are, the, the, the people in yogans. And, and tailor your talks for this and the same with your teams, et cetera. So this, this, I guess is, is something that re often miss and misunderstand.
Yeah. Because it’s hard. It’s really hard. And then we just run into walls because we’re not talking the same language. Yeah,
Tyler S. Lemke: [00:39:00] it reminds me, I think it’s so interesting. Cause my favorite English class I ever took in, in, college was about the same thing where each, each ANC group, I forgot there’s a, there’s a terminology for this type of language we use.
And the, but I’m going to just say anger group. Like each anger has its own language. And if you don’t, if you don’t communicate in that language, you’re, you’re kind of. Outside of that sphere. You know, if you think, if you’re out, if you’re at the table with, you know, your friends or whatever, and you’re not communicating in their language, they’re going to kind of treat you as an outcast.
I think I see that the same way as kind of what you’re saying is like, you have to use the right language you have to use when you’re with the business people, you have to speak in the domain of that business. Otherwise it’s not useful when you’re speaking tech, technically you have to speak. you know, you have to use our jargon, right.
Otherwise I don’t understand what’s going on. And that’s why we try to use the same terminology for Pat. That’s all. We, we develop names for patterns and for, all the other things that we have. but what is the,
Tim Bourguignon: [00:40:00] how.
Tyler S. Lemke: [00:40:01] Have you seen, have you seen any developers be able to, get this, get this ability?
Cause it’s, I was like, you kind of just ha you know, you’ve had it or created over time. Ha ha. Are you able to teach other developers to learn this? And if so, how do you acquire these skills? Cause it sounds kind of daunting, especially if we’re more introverted and like, I don’t know how to speak in all these different groups.
Tim Bourguignon: [00:40:25] There’s no secret to it. You have to do it. Yeah. I have to fail flat on your face and, and learn, okay. This way of doing it was not the right way. I’ve done it for 15 years and I still fall flat on my face every day. I in different contexts, I tiptoe in, in, in, spheres. I. Didn’t really, stepped into, so yeah, far surreal, C level management and, and talking to a really high management and doing some more, some more business, like communication.
And I quite often miss, use a word for another one, especially in German. it’s they have. Precise words for everything. And so I tend to just throw everything in one bucket and, and talk about customers. And then so, no, it’s not customers, suppliers. I say don’t care. It’s the same relationship as, or not another it’s completely different.
But until we came to them, this realization that I was talking about suppliers, but using the term customers, it happened last week, actually. So, I just, there was a mismatch, it was a miscommunication. So you just. Try. You just do it and you’ll fall flat on your face. And then you’ll be humble and honest and say, okay, sorry, I messed up.
Didn’t know. And so let’s start again. And if you build this relationship with your teammates or your colleagues and, and they trust what you say and the trust that you’re trying to help them or trying to do the, the, the good thing, then they’re not going to be offer skated, but there’s there. It’s going to be fine.
You just try it. And if you’re you spoke about being introverted and, and, and, and, maybe shying a bit from, from a public space and stuff like this, you don’t have to do it this right away. You start with talking in front of your four peers during a daily standup, for instance. Yeah. That’s, that’s already a challenge enough.
try to do this and, and try to find the right way to talk to your product owner. If you’re in scrum context or your, your, your product person, and end your colleagues and try to, to alternate from one to the other, and maybe you have an intern that comes in and this person is very new and they don’t have a lot of experience in the industry.
So you have to find a different way to talk to them. And we’re just talking about developers right now, and maybe one product. Person and that’s already exercise enough. And when it’s, once you’re comfortable with us to just go one step further, right. And try to get some persons with a different context, maybe some your backend engineer, and then you try to talk more to front end people who tend to love JavaScript and CSS, and they have a different, a different reference points in their lives.
And you have to find the different metaphor for this. Whatever’s your context. Just do again. One step after the other, just, try to peel the onion one layer at a time.
Tyler S. Lemke: [00:43:02] I love that. I love that analogy of doing it one layer at a time, and it reminds me of your you’ve learned how many languages do you know, by the way
Tim Bourguignon: [00:43:10] I speak German, French and English fluently, and a bit of Spanish just to be dangerous enough.
Tyler S. Lemke: [00:43:16] And how many computer labs now I’m just joking. But you know, you see that that’s funny, right? There is. We just knew the context right there, what it was talking about, and it could have been, it could have gone one way or the other. So you’ve learned multiple languages and I’ve I’ve, I haven’t mastered Spanish, but, I used to know it fairly well that to communicate and read and write in it, but it reminds me kind of the two things that I kind of pulled from.
What you just said is if you’re curious, humble, right. If you’re not afraid of failing. Right. And you’re curious, this is what I’ve seen before with like good, good managers and stuff. They come in very curious, ask lots of questions and don’t be afraid to be wrong. Then you can, then you can pull back layer by layer and just learn the domains and all the language and everything like that.
would you agree with those to kind of boil it down a little bit?
Tim Bourguignon: [00:44:04] Absolutely. I was terrible, terrible language learner. at school I tried to learn English at school and I really hated every, every second of it and German, exactly the same. I learned German in high school and dropped out of my German class as soon as I could and started learning Spanish and hated every minute of it as well.
But, through. Movies and video games and books. I started to learn English and really like the English word. I English language. I speak nowadays, I’m German. I needed a different, a different incentive. my wife is German, so I had the different incentive to learn this. But again, that was really going practical.
This, this idea. I need it now. And so when I started learning German, I just flipped the switch in my mind and say, okay, now I need to speak German. And I relied on, people making faces when they, when it was completely wrong and it didn’t get it. And so they corrected me and say, well, I didn’t get what you said.
And then we find a way to, to, to say, to say it again, or say, Hey, I understood what you meant, but it was really, really, really wrong. So let’s me. Let, let me help you, teach you how, how we could say this better and. It came bit by bit.
Tyler S. Lemke: [00:45:19] And so it’s, it’s funny too, cause it’s kind of like this it’s the internet pattern, right?
Like as developers, we’re like, we’re fine to go and iterate over and over again and make tons of mistakes, you know, unless they, unless you’re that, unless you’re that unicorn developer who I’m definitely not, I’m more of the like fix breaks, fix the breaks, or I try to try and try and try until it works.
and a lot of us are, are willing to try things until it works. And so it’s the same thing there and, and not being afraid of. When I think when, like when you were learning language and when you think of a little children where they’re learning languages, they’re not afraid of failing because we don’t, we don’t beat them up.
And I think a lot of the times when we go into these other domains, if we’re we’re for the only developer there, and I think Douglas has explained this before, you know, you’re the only developer really only interested in the end user’s problems. Like they’re going to love you to death, whether or not you make mistakes.
Absolutely. I think that’s a, that’s part of it too.
Tim Bourguignon: [00:46:12] And that’s maybe a one on one side, a side, side, common there. this is why it’s also very important to, use the domain language, which in your code, because then you’re thinking in the language of your customers, and then it’s, it’s an easy step to do used our use this, this language and communicate with your customers.
And you have the feeling you’re talking about your code and the customers are understanding what you say. And this is very important. This is, this is a clutch that we use to, to bridge those two worlds together again. And, this, this is work wonders in the path for me. and so far that it’s become a hindrance in one of the projects because we were coding, in English and using German words in there, and then talking in a bit in a mix and match off English and German and the, in our day to day job.
But that was intentional. We really needed to have all those German words in there so that we’re talking the language of our, our, customers and then the domain people who were helping us, understand what we were supposed to do. It’s, it’s, it’s really hard, but, but you have to, you have to do this.
Otherwise it’s going to break down and then you’re not going to be able to build what your customers really need. And you’re going to build your model of what you think your customers need. And this is where things start to get nasty.
Tyler S. Lemke: [00:47:31] So
Douglas Hirsh: [00:47:31] I’ve seen, yeah, I’ve actually seen that a lot when, when people don’t talk to people and they just build stuff, it’s really sad when someone dumps a lot of money into their, their, their SAS, that’s gonna cure.
The world of whatever it is. And then no one really cares. So you got to talk to people. It is so important.
Tim Bourguignon: [00:47:51] Absolutely. And, maybe when the one psycho at stake, in a daring, a different, tangent you asked me for, for, for our consulting, secret sauce. So let’s talk about mentoring and mentoring is also just communication.
It’s, it’s only communication just at very different levels all the time and centered in somebody else. So you’re when you’re mentoring somebody you’re just helping. My definition is a bit, there’s been an extremist, definition. It’s really being intentional and you’re helping someone it’s already mentoring for me.
And you do this by. Just showing up and listening and really going into this deep listening mode. When you try to listen to what the person is saying and not listen to your own voice, trying to figure out what you’re going to be able to end search with this and sound smart, which is really, really hard.
Our brains are freaking machines that are supposed to be thinking the whole time. That’s why meditation is so hard. And, when you’re trying to listen to somebody. It’s really hard to stole your voice, your inner voice, and really listen. And this is where mentoring starts really trying to listen to someone.
you do this as well in your relationships with your partners. Sometimes you really need to just shut up and listen. And this is very, very, very important. And that’s where mentoring starts. And that’s where communication starts. You try at first understand what the person is saying, and maybe go beyond the words, try to understand the context, which you understand the meaning for twins, then the emotions that behind it.
And that’s all just listening. You’re not talking at all. You’re just listening. And when you’re done with this listening, then you can start talking and maybe the only thing you have to do is just rephrase what you heard and say. I think you just say this, or maybe use exactly the same word and say, did you mean this and use the same way and doing so you’re just pushing the ball.
on the other side again, and this person can, can rephrase themselves. can can start talking again. then you can rephrase it differently. You can refer phrase it wrongly intentionally. I say, Oh, did you mean this? No, no, no, no, no, certainly not. And then they will say something else and you gather some more information.
You noticed? I it’s just communication tricks that I listening and this just rephrasing what I hear. I haven’t started even thinking I’m just rephrasing and listening and then you can go on. And so communication is really one step after the other and down the line, there is the expertise where you’re telling me something about.
that doesn’t sound right. Do you need this Docker at all? Have you thought about this and this and this other way? And, but this is the expertise down the line. There are many, many, many, many steps into communication before then you can mess up, mess up, and if you don’t mess it up, maybe you will never have to go there because the person you’re talking to will realize that they are going into the wrong path or choosing the wrong direction from the very beginning.
And you only listened. And rephrased stuff. Communication is, is absolutely magical when you, when you do it right. And in order to do it right, you have to listen, practice, ask questions. And at some point you can step up and become the mentor that we can’t imagine with, with a white bird and, wise figures like Gandalf style that that’s just
Douglas Hirsh: [00:51:16] by the way it is going, it’s going
Tim Bourguignon: [00:51:18] great. But I
Douglas Hirsh: [00:51:18] blame the three children for this. There is gray in my beard.
Tim Bourguignon: [00:51:22] I blame my search a little as well. but it’s, it’s starting to wear you out, but it’s, it’s taking time, but no, you don’t need a white bird. You can be a mentor with, with 20 something and, and still have whole your, or maybe no hair, no facial hair at all.
And you can still be a mentor.
Douglas Hirsh: [00:51:40] See, I like that. And, and, and really, if you, if you look at the martial arts and I don’t know if you’ve been in martial arts or not, but I. I have I have. And we believe that the minute that you become that you’d get to the next belt. If you were a white belt and you become a yellow belt, guess what I can have you teach?
I can have you show the white belts how to do their kata because you know it now. And, you know, we test if you want it, we know, you know it, and of course there may be some techniques or something that you might want to hire belt to straighten out, but at least you could have them. You can have them lead them through, through their lower, you know, their lower belt CATIA.
And that’s the way that it works the entire way. You don’t have to be a third degree, black belt to come in and teach the white belt kata. The white belts. You can start as soon as you’re a yellow belt. So I really liked that
Tim Bourguignon: [00:52:31] where you went with that. Absolutely. I did a lot of Tai Chi and, so that was very, very slow and, very, centered on yourself.
And of course we had some, some masters were able to teach us the, the form and teaches the moves and everything, but he took only the. The oldest master who barely spoke French back then to teach us what was really behind it and show us when you speed up Tai Chi by 10 X, here’s what comes out. And he showed us how you fight and that’s what came out of it.
And it was just amazing to see the stage. He really, come to, to, to blossom and. Before this, I had never needed, this kind of teaching. I went from one stage to the other and learning the moves, learning how to central myself, how to find the right, correct posture. So that’s, it’s effortless, et cetera.
And these could be done by. Bye. I’m not almost everybody, but, but I’m a person that was just one, one stage, ahead of me, but all to get all the way there and to this real, a realization that needed some more, understanding, but you don’t need that every day. You don’t need that everyday. You’re perfectly fine with somebody that is just a few steps ahead of you.
And can you show you the, the, the ropes and take you through this journey and, I, I dare say there’s a lot of cases where you don’t even need to be, a few steps ahead. You just need to be smart enough to listen and ask questions and you can do that, but just exercising your, your critical thinking and just listening to what the person is saying and say, okay, I heard, a contradiction here is, is this really the way it is?
And by just pushing back you, You help this person verbalize what, what their, their thinking. And, and while when they hear themselves speak, they will maybe realize something is wrong here. You probably have done it before with, with, duck and all these yellow ducks, plastic ducks that you have in your bath.
I’ll hold it all. They call the in English.
Douglas Hirsh: [00:54:34] The the, the yellow, basically the,
Tim Bourguignon: [00:54:37] rubber docks, we call it rubber, rubber duck. Yeah. So when, when you have a problem, you just take, you take one of those or whichever plush you have at hand. one of your kids just stole one of your kids and, and start talking to them and telling them what’s, what’s, you’re trying to do, and trying to explain to this doc or the, this, this, this plush animal, what’s your what’s your intentions are, and by doing this.
50% of the time you were realized where your problem is. It’s also the stack overflow effect. If you’re trying to, to write a question on stack overflow, you know that if your question is not spot on, you will get some, some nasty answers. So you should’ve thought about this and need you to try that, et cetera.
Of course I did, but I forgot to write it in. So you’re right. Every step in there and you try to be as precise as you can and by doing so you realize damn. I didn’t think about this thing and you try it out and that’s with the answer and then you have to finalize the question and post it and then answer to yourself.
That’s the real way to do it. People that don’t, don’t realize you had the answer and just, just be silent, help, help all the people. But, that’s the way you find your answers verbalizing and trying to explain it like I’m five to somebody else and you will realize the, this is the, The biggest communication step you need in your life.
Trying to verbalize saying, explain it, reformulate it so that it’s understandable. And that’s already a big, big, big, big step.
Douglas Hirsh: [00:56:06] Yeah, that is, that is the, that’s actually one of our major tenants at the, at our bootcamp. And oddly enough, Cody, the duck. Is a yellow, rubber duck. And we give out, there you go.
We give out little coatings. Yeah. That that’s our mascot. And we give little Codys out to everyone who comes into the program. They, everyone gets a little Cody. I wish I had, when we went remote, I left my little Cody at the, at the office. So I can’t, I can’t pull it up and go, Hey, look, I got one. But, we can just imagine there’s a little rubber duck with our logo on it.
That’s okay.
Tim Bourguignon: [00:56:38] Yeah. The, one of the funniest arguments I, I lived through was a one, one teammate that just exploded and turn around to one of his colleagues who was talking to him and say, do I look like a duck to you? And we realized that this other colleague had. I’ve been talking to him for 10 minutes and just not, not expecting an answer, just talking to him, talking to him, talking to him and using him as a duck.
And, I didn’t realize this was happening until this guy exploded. I said, do I look like a duck? That’s what was happening.
Douglas Hirsh: [00:57:11] That’s amazing.
Tim Bourguignon: [00:57:12] So heavily Cody on, on your, on your mind is that’s very important.
Douglas Hirsh: [00:57:17] Yeah, never. Yeah. Oh man. So yeah. Cool. this has been a really great Tim. we’ve gotten a lot of good information about communication in this episode and really do appreciate you being here.
wanted to go ahead and ask you in, you know, if people want to continue having a conversation with you and want to, you know, want to reach out or follow you, what what’s, what’s the best way to, do that.
Tim Bourguignon: [00:57:43] I’m, I’m easy to find on the internet. I’m on Twitter, way too much. So you can go to a team of that’s my handle on Twitter.
you can find me on my, on my website, Tinbergen you to fr, Maybe you can add that to show notes for people who are having a hard time, spelling Bougainville and, and you can listen to all the stories that I, I record weekly with as many, diverse profiles as I can find, Def journey.info.
And that’s, that’s the podcast. It’s a weekly podcast. it lasts about 45 minutes. And, it’s just me trying to get one more story, before I can go to bed. So
Douglas Hirsh: [00:58:21] there’s another thing.
Tyler S. Lemke: [00:58:22] There’s another thing I want to mention real quick since we didn’t get into we, I honestly, Tim, I think we could talk for hours and hours.
Like we’re, if there’s so much good info that you have, but I wanted to bring something up that we didn’t delve into is the mentoring stuff. There is a, I found your long lost art of mentoring presentation on YouTube. So I really want people to go check that out. I think that’s excellent about understanding the mentor, mentee, mindset, and, you might be able to explain a little bit more about that, Tim, if people want to check that out too.
Tim Bourguignon: [00:58:50] Yeah. mentoring has been the, the biggest rollercoaster of my life, after my family stuff, of course, but I’m getting to too, it’s like a, a new gear on your, on your car. It’s like, it’s, it’s, what’s taking you from a, from a certain speed to double speed being with somebody else and helping each other.
Get further on. And so I’ve tried to, to give to that again, to as many people as they could. So I’ve, this email class mentoring that rocks, you can have this small, you know, class, and I have a couple talks on YouTube as well. I try to just explain to people. Mentoring is not a nasty word. It’s not something that you have to, to have 20 years of experience under your belt to be able to do it’s something you can do right from the get go.
You just have to be intentional about it. Jeff too. Shut up, listen and ask questions. And, and it’s going to take you already a long, long, long way further than, than you could ever think. And, and some that’s something, few people realize, all the persons that we see, all the celebrities, all the big with big air quotes and the celebrities in our industry are not knowing this readout.
Or mentored, they all have mentors. we just have to, to realize this and, and, and try it and do it. And, they help you so much. So. I don’t know what I can do, what else I can do to try to popularize them. So we have to do it. And, and when you look back on your life, you will not remember those projects that took you, way too long and, and, long hours into the night.
You are, remember when you move people, you will remember the connections you had, and this is what I attribute to mentoring. So, yeah. Try to do it. And if you want to talk to me, just ping me. And I’m always happy to stay up very late into the nights too, to talk to people.
Tyler S. Lemke: [01:00:41] That’s awesome. So we, like I said, we’re going to tee you up at the end here.
what’s the one question when we should have asked you that we missed, so maybe you can leave us off with, something to think about. .
Tim Bourguignon: [01:00:53] I actually didn’t think about that one.
what do you could have asked? what’s what’s a French guy doing in Germany. that’s when he is easy, you do everything for love. I guess, D do you have to be your free and, and stay up all night and do all kinds of things during, during your evenings and during your weekends to be a good developer. I used to think this, and I’m, I’m a workaholic and I love my work and I tend to work way, way too much, but I’m learning this as well, Jura Thrones for the podcast.
we don’t have to be this way. We, we can, there is another way and people doing it another way are as least, at least as, as successful as, as I am or, or, or the other kind is. And so this is something we all have to explore. Do we have to do it the way we are doing it right now? Or are there, and there’s a way, and I’m pretty sure we’re all going to be surprised by the answer.
There was not really a question.
Tyler S. Lemke: [01:01:55] No, I think that’s a great, that’s a great way to leave it off. Hey, thanks so much again, Tim. we hope to be in contact you and we’ll be following you on dev journey.
Tim Bourguignon: [01:02:04] Please do. Thanks, likewise.

Ep 11 – You Get What You Give w/Rylan Bowers

Rylan currently lives in Boulder, CO. He has been freelancing since April 2012 and consults on a variety of front-end and back-end client projects for start-ups and established companies.

He emphasizes clean, crafted, and tested code. Rylan works with proven technologies to architect applications that are easy to read, maintain, and iteratively improve upon. He builds, maintains, and improves web applications for several start-up clients.

How to Contact:


Talking Points:

  • You Get when you Teach
  • Giving in the Community
  • Helping Others
  • Helping others get jobs
  • Interview a lot because you will be bad at first
  • Ruby and the Ruby Community
  • Good and Bad Recruiters
  • Skills and values from other career paths
  • Understand one level below the abstraction you are using


Boulder Ruby


Douglas Hirsh: [00:00:00] welcome to another episode of the junior to senior dev podcast. I’m Douglas Hirsch. And I’m
Tyler S. Lemke: [00:00:06] Tyler Lemke and we’re here today with rye Island Bowers. Reiland currently lives in Boulder, Colorado.
He’s been freelancing since, 2012 and consults on a variety of, of front end and back end client projects for startups and established companies. including one for like, come new or as a shopping for, to, to get my a bed out recently. he is he’s, emphasized as clean, crafted and tested code.
He works with proven technologies to architect applications that are easy to read, maintain, and eternally have a pro improve upon. He builds, maintains and improves re web applications for several startup clients. Thanks for calling on our Island. We, we’re really excited to have you on
Rylan Bowers: [00:00:47] happy to be here and thank you for having me super excited to.
Talk with you both.
Tyler S. Lemke: [00:00:52] so we wanted to kick it off with, this blog post you did and letters to, to a new developer, which, which Dan created and on this, on this letter, basically the, the premise of it or the title of it was you get what you give and you talk about, why you should. Well, you should basically give back.
Can you, can you go into what you meant by, by giving? Are you talking about giving to the community? Are you talking about giving to others and their careers? What are you talking about giving and what, and what does it mean to get when you give to, to others as well?
Rylan Bowers: [00:01:31] Sure. Yeah, that’s a, that’s a great intro kind of question.
it’s kind of a multifaceted situation and it really depends on the person and it depends is my favorite phrase for all of my career and life, but, It kind of comes out of a, Brad Feld, the founder group in tech stars here in Boulder, they sort of started this give first mentality. And the sort of idea is you’re not giving because you’re not expecting anything back, but you’re giving because you want to improve it community.
And it could be mentoring one-to-one with somebody. It could be helping organize meetups in town or just being a kind and helpful person. There’s a lot of kinds of facets there. So it really is about building community in my opinion, but you could take it anywhere you want it to in a way that was applicable to your career or your personal life, I think.
Tyler S. Lemke: [00:02:20] Okay, cool. So how have you, how have you, implemented this in, in, in your own life? How have you built the community around you?
Rylan Bowers: [00:02:31] Yeah, I, I was sort of surprised. Kind of found myself as an Oregon organizer of Boulder Ruby as a meetup in town, has been going since. Early two thousands, Marty hot from hot Coworks, started it with a couple other people.
And, I, when I, I came to Boulder 10 plus years ago, it was like, wow, these people are super smart. There’s just no way I’d ever be able to like, do anything any of these people are doing or things are talking about. and so I just kind of was nice to go there and, and a couple a year and a half ago, or so they’re like, Hey, so you’re organizing now.
And it’s like, I’m sorry, but, so that’s been pretty key. W we with Dan Moore, who you mentioned the letters to a new developer, and Marty still, and then kind of a rotating cast of other folks who would help out from time to time, we do two talks every month, which is. It sounds like a long time between them, but it comes on so fast.
but it’s an organism, you know, so it’s a way to bring people together and improve generally people’s knowledge and then also kind of network. So you can improve your social and, professional circle. So that’s one way I volunteer for Boulder startup week, which is a, Week long sort of celebration of startups in Boulder and it’s expanded everywhere.
so those are kind of two ways, just sort of trying to, to be welcoming and build a community that people can come to with no judgment and find, find ways to improve themselves in many different ways, actually. so that’s kind of the, the main focus and that does a mentoring. I try to answer questions.
We have a local Slack channel for Boulder, and then there’s some Denver ones too. Try to just sorta like, Hey, somebody has a question about the area or somebody has a question about their career and jump in and help if I can.
Douglas Hirsh: [00:04:14] That’s awesome. I
Tyler S. Lemke: [00:04:15] love it. there’s a lot. We could go off there. what, what have you seen from, what have you seen from a mentorship, place or what?
I think this might be a good question. cause I went to a, A virtual event today that we talked about how to get mentors. What, what, what attracts you to mentees? Like what, what types of mentees make you get you really excited and get you more involved than normal? Like what, what do you, what do you see in people that you’re like, Oh, I should really give to this person because of X, Y, Z.
Rylan Bowers: [00:04:47] That’s a interesting question, like trying to piece kind of piece back the way that I’ve thought of it. And really, I think it’s just kind of a, People who seem kind of welcome welcoming and eager to learn without being pushy. there’s, there’s sort of a fine line. You can walk there, but it’s just anybody who you can see is pretty excited, but just have some rough is really into learning and it can be.
Douglas Hirsh: [00:05:13] Yeah.
Rylan Bowers: [00:05:13] The two that really stand out are two women that I mentored back when I was a full time, at quick left and, and seeing them kind of go on in their career from there not to say I am at all. I was just a very small part of their career. They were very, both, very intelligent, and motivated on their own.
But I just remember them being like super eager to learn and try new things out. And it was fun to be like, cool, let’s think about it this way. And then let them run with it. So that, that I think is really a nice, it’s just sort of, you’re just sort of giving a little guardrails, right. So people can bounce it off and get maybe where they want to go on their own.
But with like, I’ve done that before. It may, maybe you don’t want to do that.
Douglas Hirsh: [00:05:50] Yeah. That’s the, that’s the one where also I think that if they, they follow the advice, that’s another big deal. Like if you ever have someone who tries to try to tries to get you to, you know, ask a few questions and then they suddenly just don’t.
You know, they argue with you, I’ve had this happen to me before, so that’s why I’m thinking about it for some reason, but they, they argue with you and then they don’t do what you, you know, they, they don’t even take your advice. You get to the point of, well, why did I just spend the time sitting down to listen to your problem?
If you, you know, if you think that you do how to do it better. Right. And then you’re going to go make the same mistake. Cause you’re going to come back later. It’d be like, Oh man, it just did this, this and this. And you’re like, yeah, I know
Rylan Bowers: [00:06:32] because I did that five years ago.
Douglas Hirsh: [00:06:33] I know. I actually I’ve had, I’ve had that happen to me.
That was more of a, a junior coming in as a, as an employee. And I’d been around for a while. At the company and, and he’d come to me and go, Hey, I’m trying to do this. And I’m like, well, I’ve done this before. Don’t do it this way. And he’s like, well, why? And I’m like, I got to go do work. If you want to know why I guess go do it.
But I mean, There’s
Rylan Bowers: [00:07:04] a lot of value in that too. I mean, making them take yourself really well, cement it in there instead of being like you told me not to go. Why? So there’s sort of a fine line to walk there and everybody’s busy. So it is hard to.
Douglas Hirsh: [00:07:17] Yeah. There were times where I would, I would see something and I’m like, you know that Stott.
So there’s, there are, I find that in the mentoring side of things, there are times where you can look at it and go, yeah, they absolutely should go, go get that scar. Like you could even sit back and go, yeah, you should go get that scar. And then there’s other times where it’s like, I should try to stop that train wreck from happening.
And that could call someone there if they, if they, if this goes through. So yeah. Kind of kind of getting the maturity and looking at that and learning from that is always been, it’s an interesting thing. And then when people don’t follow your advice, you’re like, still come to me next time. You don’t say it to them, but you’re busy.
Rylan Bowers: [00:08:06] And then, sort of to Chine off of that as the like, give and get the, and I think as I’m sure you all know this already, but when you have to teach somebody something, you’ll be like, okay, do you do wait, why do we do it that way? And you go look it up or, and you can kind of help just in mentoring yourself that way to really ingrain and learn it better.
Cause there’s, there’s just really no better way to know what you’re talking about and trying to teach it to somebody.
Douglas Hirsh: [00:08:32] You know, and that’s a really good point. I think that I do look back at those times where I was probably a lot younger myself and say that maybe I should have been more, I should have been, been more of a, of a teacher instead of just going, Hey, don’t do it that way.
And I needed to get, you know, and just not have the time to sit there and explain it to them. But, you know, we, when you’re a dev, you always have those, that gun to your head for what you’re working on, not just what they’re trying to work on. So I look at it that way, but you’re right. We we’ve talked about this in other episodes, Tyler, about the, I forget what we called it or what it was called, but evidently you know, the, one of the ways to retain the most knowledge out of something you’ve learned is to go teach it.
You have the name for it? You’re my name guy.
Tyler S. Lemke: [00:09:17] I can’t recall right now.
Douglas Hirsh: [00:09:19] Oh, no. Don’t say that. I just sold you as the name guy
Tyler S. Lemke: [00:09:29] fail. I’m sorry. Sorry. I’m thrown an exception.
Douglas Hirsh: [00:09:36] No reference.
Tyler S. Lemke: [00:09:38] So no reference. Now, you know what, I’m still, I’m still, you know, it’s, it’s, async, I’m still waiting on that
Douglas Hirsh: [00:09:49] a second.
Tyler S. Lemke: [00:09:51] yeah, we’re, we’re, we’re doing bad puns tonight, but it’s fun. So, what. Right. And what do you think is the been like the most?
I know you talked about a few different things that have been rewarding, and maybe those were the most rewarding moments, but what have you done? That’s been the most intrinsically rewarding. So something that you’ve done, that’s been rewarding in and of itself, to, to give to others or to the community.
Like specific thing,
Rylan Bowers: [00:10:22] the question I’m sort of trying to find like a firm answer, that would be, not just me rambling for five minutes. So I’m now rambling.
Tyler S. Lemke: [00:10:31] That’s fun too. That’s all we do all the time. So
Douglas Hirsh: [00:10:35] just to show we’re just rambling on along. So. Yeah.
Rylan Bowers: [00:10:39] I mean, there’s been some tangential things to organizing. And I think my, my biggest thing, especially right now in a pandemic is finding people jobs.
So that’s been a really big motivation for me is like, you know what, your recruiter, I’m still sending this out to people that I know it doesn’t matter right now. and that’s not to say recruiters are bad that they can be bad, but that’s a whole other discussion. so. Well, just that just, you found a few people, jobs are putting them on a path.
Cause I get asked that a lot meet ups. I have a lot of junior developers come in from some of the great code schools out here and they’re like, how did I get a job? And so I sort of just do this like network and give back and keep improving and it will come to you eventually kind of situations because there’s a lot of them right now.
And, and it’s, it’s a hard to be like, just do this one, two, three, but it’s sort of a. A mixed bag of all the different efforts, but long winded way to say. anytime that I’ve helped people find jobs, even just tangentially to like organizing the Boulder Ruby meetup at a company, and then having them be like, Oh, if we had found somebody, I was like, that’s amazing.
Tyler S. Lemke: [00:11:44] That’s great. That’s something I’ve been really wanting to do because I got in a weird place Mike or where I was like, okay. I felt like, Oh, I never want to be in this space again. And I guess it’s a, this is not completely altruistic, but I knew if I gate, if I gave, if I helped like a hundred people get jobs over the next 10 years, those people are probably going to be more likely to want to network and help me.
So I know that’s like a, you know, this is a karma kind of going along with the karma theme that we’re talking about. how have you been? I ha I’ve had a hard time. Being successful with that. So, getting other people’s jobs, what are some tips that you can help give people? I imagine having a really good network is probably the best one, but what are some, some tips along with that, that can help people who, who want, you know, especially during this time during the pandemic and everything that want to help other people get jobs are maybe aren’t as effective or don’t want to be more effective doing it as, as developers.
Rylan Bowers: [00:12:45] That’s a good question. and I’ll sort of, before I try to answer that one, say that, you know, give the kind of give first, isn’t an altruistic. I’m not going to get anything out of it, but it’s just not the first thing you’re thinking of. And so when you are saying, Hey, I’m doing this because hopefully you’ll help me later.
That’s kind of the idea, right? Is that I’ll help you. We’ll build a network of Goodwill karma, if you will. And at some point I could be in a bad situation and you’ll turn around and do the same for me. So for like in a, in a developers that can be a little harder, but being just part of the scene. So it could be like, Oh, that guy helped stack chairs at the end of the meetup.
that’s something that like sticks with people’s. And people’s brains. And then you start building these little moments that people will be like, Oh yeah. Oh yeah, you did help. That’s awesome. By the way, I know this guy who’s looking or woman is looking for, your sort of, career skills. Let’s see if it’s a fit and.
So I’m sort of thinking like, for me as a, you know, quote unquote, senior, the idea is I try to watch kind of job boards. I try to talk to people and I try to do some loose matchmaking. I think I’m trying to get at what your question was. I hope this is right the right path here. But, so, so I do a lot of that.
People will say, Hey, I have this job. Do you know anybody? And I almost always am like, no, but I’m going to. Make a note of that. So I’ll try to keep a list of those things that I’ve heard. and it’s tough when we’re all busy and distracted to do that, but yeah, that’s sort of, my idea is like, you’re trying to keep these, like, I know Junior’s looking, I know Mitt who’s looking in Royals or no.
Oh. And here’s a job opportunity. That’s come up. And so usually I’ve forgotten one or the other. And by the time that they would have coalesced properly, but occasionally it’s worked out, I’m like, Hey, let’s talk to talk to this person. Hey, you’re a design consultant and I have a design client. So some of those things just kind of work out, but having that network, and I’ve actually paid a junior developer a few years ago to build me like Rolodex, which I never fully ended up using, but it was that idea of, I met this person here.
These are their skillsets. These are what they’re looking for. So I could have that offline, that knowledge to try to help find people more, more gigs and build their network.
Douglas Hirsh: [00:15:08] I really
Tyler S. Lemke: [00:15:08] like that. I think that that, that definitely addressed it. I think, I think the hard part is, is knowing for me, is getting the, is finding those people who have those roles open.
I don’t know if I, cause I’ve done, I’ve done quite a bit of networking. I feel like at least for, you know, the standard developer, like I’ve gone to a lot of different meetups. I try to meet people. I’ve done a lot of stuff on LinkedIn. I like 3000 something connections on LinkedIn. So I try to meet and connect with a lot of other people, but the other, the other part of the equation.
So I think knowing the right people that are going to have those roles open works, and I think going down the recruiter rabbit hole might be an interesting thing if you want to talk about that. Cause I think that’s an interesting subject too, but before we get to that, I think,
Douglas Hirsh: [00:15:55] w.
Tyler S. Lemke: [00:15:57] How do you, do you vet people at all before you try to connect them as well?
Because a lot of the junior type roles, it’s hard to really vet people. Right. And not everyone has time of day. So a lot of the times, if I think anyone has, like, I usually want to connect people if they have no competence, but, or if, I don’t know if they have any competence, but I try to just connect people and let things kind of.
Lay where they lie. Do you try to vet people more or not, and not refer people over? Cause I know that can potentially, that could potentially damage your, your credibility right. With, with your network. how do you go about an approach? That
Rylan Bowers: [00:16:37] that’s a, that’s a great question. A lot of it. So the real answer is lots of times to say, Hey, I met this person.
They seem okay. I have no other knowledge about them, but I wanted to connect you because they’re looking, you’re looking, please vet them yourself. Cause you’re really, the end goal is going to be either as a recruiter. They, you know, do the kind of in between screen and then the company would do the real vetting, but.
The kind of cop-out is, I don’t know what the company wants. Like, there’s just no way I can vet the company and be like, Oh yeah. And then vet, the person is just too exhausting to do that. So, so it’s sort of a like gut feeling of, Hey, this person is getting back to that same networking or just being present like this.
I’ve had some interesting conversations. This person has good bye. Seems like a good person. Yeah. And who might fit well with whoever they’re looking for, but yeah. Vetting is just going to be too hard. especially if you’re having multiple people just be too wiped out. You’re like, wait, did you have a whole nother set of notes?
Oh, they seem competent in this or this. So that’s kind of a best guess just to sort of feeling and to know
Douglas Hirsh: [00:17:43] that
Tyler S. Lemke: [00:17:43] I liked that though. Yeah. Like how you, you kind of, you kind of caveat it and if you, if you have more information and you do, you know, like, Oh, I’ve seen their code before done something like, that sounds like you, you give whatever information you know about them, but you don’t, you don’t really sugarcoat things or, or, anything like that.
You just give them the straight, the straight stuff. Right. So exactly. So it sounds like
Douglas Hirsh: [00:18:06] you’re on the. On the flip side of that though. And this is something that I deal with because I do handle junior developers quite a bit. and. No, not from a hiring perspective, but we actually, I work for a company.
We create them. So we’re one of those kids, coding schools. And, and so one of the things that I tell, I tell my students when they’re like looking at jobs is. And I I’ve had this happen where, where a junior that I was mentoring. So someone who taught themselves, not even someone coming through the coding school, but somebody taught themselves, got in with this company.
And they were basically treating him like a senior level developer, like just giving him the stuff and say, go do all this. And come back and let us know when you’re done and he was failing and he almost like, he’s like, I don’t even know what I’m doing. Why am I w you know, why am I here? Imposter syndrome kicks in real quick click.
And I’m like, no, man, this is not something you give someone who does not have professional, like a lot of professional background. You would have never succeeded at this. You were set up for failure. And so I had to get in there and build him up and get him back in there. He’s a senior dev now at a really large company, right.
But if I hadn’t gotten in there and like helped him back up off the ground, after that company did what they did to him, I don’t know what would have happened, but that’s the thing that I ask or the thing that I tell my, my juniors. That are coming or students that are coming out of the program and they’re, they are developers when they leave.
is that, yeah. You know, look for, or at least ask what, you know, what their mentorship is like there, and if they can’t give you a good answer, just on a simple question of, you know, how do you handle mentoring junior developers? That’s a massive red flag right there. They don’t have to go forward with them.
fortunately I work for a really great company that we have. Our placement team is, is top notch. And so our employer partners. know us well and we know them well, so we don’t put people in positions they shouldn’t go into, but the, the thing is, is that I’ve had experience with that. And I was just wondering how you handle, do you handle that or is that that caveat?
Hey, these, you know, do you know the people you’re referring on the flip side of it, as well as the junior dev that you’re making the referral, but the company on the other side,
Rylan Bowers: [00:20:27] Yeah, I wish I could say yes, I can do all of that, but I’d imagine your plate team is quite good at that. And they could. Speak to that and be like, yeah, it takes a lot of effort to vet the company, to vet people and try to, you know, I mean, matchmaking is hard in a romantic sense.
It’s the same with the job.
Douglas Hirsh: [00:20:43] It’s like getting married.
Rylan Bowers: [00:20:45] Yeah, yeah, yeah. And Dan being, yeah. You know, let go or fired or when I can, I’m sure. It feels very much like divorced. I mean, it’s just a wrenching experience experience.
Douglas Hirsh: [00:20:56] Yeah,
Rylan Bowers: [00:20:58] it’s
Tyler S. Lemke: [00:20:58] funny. You brought that up cause that’s, that’s totally a blog post I’ve been wanting to do how, how finding it, the right job is just like dating or, or like marriage.
So that’s funny you brought that up.
Rylan Bowers: [00:21:09] Yeah. And I tell a lot of people and sort of another way I approach it is. You have to interview a lot before you figure out how to interview and you’re just going to be, it’s going to be like, I am so embarrassed. I’m like my answers there. And, I cannot believe they did that.
And then the next one you’d be like, Oh, okay. I can answer it this way, because I screwed up so bad that last time, and it’s sort of figuring those things out. And so I’m just like, okay, yeah, just do a phone screen with it. Everybody you can when you’re starting out, because you’re going to start getting like, Oh, these are the things that are asking.
These are things I need to know. And then you get better and better at it. I’m sure it’s super difficult to do, but it’s just one of the things you have to do and you’re starting out. I think.
Douglas Hirsh: [00:21:49] Yeah. We’ve been finding that a lot of people want to hand out these challenges now, even before like a phone screen, like here, right, right.
Code that matches the spec. And in some of it’s like, have you. Have you actually hired a junior before, you know, when you look at it because, you know, this is, this is something that I would, I would have to really know exactly how to get to the root of this, this project and understand where the, where you hid the instructions.
Rylan Bowers: [00:22:18] Yeah. And that’s, and that’s part of the, I think sort of outgrowth of, we just got 150 applications for junior developers do this and you’ll, you’ll be able to weed out some folks, but some of it is like the barrier is too high. You have to. You have to lower the bar a little bit so that you can get a better sense.
And a lot of it is you don’t have to be super, technically skilled. You have to be eager to learn and like super motivated until then. And those little code challenges, you could easily find someone on a bad day, or it just be like, I don’t, there’s not enough context. I need to know the business domain better, or it just doesn’t make sense to people.
And you’re really could be missing some really good candidates with that kind of
Douglas Hirsh: [00:22:57] effort or swimming. I think
Tyler S. Lemke: [00:23:00] it’s funny too, because I think a lot of people learn bad habits, right? When they’re first coding or, or, and I think it’s a great opportunity for those companies who want to be like, take someone and go look, I can teach you.
You know, something that you’re an advocate for. I can teach you clean code or test testable code instead of, you know, this highly coupled, spaghetti code that, a lot of people. Right. You know, so I think that’s an interesting thing that they’re missing out on, but some, some companies don’t care, right?
It comes down to culture. A lot of times it’s sort of realizes you got to find a company that matches the culture that you are good for. And because. I think different people have different talents and skills and those skills and abilities are going to align with a shirt and company culture.
Rylan Bowers: [00:23:47] I think it plays right back into just sort of the dating versus vetting people as myself while doing introductions is like, even if you know people and you set them up, it’s just so many things that could go wrong, blind date or on an interview that it’s just so hard to get.
Tyler S. Lemke: [00:24:04] Yeah, exactly. Yeah. That’s a, that’s a really good point. I like it. Okay.
Douglas Hirsh: [00:24:11] Well, I was going to, I was going to jump in here for a second. I think we were going to wait, where did you want to go? Tyler?
Tyler S. Lemke: [00:24:18] You take, you take the reins.
Douglas Hirsh: [00:24:20] Okay. Well, I was going to ask you, cause we’ve had, we’ve actually had a couple of people from the Ruby community on, on the show at this point.
And, interestingly enough, I’m a.net guy. And, and I guess you could say I’m a Java guy. I teach Java now. And so is, so is Tyler Tyler, you’re a.net person, right? Yep.
Tyler S. Lemke: [00:24:41] Yep.
Douglas Hirsh: [00:24:42] And so it’s, it’s really interesting to CA people from a different community come on to our, our, our podcast. And I was going to ask, cause this is kind of a little bit of a historical question.
What, what pushed you toward the, the Ruby path?
Rylan Bowers: [00:25:00] I was actually doing.net in San Diego. so let’s see C sharp and.net with the web forms, which are winsy now, but maybe also use those. I know the MVC is a little more popular, but, yeah, and then I, there was this boulder.me, which is a precursor to Boulder startup week, Andrew Hyde, and a couple other people.
Did like a flying program. And I just found out about it by luck. And then another lucky sort of coincidence was I looked at the people who were there was like, Hey, you know, make a friend with these kind of leaders in the community. And one person had gone to San Diego state. And so I reached out to her beforehand.
I was like, Hey, I’m from San Diego. You’re you were in San Diego. Could we hang out when I’m here in this new city and that woman ended up starting quick, left with two other people, and then it just sort of coalesced into this. Hey, they didn’t PHP when I had first met them. And, then in between the time they had switched over to Ruby, And then it was just a, Hey, we need people, you know, we’re looking for to hire new people and they ended up moving me out there and like, you’re going to do Ruby now.
I was like, Oh, okay. This will be interesting because it’s a pretty different paradigm coming from web forms, which are clunky. And then you’re like MBC, what in the world is going on with this code organization? so. Well, no, I just sort of lucked into it and they paid to move me out. And then,
Douglas Hirsh: [00:26:28] yeah, no, that’s, that’s that’s cool.
I had actually run into Ruby myself a long time ago. I was listening to, listening to an episode of dotnet rocks, where, where the guests had come on. He was talking about Ruby and, and it sounded like this really awesome language to go learn. So I actually went and got a book on Ruby and learned it and, and, How to put, you know, got to look at rails and see how, how MVC worked, which I loved a lot more.
I was using web forms at the time, too, when all this happened, this would have been like in 2006 or seven, somewhere around in there. And, You know, MPC wasn’t, it was, was, was not a thing at the time. all.net was the crazy people that did even like testing and all that stuff. It was, it was a different time for.net developers.
And I really loved it. I wanted to go do it professionally, but where I lived. There’s no one what’s Ruby. If you period, I do Ruby develop. What is Ruby? Wait, what is rails? No one would, no one would know what it was. So, you know, I see people who got to go in and do it professionally and, and, I’m not going to say jealousy is a thing, but it’s just one of those where I kind of wished I could have gotten into it and done it professionally and seen how an enterprise grade, route rails.
Deployment is put together or even just how Ruby would be done in a full blown, like, like full system architecture. and I’ve had, I’ve had the chance here in Dallas to look at a couple of systems. Like I’ve had some friends that have said, Oh, I do repeat development, but they’re very far and few between.
They’re like these unicorns that are out there, in, in, in my area, even the, that, that do it. So it’s really cool when. When we get to talk to people who got to jump into rails, I just don’t know the community around rails seems like it’s a very unique community. I’ve heard MOTS talk about like his, his, Inspiration or, you know, kind of like the motto of the language is supposed to be welcoming and I’m like, that’s, that’s awesome for a, for a computer language designer to be like, I want this to be a pleasant language to use and, and stuff like that.
I just went on a, on, on a, Just wrote a love letter to the Ruby community, but that’s, I really do. I really have like, like Ruby changed the way I even thought about web development, to be perfectly honest with you because when I picked up rails, I wanted to write my web code using MVC and not use web forms anymore at that point.
So it made so much sense to me.
Rylan Bowers: [00:28:58] Right? Yeah. And I, like I said, I got lucky with what, how I fell into it. and I’ve been gone a long time from San Diego. But it was like all PHP or.net. So I did PHP for awhile and then I did.net for awhile. And, you know, there was no community back then just coming into Boulder where it was like a small community, super tech focused.
It was like a turtle merging onto the freeway. I just got ran over by all these smart people who are super motivated. but. To sort of riff off what you were saying. Ruby is very different community and, and sometimes it’s hard cause it’s an echo chamber, especially in the Boulder area because it’s small and you know, a lot of people, but you know, there is a top down from Matt Mattson.
Nice. So we are nice, kind of welcoming community and that’s what I love about it. So if people are kind of toxic in the community, they sort of get excited out because who wants to deal with that in your job and your. You know, any sort of personal or professional life it’s tough to deal with. and so it really does keep you keep me in Ruby land, to be in that kind of situation.
There are trade offs though. We could talk about that, but that’s a whole nother,
Douglas Hirsh: [00:30:06] well, we, we could go technical to it, into it too, but I mean, I was just thinking about even the market. Cause you know, I just don’t see like, In, in my market, like here in the DFW area, I don’t see a lot of Ruby shops around they’re very far and few between there’s two that I know of.
That’s it?
Rylan Bowers: [00:30:26] I wouldn’t say I’m in San Diego probably.
Douglas Hirsh: [00:30:29] Yeah.
Tyler S. Lemke: [00:30:30] I also get the feeling and I don’t want to, I don’t want to battle languages anymore, but I get the feeling like the Ruby was taking off for a long time. And I feel like, and maybe you could maybe talk to this cause you’re, you’re deeper into the community.
It is. It is it. It’s true. My assumption that it’s kind of getting less prevalent with new developers coming in, and I feel like JavaScript’s kind of overtaking the PHP and Ruby scene where that used to be. Is that, do you think that’s a correct assessment?
Rylan Bowers: [00:31:01] Yes. And so a lot of my. I’m sort of like too deep into the Ruby community to know if I’m giving an honest answer.
but yeah, it’s each node in the area as well as Ruby. They’re still teaching Ruby on rails and touring in Denver. I think galvanize. They’re still teaching Ruby on rails, but also node. and I think those are in my circle, kind of two big ones. The elixir has become popular, but I haven’t seen it, like do the hockey stick.
It’s sort of like at a blip and maybe I just lost kind of the context on it, but it seems really nice. And another tool to know about. but I think what’s happened with, with Ruby and then with rails, cause they’re sort of tied together right now. There’s NAMI as well. And in some other ways you can do things Sinatra, but I think it’s just found its neat niche and sort of stabilized and leveled off.
I see a lot of jobs posted salary is usually pretty good developer. Happiness seems pretty good. so, so yeah, I don’t think. I guess it’s going to go live print, shoot back up and take over. But for people who want to do and that you can scale it, we can talk about that too, but super, super good to be like, boom.
Prototype is up, go sell it. And, you know, I haven’t done any with.net or Java spring boot, you know, forever. so I don’t know what that kind of turnaround time is, but for people who are just even like relatively decent at rails, you can do that really quickly. And then you can, you’ll run into scaling issues later, but that, you know, you can solve those as well.
but that’s kind of his niche. That’s what I’m trying to get at.
Tyler S. Lemke: [00:32:38] That makes sense. Cause yeah, cause Dan, I think Dan’s, on Dan’s website or his old, the old, the, I guess his, his, his company they had before, I think you talked about rapid prototyping was, You know, doing rapid prototyping on there.
Sorry. Am I mixing Dan and Marty? Maybe it was Marty. I can’t
Douglas Hirsh: [00:32:58] remote.
Rylan Bowers: [00:32:59] I mean already had a consultancy that did rapid prototyping
Tyler S. Lemke: [00:33:04] is Marty. Is Marty the one? Yeah. So on his site he talked about doing rapid prototyping with Ruby. And I think the reason I bring it up is because a lot of junior, a lot of junior devs are worried about like, am I going into a dying language?
And I know it’s kind of a, It’s kind of silly in one sense, because even if, even if you’re going into a market, that’s, you know, stay stabilizing or waning out, there’s still going to be tons of legacy code out there. So it’s not like it’s going to disappear overnight. Right? Like, there’s still going to be a lot of maintenance and these occur and, I think, I think something I’ve realized as well is like, I was just picking up Python again after like four years of not touching it.
I was like, wow, it’s so easy to jump into new language. Once I have, you know, you know, three, four years underneath me, it’s like way easier to jump into a different language. Now that doesn’t seem so daunting to try to pick something new up. So that’s kind of, kind of why I was asking as well as cause some people are afraid of, Of entering the market, but it’s good to know that at least in, are you talking nationwide or more into like a Boulder, Denver or area that you’re seeing a strong, amount of jobs, a lot of jobs out there.
Rylan Bowers: [00:34:12] It’s a good question. it just sort of seems like there are a lot of jobs and that sort of, while you were talking, I was like, well, they were just looking for a Fortran or cobalt developer in Jersey, right. For their voting, whatever it was for sure. And that’s. Decades ago. Right? So, so, so there’s, I think it’s like a Sam, I think it’s safe realizing I wouldn’t be able to say nationwide what’s happening, but there are a lot of pockets of startup centric communities that that’s a, that’s a major, they good choice for.
and then there are big companies who are still using rails successfully, like get up and Shopify, Yeah, I wouldn’t call it a dying language. And I think your point is really salient that once you learn a language, you’re going to be, they’ll learn other languages. Cause you’ll understand the like types you need to figure out and patterns.
And a lot of the stuff that you start picking up just sort of can translate. I mean, it’s not the same, but you can be like, Oh yeah, I’m doing faculty pattern here or cool. I have to do an object for this. And it’s a command or service object. And. You figured out how to do it in a different language. So it’s not going to be like, Oh, I learned Ruby and my career is dead.
Tyler S. Lemke: [00:35:18] No, it’s funny. Cause I was just like some of the things I was doing the side project for automating, automating some stuff in audible that I might bring up in a future episode. But the, I was like, Oh, it’s really easy to know, like how to search for packages and how to try to find this prebuilt solutions.
Right. Instead of just rolling my own, but finding those prefilled solutions was even faster. I was like, Oh, I it’s just like conceptually it’s, it’s less, much less daunting than it was, you know, you know, a couple of years ago when I did my senior project, I was trying to do everything from scratch in a native script.
I was like, man, this is so hard to learn this, this, framework and everything. So I think things just get. Easier. I think the point, I think you, you said that the, you did mention like, did you mention that the pay is pretty good as well as, as far as what you’ve seen? Or I don’t know if you mentioned that maybe I’m just imagining.

Rylan Bowers: [00:36:08] I think so. Yeah.
Tyler S. Lemke: [00:36:09] So the, if you’re saying the pay is good as well, that’s something that I realized because I actually had, But a guy that I worked on a startup with a brief time, he said that he switched from dotnet to JavaScript developers because they’re cheaper. The talent was cheaper to acquire.
So that’s something to consider as well as it’s almost better to go into a market that’s a little less popular because your, your wages can be higher. And this is something that I’ve seen with, PHP developers is part of the reason why I wanted to not be a PhD VP developer anymore was, you know, for better or worse.
There’s a lot of people look down on PHP developers, right. And. It’s just it’s it’s it’s it’s it’s a fact. and whether or not there’s lots of good PHP developers out there, but there’s, I think it’s the whole WordPress thing. And a lot of hackers who hacked around in language, it’s gotten a bad rap. but, It’s funny.
Cause it’s like, Hey, go and consider a goal. Like learning Ruby. Cause you’re going to learn something that’s not such a as crowded of a market. Cause you have a, it’s kind of a two edged sword. It’s like, do I go into a market that has tons of job opportunities, but then I can get paid less or do I go into a market that there’s maybe a little bit less job opportunities, but I can’t get paid more.
So it’s kind of an interesting paradigm there.
Rylan Bowers: [00:37:23] Yep. And the. I just lost the thought a little bit, but no, you get a little older and things just sort of flit away while you’re getting distracted. But what I, what I kind of want to rip off on that is. Tickling is really what I would say, that you can have this existential crisis and anxiety of like, Ooh, doesn’t have, Ooh, this.
And at some point in my career, I was like, you know what? I have to pick something. I have to get good at one thing. And then I can branch out from there because otherwise you’re like, I know a little bit of PHP and a little bit done it. I know a little bit of go. I know a little bit of no, And, and so as soon as you interview any one of those companies that it does, or those technologies that are going to be like, you know, a little bit okay.
And that may be enough. but at some point you have to like, alright, I’m gonna just get good at note and choose that. And you can, the survey, you can check stack overflow for kind of number of new responses, number of total responses on each kind of language and look at surveys and sort of figure out, Hey, find what you like.
but I think that’s really important is just being like, don’t get stuck, spinning your wheels. Cause you’re like, I’m not sure which to pick.
Like I was saying.
Douglas Hirsh: [00:38:36] Yeah,
Tyler S. Lemke: [00:38:37] that’s great.
you talked a little bit about recruiters before, and I think this is probably might be a good, good place to end, but you said that. There’s bad, bad recruiters and good recruiters. And I think this is pertinent to junior developers, something, something I didn’t, I didn’t know a lot about. So I’d love to hear your, kind of your spin on, Not that I want to like, keep up with recruiter hate, you know, there’s a lot of that out there, but I think it’s good to have a, you know, a, a nuanced view of like, what does a, what does a good recruiter look like?
What does a recruiter that you should avoid look like what’s up kind of persona profile, for you
Douglas Hirsh: [00:39:17] Reiland
Rylan Bowers: [00:39:19] it ties well actually into the sort of start of like my blog posts is it is the recruiter. Looking to get something out of you because they get paid a good amount of money when they’re placed some.
Right. And so you can just sort of like, there’s that used car salesman vibe you can get. And this is not like hitting on recruiters. They have a very like good reason for existing. And a lot of people have gotten jobs that way. and that’s sort of the like bad recruiter too, is like, Hey, I see that you did a demo project once 20 years ago in Java, would you like a Java job?
It’s like, That seems off base by a good amount. but a recruiter from that sponsors Boulder Ruby as a caveat, but in Boulder is always like, Hey, just go. Yeah, we’re looking. But if anyone wants to talk about their career or anything like that, like let me know. I’m happy to chat and that sort of the like, okay, that’s good.
You’re just sort of like, I’ll give you career advice. Maybe there’ll be, and it’s the same thing I’m saying, I was saying before is you give a little bit and all of a sudden they’re like, Hey, that recruiter was kind of cool. And I got some good advice and then a year later, like, Hey, I need a job. Do you have anything?
And it works out. So I was just looking for something like that. And I think we’ve all. I don’t know if we all have been there, but you’ve been in places are people kind of are, you can tell they’re not, they don’t per se belong, but they’re really moving between person and person really quickly trying to make as many introductions as possible and not really getting to know you.
and so that’s kind of the. The bad recruiter is, they’re like, Oh, you do Ruby I’m out, or, Oh, blah, blah. And it’s just sort of like, Hey, like I’m a person I have, you know, just because I know Ruby doesn’t mean I’m not interested in other things and could potentially be somebody who is someone that you place.
That’s sort of the general, just to what I’m getting at is the, get the give. And then maybe you get something later kind of person. Yeah.
Tyler S. Lemke: [00:41:08] I think what, what was hard for me is when I first started, I thought it’d be so easy to get a junior dev job. And I realized it was really, really a lot harder than, you know, a lot of companies and, you know, even, even, coding boot camps, make it out to be like, Oh, it’s so used to happen.
And it’s like, it’s hard. Even if you come out of, you know, maybe unless you come out of a top, a CS school, it’s still can be difficult. Right. if you’re, if you’re just average, like I was, you know, I was pretty average coming out of school and, honestly, I had to learn a lot and I’m still learning a lot more, but I think, It was hard for me.
It’s like, when, when recruiters didn’t give me the time of day and I was like, I’m looking for people who want to build longterm relationships, right? Like people who care, you know, after it. And I think of a w this one recruiter, a recruiter sat down with me. I met him at a meetup and he sat down with me for 45 minutes and gave me this like, master plan of how to like, choose the right job and do it within a certain, like, A distance from your area and find multiple companies and target those companies.
I was like, you know that guy, if you were to ask anything of me, I would bend over backwards to help him because, you know, he just took 45 minutes once out of his day. And it really changed the path of my career. So I think it’s, I think he gave some excellent advice there and it definitely aligns with my experience.
how about you, how about you Douglas w what, what experiences have you had with, recruiters.
Douglas Hirsh: [00:42:36] So I’ve had both, but I will say that, I was self taught and I had to convince people that I knew what I was talking about. And so there was no degree behind me. And, I really lucked out. I say, lucked out.
I put myself in some interesting positions in that that kind of brought the chance occurrences. to happen, but this one recruiter, I got ahold of them and we sat and talked for about half hour and he was like, you can talk. There’s absolutely no way. there’s no way you don’t have a programming job.
And, me and him talk to each other for every day, for a year. Like, Hey, Hey Doug it’s Douglas. His name was his name is Doug and it’s a, Hey Doug, it’s Douglas. How’s it going today? And that would be like my phone conversation with him. And he’s like, Hey man, I’m trying to, I got your resume. I’m sending it.
So he was, he was marketing me. And that’s the thing, right? When you find a recruiter that says, I really feel this guy knows what he’s talking about and he could talk, and this guy was really trying to push me into places. And it took him a little bit to find the right place, but he did. And oddly enough, we had a very longterm relationship because I would say for the first, he had to do with all of my jobs for the first seven years of my career.
I mean, he was involved in it at some point somehow. And even though he referred me to a friend of his, at one point, it was trying to play someone. And, that was, that was the good recruiter, right? He, he, he marketed me. We could, we became friends. he still keeps up with me, like we were talking about like, I sent him a message the other day.
Cause it was like a, Hey, thank you, man. I think you’re the reason why I got into the field or. Wildly succeeded in getting my first, my first big break. And, so I still talk to them and this is I’m, I’m almost 18. No, not yet 10 years into my career now. And, and so that’s, that’s one thing, but then there were the other recruiters who were like, we’ll let you know if there’s something that matches your, it matches what we think you can handle it.
And, so I’ve dealt with, I’ve dealt with recruiters, in both different in, in different areas or how, or actually just how they were, I should say.
Rylan Bowers: [00:45:02] Yeah. And I’m kind of a, while Tyler was talking, I was thinking of, of a lot of junior developers, especially those probably going to code schools are coming from a different.
Career path? not always, of course, but what I find is really a good point to keep in mind is that you have skills and values coming from, from those other career paths. And so when you’re talking to recruiters and potential companies, you don’t, I mean, you don’t probably don’t wanna get stuck doing what you were doing, but there is value you can add to your technical skills by, by sort of.
Pushing that, or it could just be something that you like, kind of used to give. It was like, Hey, I was in HR and I can do blah, blah, blah, for you or something. It was just something that kind of naturally comes up in conversation when you’re trying to network. I think that’s a really good way. A thing to keep in mind.
Douglas Hirsh: [00:45:53] Yeah, I imagine I was gonna say, I imagine interview viewing, like you have some financial experience and imagine going to interview for a junior position and you know, at a financial institution. And you’re like, Hey, I actually know all this stuff and I can write code. Wow. You’re like, let’s. Come on. Come on.
Let’s go. Yeah. You know, that’s, that’s, that’s the thing is if you, if you can use that prior industry experience, I have some experience with someone that was in management. And they definitely didn’t this one company hired him. It wasn’t because, so his programming experience, it was because of his, yeah.
His management experience. And then he still programming, but they were happy that he had the management experience as they, as they brought them as they brought them on. So that is definitely something to do, which is to leverage. So leverage your, your prior career. Cause a lot. You’re right. A lot of people are coming in.
they’re they’re not coming in right out of school. Now I will say Tyler, you were talking about this. When you got out of school, you were having a hard time. I know of a couple. Well, I know of at least one, one case study or I should say one student that we had that he got out of, Out of computer science and evidently he just couldn’t find a job.
And he just went to a boot camp and then he was very employable at that point. Like you have a degree and that bootcamp behind you and you walk in somewhere and you can talk all the theory and, and the applied code. And he said he had no problem getting a job after going through the bootcamp, but he did before he wasn’t, he just wasn’t getting through the interviews before, but after the bootcamp, it was, it was the final thing that he needed.
So I’ve seen that.
Tyler S. Lemke: [00:47:36] That’s that’s funny. Cause I would think the opposite, I would think. I would think having both would Joe show like lack of competence. I don’t know if that’s fair, but that’s kinda my gut reaction when I’ve seen that before. I’m like, okay, why are you going to, because it’s like, it’s kind of, it’s difficult, right?
Because some people who go through code boot camps wish they could go get the 40 year degree. Right. So what do you think it was the, was the catalyst for. Before that was it the, his experience he was able to bring, like, did he just not have enough experience to get through those interviews? Or was it the actual piece of paper from the cutting bootcamp?
Douglas Hirsh: [00:48:13] It was the, it was the applied skills. So
Tyler S. Lemke: [00:48:17] it was the,
Douglas Hirsh: [00:48:18] it was so much theory coming out of a CS degree. And I, you never know, right. The way that, the way that he explained it to me was that it, it, it was just, he didn’t have enough applied. Experience to, to get through into the position. Who knows how long have you tried?
Maybe he didn’t try long enough. Andy decided that, that I’m just going to go do this other thing real quick. You know, you can go say that, Hey, I’ll take an extra five months. It’s been a little extra money. The other thing that you get that you got with our school. and this is not an advertisement for my school.
I haven’t even mentioned that the actual name on this show, this show, right. Specifically, I have mentioned who I do teach for the past, but, we do have employer partners who do look at us very highly. So if a student gets through our program, they, they have a bit of a reputation behind them for having gotten through, you know, to graduation and.
Coming out of our program. So maybe he went with one of our well-known hiring partners and he had no problem at all getting hired after going through our program. And I will say that sometimes spending that money cause I can go back and think about, about that too. I don’t know if we’ve ever talked about it on the show, but the way that I met Doug was not at some networking event.
The way that I met Doug, The recruiter that helped me was because I had gone to a M. you know, I, I wasn’t getting where I wanted to go. I was doing some freelancing and some job here, you know, some, a little bit of work here and a little bit of work there. And I wanted to like up, up myself, you know, kind of level up a little bit.
And so I went to this place called new horizons. I don’t even know if they still exist or not. And they’re like, well, you need our five certificate program where you’ll have all the Microsoft certifications that I was primed for that sell for that, that selling job right there. And, and so I took them up on one of them.
I paid $5,000 for a one week course, and this is in $2,001. So this is way long time ago. This was a really expensive program. I got a loan for it and went through the program and it was my account exec that made the introduction. Cause I sat and talked to everybody there all the time. And he’s like, you need to talk to my friend.
And, and he passed me over to, to Doug and Doug’s like, you’re going to have a job. Like, there’s just no way that you’re not going to have a job. We’re going to get you a job. So that $5,000 turned into my entire career, which like magnitudes upon magnitudes returned on what I spent. And the same thing goes for sometimes you buy your network.
Sometimes that’s how you come into to making the connections. You pay a little extra money for it.
Rylan Bowers: [00:50:59] Yeah. I mean, that’s your, the pipeline that a code school, Ken providers can be very, very, very worth it. and I’ve. I’ve gone back and forth on code schools. And I think I’m in the like very positive kind of side at this point.
cause I think some of the worst ones have been weeded out. And so now you have people who aren’t in it for the $5,000 for a week kind of situation, but they’re like, we want to teach you how to do this properly. so I’m excited about that. But as you were speaking, I was like, I did two and a half years in CS.
Before. I was like, I don’t know why I’m learning this. I took a web publishing class in high school and I know I want to do web development. Why am I like, what am I ever going to provide? Like need calculus based physics? What’s that ever going to do from being on the web? And maybe now I could use it a little bit.
And I do use a lot of the concepts and theory of CSC, but I really wish there was a web programming. Course with some of that, with some of the like CPE computer programming now with a little of the electrical engineering stuff, but really focused on web development. And that’s what the code schools are doing is you’re sort of polishing those CS skills and then boom, you’re like, Oh, I can speak this know, talk the talk, learn things fast.
And we can talk about note or. Yeah, rails or Java.
Douglas Hirsh: [00:52:15] And I will say that the bootcamp industry does deserve scrutiny. I mean, not all, not all coding boot camps are created equal and it took a lot of selling from the people that brought me on as an instructor for me to say that I should, you know, that I would come on.
Like I asked a lot of questions about their pedagogy and, you know, I, I wanted to really understand their model and. And all that stuff. In fact, I think the, what they told me was the, they were interviewing me for about an hour and the other, Oh, the other 11 hours of conversations we had was just me asking them questions.
It was, it took a long time for them to get to, to convince me to come on. And so they had to sell me just as hard as they had to sell, you know, they have to sell a student, but, The thing is, is that yeah. Are what you just said is we take in condense down, w the applied, what you have to know to do web development into, and we’re a five month program.
So we’re not like the typical, you know, 12 week, three month program. We spend a lot of time with our stuff, students, and, You know, it is it’s, it’s one of those things where it’s like, Oh, you could take three years and do it on your own, or we can actually get you everything, you know, you need applied knowledge and do it in five months and have a network to send you, you know, to, to, You know, we have, we have a pipeline.
the, the other thing frustrating, cause like I was on our Slack channel. We happen to have a developer Slack channel here in the DFW area and they were just railing against bootcamps. Someone was saying, I was thinking about going into this boot camp and the person was like, well just go to free code camp.
And I’m like, it doesn’t work that way for everyone. Not everyone’s going to be able to go to free code camp and . Yeah, you, you have to be, and Tyler, you know, my history, you, you, you know, w you really have to be very self-driven and in order to get it done, right?
Tyler S. Lemke: [00:54:07] Yeah. I’m not one of those people, actually, I was playing around with coding, go to a coding boot camp, and I decided a CS degree was a better, a better route for me personally.
But yeah, I think you guys brought up a lot of good points. About about the, the, the pros and yeah. And cons, I will say something though, is that I think, I don’t know if, I don’t know if the market’s been saturated. I think that’s part of it, with bootcamp grads. but I do think that there is something to.
The bad name out there, because I know that I’m one of the companies that I’ve taught for before specifically mentioned not putting it on your resume, which is very telling. and they’re a good company. So from my estimation, but they specifically say not to put that your cramp bootcamp grad on your resume, which is pretty interesting because it sows you where the market’s at.
Like people. I don’t think it’s anything special necessarily to be a bootcamp grad, you have to show other things to be, to show that you’re, you’ve gone above and beyond,
Douglas Hirsh: [00:55:11] other
Tyler S. Lemke: [00:55:12] people as
Douglas Hirsh: [00:55:12] well.
Rylan Bowers: [00:55:13] Yeah. And none of the ways that you can get into this career or wrong, one of the sort of ways when people are like, Oh, I’m thinking about it.
you know, getting into coding. I’m like, okay, why are you doing anything on your own for fun? Like, this is not easy.
Oh, cool grant and like succeed. You’re gonna fall flat on your face if you’re not like into it. cause it’s, you’re just going to be like, what am I doing? And you’re just sort of like punching the clock again. And that’s not to say that there aren’t people who are successful in doing that. But it’s just my opinion is that it’s something that you kind of have to be a little passionate about.
It doesn’t have to be here. The hobby that you make a job, just something that tickles the itch. Very frustrating. And that’s where free code camp is hard. Right? Cause it’s so frustrating to be a coder and learning to code and being like, what in the F are you even talking about you try and do it. Doesn’t work.
I do. It doesn’t work. And so one of the things I was listening to the pod, I think, change log this week and it was like, Developers have a high bar for like the frustration before your head blows. You’re just like, you’re going to have to grind and do some of this stuff. And code camps can be a really good way to set those frameworks so that you don’t have to be that frustrated free code camp could be awesome if you’re going to be like, I just want to like do it on my own, my own pace and really grind at it.
That’s awesome. And I think people can be super successful doing it that way. CS is still amazing. I I’m constantly kicking around going back to get a master’s in CS because now that I’ve worked in the industry, you’re like, Oh, I see why, like I should have finished. There’s lots of cool stuff that I don’t know still.
Tyler S. Lemke: [00:56:51] Yeah. And I, Oh, I don’t want to make a correction. I never got a CS degree. I got a software engineering degree, which was basically CAS without any of the math. So
Rylan Bowers: [00:57:01] I wish
Tyler S. Lemke: [00:57:02] I had that too.
Douglas Hirsh: [00:57:04] Be that’s actually kind of tempting. I might, I’ll have to talk to you about where that program is. Cause I have been deep in that.
I’ve never asked you about your, your degree. So no, that was the whole thing, right? It’s like, do I really need to go that deep into mathematics in order to write code? And, and, I just. Yeah, there’s definitely.
Tyler S. Lemke: [00:57:23] Yeah. There’s definitely things I miss. Like I miss not doing discrete math. I think that would have been useful.
I miss not getting into algorithms. There’s a couple of algorithms classes that would have been useful. And I think going into operating systems would have been useful for understanding how to solve really hard problems. But, they didn’t have that. I, well, no, I think they did have operating systems maybe, but I know that.
Yeah. Or in a lot of CS, CS courses,
Rylan Bowers: [00:57:47] Those are, I think will be a lot of value. Cause you’re like, Oh, I understand what’s going on behind the scenes, but like, why, why do I need to know that? Like how electricity moves coupled with calculus? Like what’s, how’s that going to ever apply to my career?
Douglas Hirsh: [00:57:58] Yeah, I really appreciate it.
The advice once that I heard, which was that you should really understand, understand what’s going on under one level of the abstraction that you’re using. So you should at least know what’s going on one level under the abstraction, that you’re using. And, I think we’re so far above like machine code at this point, though, that that understanding what’s going on at that one level below is, is, it’s not the same as it might’ve been a long time ago, but she should at least understand what’s going on a little bit under meet the covers.
I still don’t know if we need. although I will say that I did have a guy that I worked with. He was really cool with math and I’d be trying to solve a problem and you go, Hey, you just need to use this. And I’m like, Oh, that actually did work crap. What am I doing here again? How did y’all hire me?
Rylan Bowers: [00:58:50] Yeah.
There’s a lot of people with that kind of knowledge and it’s super helpful in this career specifically. I was just sort of hard when I was 19. Like I don’t get it. Why, why do I need to apply for this?
Douglas Hirsh: [00:59:03] Yeah, it’s true.
Tyler S. Lemke: [00:59:04] I mean, I have, I had a professor who did a C plus plus for 30 years and he said he never used calculus ones.
and he was doing, you know, he was helping build. Stuff like, I think the firmware for like, manufacturing machines or something like, so, I mean, it’s, I think you’re right. So the, the last question we’d like to, to ask, is what, what questions should we have asked you that we, that we’ve missed Rutland?
Rylan Bowers: [00:59:32] That’s a great question to wrap up on. I know, I feel like we’ve covered so much that nothing like is. I think we have like, had like lots of really interesting interjections as well that I don’t know that any one thing is anything that we’ve missed.
Tyler S. Lemke: [00:59:47] Well, that’s amazing that that means we’re batting a thousand, so
Douglas Hirsh: [00:59:52] we
Tyler S. Lemke: [00:59:53] hit it then.
So, What’s the best place. What’s the best, place for people to follow you? I, I know, we’ve got our, your Boulder Ruby Lincoln here for your, the YouTube for that. but for, is that right? Reiland bowers.com and your Twitter, is that the best place where people can, get to get to follow you? I know Reiland Bowers has all your different social links as well at the bottom.
Rylan Bowers: [01:00:13] Yeah. Yeah, yeah. Right on bowers.com. It loads kind of clunkily. So remember that children have no shoes, but, I’ll have my Facebook on there. I don’t have Facebook anymore. Do you not go to Facebook? I am not on there, but my email is there. my cell phone is there, but probably don’t just start with the cell phone gets up.
LinkedIn. Is there? Twitter is on there. Oh, Google plus. Wow, my Google plus
Douglas Hirsh: [01:00:39] I don’t know if that exists anymore. Yeah,
Rylan Bowers: [01:00:42] I should probably
Tyler S. Lemke: [01:00:42] say it’s age, man.
Rylan Bowers: [01:00:45] but yeah, Twitter Island B can at me, feel free to shoot an email. I do really like giving back. I mean, I try to walk the walk, not just talk the talk.
but I think, given the pandemic, we’re all a little busy and distracted and low energy, but I do try to help as much as I can. if you wanted to shoot an email or just tweet at me, cause that’s kind of the fun of it, of, of the, the industry and trying to just be finding my own part in it is just trying to help other people.
And I will say the, Oh no, I just lost the thought again, as I was talking about that. Okay. There was the one that was a thing you could have asked me.
Douglas Hirsh: [01:01:25] I was going to ask, if you don’t mind, is the Boulder Ruby, a user group? Is that, is that group online? Do you, you said you hold it. You’re holding two meetings.
I think you said two meetings a month.
Rylan Bowers: [01:01:36] One, one meeting a month with two talks,
Douglas Hirsh: [01:01:38] one meeting a month with two talks. I, but if that’s online, man, we all could just jump in there and join along. So that’d be. And,
Rylan Bowers: [01:01:46] and that actually brings up one of the points that we were talking about, which is we are not Ruby exclusive or rails exclude.
We’ve had soft skills folks come and talk. We’ve had other technology folks come and talk like Python and Ethereum guy. I came in and talks to us and he, And I think that’s kind of related to what you’re talking about earlier is the different ways that programming languages approach things and things you can learn from and then apply it to your own sort of career path is super helpful.
So, I mean, we’re always looking at for speakers. If anybody is interested and listening and wants to give a talk. We have lightning talks, super interesting ways to be like, cool gems, cool design pattern, cool. Anything. And it also ties back into teaching people like, it’s just, you really drive home the knowledge and the thing, and I’ve done a couple of talks and they’re a little nerve wracking and then you do it.
Yeah. You’re like, that was amazing. Like I had to prep for it. I learned a bunch and then I was able to like split it up back and kind of riff on it. And then it’s just stuck in your brain forever.
Douglas Hirsh: [01:02:45] Yeah. Cool. Cool. Looking forward to jumping into one.
Rylan Bowers: [01:02:50] Yeah, definitely would love to have you it’s open. So you just sign up on meetup and join.
It’s a zoom call and we do it through GitHub, get hubs, zoom account, actually, which is super helpful to they’re kind of a sponsor in kind for our zoom meeting. Yeah, and it’s just super cool. So we’ve been doing it every month. It’s a little different, I really miss the in person and stuff, but it’s still nice to have some semblance of community in that way and learn, learn from the people in the community.
Awesome. Yeah. And then that’s boulder-ruby.org. I think we also have our own website and we have a lot of the talks
Douglas Hirsh: [01:03:23] recording. Awesome.
Tyler S. Lemke: [01:03:24] We’ll have to join you there. So thanks again. Thanks for getting right then.
Rylan Bowers: [01:03:30] Yeah. I love being here. I really appreciate y’all having me on.

Ep 10. – Dev Opportunities, Freelancing, Meet Ups, and Conferences – w/Marty Haught

Marty Haught: Engineering Director at Fastly. Tech community director at RailsConf, RubyConf and Boulder Ruby. Colorado. Husband. Foodie. Totally a dad. 

Get in Touch with Marty: https://twitter.com/mghaught

Talking Points:


Douglas Hirsh: [00:00:00] welcome to another episode of the junior to senior developer podcast. I’m Douglas Hirsch. 

[00:00:08] Tyler Lemke: [00:00:08] I’m ki, and we’re here today with Marty hot. Did I say that right? Marty? 

[00:00:14] Marty Haught: [00:00:14] You did. That’s 

[00:00:16] Tyler Lemke: [00:00:16] a miracle cause I’m supposed to ask him.

[00:00:20] Marty Haught: [00:00:20] Yep. So 

[00:00:22] Tyler Lemke: [00:00:22] Marty hot. He is a engineer. He is an engineering director director at Fastly tech tech community director at rails comp, Ruby comp and Boulder Ruby. He’s currently lives in Colorado. He’s a husband, a foodie, and totally a dad. I don’t know where we got that from, but I think that’s it.

[00:00:42] That’s your Twitter. He’s also a D and D master back. So we learned that before 

[00:00:49] Douglas Hirsh: [00:00:49] master, you got to get that right. Dungeon master. 

[00:00:52] Marty Haught: [00:00:52] I didn’t do. Or you might just say DM, like. Right. Yeah. Yeah. I, the backstory is that when I was eight, I got, my grandparents gave me, a first edition player’s handbook and DMG.

[00:01:07] Dinner’s your master’s guide and monster manual back way when I was little kid. So, that’s pretty awesome. 

[00:01:15] Tyler Lemke: [00:01:15] Awesome. Well, we S we got in touch, touch with you cause you have a cool, you got a lot of cool, Background of different things. I want to start off kind of with your story. So I found this cool article.

[00:01:28] I don’t know if you remember it, cause you stopped blogging some time ago. but this one was from 2012 and it’s called the developer opportunities. The rest of the story I’ll have a link in the show notes, but Do you, do you recall much about this article at all or, or, 

[00:01:42] Marty Haught: [00:01:42] yeah, I, it does. It does ring a bell.

[00:01:44] I, I don’t recall. Did I write it? Did I, is this one is for my blog. 

[00:01:49] Tyler Lemke: [00:01:49] This one is from your blog. It’s not 

[00:01:51] Marty Haught: [00:01:51] from, 

[00:01:52] Tyler Lemke: [00:01:52] so it looks like your, it says posted by you. 

[00:01:56] Marty Haught: [00:01:56] I’m sure. That’s right. I wrote a lot of things back in the day, so, you know, just, yeah. Cool. 

[00:02:02] Tyler Lemke: [00:02:02] Well, it’s, it’s pretty cool. Cause he, I think he had some, some previous blog posts that kind of talk talked about different opportunities in your career.

[00:02:11] Right? But in this one you mentioned how, you’re going to break down to different, the opportunities that come up and you broke down, what’s called the mid game. What you call the mid game and end game. Right. And you said, and the mid game, it’s a, as I’m calling it, it’s about building up the resume and negative experience.

[00:02:27] So you said you have so many options and see the, see the world, sorry, world of software, travel, stretch yourself and experience, I think make experiences there. So when you talked about a few different things that they’re inside the mid game, What, first of all, I wanted to break down what consider all the years of the mid game, right?

[00:02:48] Because we’re talking about junior to mid-level developers. What are, what are the years of the mid game as you’re defining it here? 

[00:02:56] Marty Haught: [00:02:56] Yeah. So I, you know, when I think about the mid game at this point in your career, you probably can get a job fairly easily. So when you’re a junior, I mean, you know, it’s, it’s fairly common that it’s hard for them to get their first break, you know, where they land their first job.

[00:03:12] They’re there. They’re pretty green. They probably are gonna make a ton of mistakes. There are definitely, most companies will view a junior as sort of, you know, it’s a project, right. You know, they’re not going to be productive and they may not be set up to help that person succeed. So they might have high failure rates on people not working out.

[00:03:32] And so, so the mid game is really when you have. Probably one, two, maybe three years of experience, somewhere in there, depending on how fast you pick things up and how comfortable you are with your tech stack, wherever you’re working on to where you essentially F you apply for jobs. You’re going to get interviews, you’re going to make through the interviews and you’re going to get hired.

[00:03:54] So you, at that point, you have a lot of options available to you. Where do you want to go? What do you want to do? and, you know, you could go for a certain kind of tech stack. Maybe you want to change tech stacks, or you go someplace, we’ll let you work on different parts of the stack, or maybe you are going for more of like, maybe for salary or maybe you’re, trying to, get into a new industry or something like that.

[00:04:19] So you’re changing the different verticals, you know, in, in it. and so. You have a lot of options. That’s sort of what I’m think of with the mid game. And I’ve advised many folks over the years that, don’t worry about the money cause the money will come. And we’re blessed in industry where we’re paid quite well.

[00:04:39] I mean, we, we, we deliver the value, but like, Compared to the industry when I got started, it’s just night and day at this point. And the, so optimize for experience, you know, optimized to learn, to get exposed to maybe different ways of working, maybe, you know, consulting versus product, or kind of two other angles you might, explore, in terms of the kind of company and the kind of team you’re working on.

[00:05:06]I also advise that you want to take ownership of things as soon as you can, you know, let, you see if you can run with a feature all on your own or come up with a design of some service on your own or whatever it is you’re doing. you’re going to learn a lot to push yourself. You’re probably gonna make mistakes.

[00:05:25] Hopefully you’re at a place that will not punish you for trying and maybe not succeeding quite as well, but. definitely push yourself outside of your comfort zone. Cause you’re, if you play it safe, then you’re not going to learn as much. 

[00:05:39] Tyler Lemke: [00:05:39] I love it. That’s 

[00:05:39] Marty Haught: [00:05:39] great. 

[00:05:40] Douglas Hirsh: [00:05:40] Say that’s really good advice. I mean, that kind of sounds like oddly enough, that sounds like my career.

[00:05:47] I actually for the first time ever, when I took the last job that I’m at now, I’m an instructor now and I teach web development. But the, the, the, my code structure was like, Hey, it looks like you jumped jobs well, in the past five years, it’s been a little bit more than I would have liked. But, you know, when I, you go to startups, you take risks.

[00:06:08] And so I kind of jumped into the startup realm and yeah. And, you know, even, even try to hand it instructing before, but before that I spent time in different industries and different size companies to kind of understand how. How those things work. So I think that’s really great advice. It’s something where I know I could see people who say they have like eight years or 10 years of experience, but it really doesn’t feel like that they’ve experienced a lot of different things.

[00:06:37] It’s the same company and, and whatnot. So no, totally awesome. 

[00:06:43] Marty Haught: [00:06:43] Yeah. And you, you really can’t. You really can’t judge a person, short of tech, competency based on pure years of experience. Cause I’ve seen many folks who have stuck in the same time kind of job for years and years, and they’re really plateaued and they got comfortable and it’s.

[00:07:01] I mean, I’m not judging anyone for doing that, but you can’t look at someone who’s got eight years of experience where it’s like, you know, maybe the first two years there’s a lot of growth, but in the last six is, but the same year over and over again, you know? So like, yeah. They’ll they’ll know some things really, really well, but like, yeah, there’s diminishing returns on what they’re learning every year.

[00:07:21] And you know, certainly when you’re in the mid game, You, you want to make sure you’re, you’re constantly learning. You’re getting to, take on, harder challenges. be curious about how systems are put together about architecture. You know, you should be reading, blogs, books, whatever, you know, pushing yourself that way.

[00:07:41] Cause, I mean, it’s, it’s a lot to learn. But it’s, it’s worth pushing yourself on that. 

[00:07:47] Douglas Hirsh: [00:07:47] Do you have a specific set of books that you would recommend that people would read? Cause it’s what, since you brought it up. 

[00:07:54] Marty Haught: [00:07:54] Yeah. I mean, so I think some of the stuff, well, one test driven development is one of those books that I read.

[00:08:03] I think it was Charles. And for when I. When I read the book and it changed how I looked at programming and, solving problems with that person. And, and it’s, the book breaks things down to where it’s like baby steps. Like you want to like, Oh, surely I can, I can write more in this version and then run my tests and such, but it’s, I think it was really, good for me to break into that and understand, working that way now.

[00:08:33] You know, from now to back then, was that test driven development was not common back then. And, so I think certainly a lot of places now teach TDD out of the box or at least some sort of close proximity to what that is. And, but I think it’s worth reading that book regardless to kind of see how much like Ken’s process breaks down to actually how you might be.

[00:09:01] Practicing or not practicing TDD. refactoring was another book. Yeah. Martin Fowler that I read the same time that I think a lot of more dynamic languages these days, some of them. The refactoring, steps and, and patterns that you would use, you really wouldn’t use because this was like back when you were writing Java or something like that, that was a lot more structured.

[00:09:22] And, you had IDE support that would let you do these refactorings fairly effortlessly. But I think reading through that, interesting to see the process of here’s code in this one state that works, but it’s not optimal for some reason. And why you choose to. Pick a refactoring pattern and use that because it brings either more flexibility in design or clarity, or allows you to then build something else after you’ve done that refactoring.

[00:09:50] So I think that those, those two books were pretty pivotal for me, in how I design software, when I was thinking about it, from a more recent book. I think, Sandy Metz is a practical object oriented design. And Ruby is really interesting. Even if you don’t write Ruby, I think there’s seeing how she’s using a design to break down a problem and really get to the heart of it, I think is really useful.

[00:10:13] And it’s a pretty quick read as well. I’m trying to think if there’s any others that really jump out at me as something that I would grab and looking at my bookshelf right now. I think those are, those are good ones to start with. but reading blogs and kind of seeing where people are going. I think understanding microservices, I think is pretty useful why you would, or wouldn’t.

[00:10:34] Want to, you know, follow that pattern, there, one of the books that, I don’t know if I’d recommend it, but it certainly very, you learn quite a lot, which is patterns of enterprise application architecture, which is also Martin Fowler. It’s a huge, 

[00:10:47] Douglas Hirsh: [00:10:47] huge book book. 

[00:10:49] Marty Haught: [00:10:49] It is. And it’s, it’s, one that, I think if you’re ready, you’ve built some software you’ve built, you’ve worked on some systems.

[00:10:57] It’s good to kind of see these patterns and how they explore that. 

[00:11:01] Tyler Lemke: [00:11:01] yeah. Got a question on that one because I actually have that on my shelf and that we started reading that in a book club recently. And I, I don’t know about you guys, but when I start using, seeing UML diagrams, when I cut my eyes was kind of like glaze over and my brain turns off like reading this book was really difficult for me.

[00:11:19]could you I’ve I’ve got, I’ve got about four years of experience for like professional experience, roughly and. my, my experience has mixed, so I’m sure other people will be much more advanced than I am at their careers, but can you talk a little bit about that? What would you suggest, for people who feel like that if they pick up one of these books, the same with the same thing with the TDD, by example, like, if you haven’t done unit testing, jumping into T like TDD, same is like overwhelming.

[00:11:46]at least it was for me. Can you speak a little bit to that for people who might feel like I do. 

[00:11:51] Marty Haught: [00:11:51] Yeah, I, I do think that, the writing styles that they used back then were a lot more academic and they are, they are pretty rough. some of those books are pretty rough to work through. And, I think what I would do, if you find yourself in that sort of, situation is, is maybe Google, You know, blog articles or something like that, that kind of touch on the same subject matter and something that’s been written in the last maybe five years, because they’re, they’re going to one, probably a riff on whatever they’re talking about.

[00:12:24] Maybe the use of a pattern, maybe some sort of process with a modern language that a modern, stack that you would be more comfortable familiar with and the likely speak in a way that’s more engaging and more relevant to how you’re thinking and working. And there’s plenty of folks that are, that are sharing sort of, you know, this process, you know, now on blogs or medium or whatever, and it’s very approachable.

[00:12:52] And I think that that’s a, that’s a good way. Usually those. Kinds of posts are quick to read, you know, maybe you spend 10 or 15 minutes on them and, and then just try it out, you know, grab your peer editor and your favorite language and just try to follow along and see how that goes. So that’s, that’s why I would recommend, I mean, I also recommend that, that it’s great to have, someone, a mentor or someone you can.

[00:13:18] Talk to that has more experience because sometimes there’s nothing better than sitting down and pairing on something or walking through where you’re getting stuck or what you don’t understand, and they’ll be able to kind of help unblock you, that maybe you, you wouldn’t, you might struggle more with if you’re just reading through material yourself.

[00:13:38] Tyler Lemke: [00:13:38] Yeah. I think it was helpful to kind of do that through book club, even though that fell off. But I really liked that suggestion because I think it helps. Douglas and I are both into like how hard brain works. I think it helps you kind of get the mental model faster that way. And then you can fill in the gaps with the book because the book is going to give you this huge, it’s like 10 pages on one, one design pattern of 20 pages.

[00:13:59] And you’re gonna be like, what did I just read? And it’s in a completely different context, right? It’s a context of 20 years ago, which in programming is like a hundred years ago. Right. So it’s like, so I think those are really good points. Thanks for that. 

[00:14:12] Marty Haught: [00:14:12] Yeah. And I think there’s another piece here, which is like, There’s another, there’s another great classic book, but it’s going to be on the same, sort of a spectrum of maybe hard to work through, which is called design patterns.

[00:14:26] Yeah. It’s usually called the gang of four book and, that, that’s kind of, that was the first book that I got that really got into that. And I think I got that book in like Jasmine one or something like that. And, and, the thing is with a lot of those patterns, you, you know, you might not. Be in an environment where you had that problem.

[00:14:46] And so it’s very abstract. You’re like, okay, I’m reading this. I think I get why I do this. But like this isn’t a real person for me. I’m not, I don’t know when I would grab this and apply it. And that’s, that’s sometimes, a challenge with these sort of design patterns or Beck breast practices is that if you haven’t felt that pain, if you haven’t run into that wall, then this is gonna, like, I think I understand it, but then like, You might use it and it might not even be the right situation and it doesn’t fit.

[00:15:15] And of course it’s probably not going to work. So, I think there’s something to be said about like, yes, I have this problem. I recognize this pain. And this is a very, this is getting me to think about, I could approach this problem with this solution and it may be enough to get you going down the right direction.

[00:15:30] But if you don’t have a problem, right, like, okay, So 

[00:15:34] Douglas Hirsh: [00:15:34] that’s what, yeah. That, and whenever anyone says, Hey, throw a pattern’s book at somebody it’s like, well, you might be doing more damage to that, to that junior then than you think, because maybe they should go through problems, not understanding how to talk about the problems and then, and then be introduced to now, this is how you talk about them, because reading about them, what do they say when everything, when, when all you have is a hammer, everything looks like a nail.

[00:16:00] Marty Haught: [00:16:00] Right. 

[00:16:00] Douglas Hirsh: [00:16:00] You know, that’s, it’s funny that comes back like a book in the 18 hundreds from a psychologist, but it really, it really kind of, it plays out in our field a lot where someone like I’m going to make everything a Singleton now, because I read about it and it’s, you know, I think it should be, but no, like, yeah, like let’s have the problem where you try to figure out how to have only one instance of something ever created.

[00:16:23] Now let’s show you how to. How to create one. So sometimes it really is about the mentoring. I think that what you brought up about mentoring is, is very important because it does come down to passing down some of that. I don’t know if we can write everything down in our heads, in a book in a way that would let someone pick it up.

[00:16:41] Like you need to go find, go find someone who’s done it for a while and sit down with them and see what, what you can hammer out. 

[00:16:49] Marty Haught: [00:16:49] Yeah. And one thing to kind of tie it back to our original, sort of, sort of topic was that when, you know, when you’re looking for potential places to go work, hopefully you should be asking a lot of questions in your interview, interview processes, not just them.

[00:17:05] Grilling you to make sure that you’re a good fit. You should be asking them tough questions to make sure they’re a good fit for you. And I think, especially if you’re in that maybe if a junior, you don’t have this luxury yet, so you just want, you need the job, but like definitely the mid game, like, you know, Ask them about mentoring, ask them about what, what they’re doing, how they help, you know, mid-level program or succeed, you know, with concrete examples and see, do they have those helpful seniors that will sit you down and kind of talk you through like, Hey, let’s solve this problem.

[00:17:37] And here’s how, you know, the pattern or sort of the approach we use. To get into that. Cause I mean, they should be able to explain that if they can’t then they probably don’t have, have that a good practice with that at their workplace. 

[00:17:50] Douglas Hirsh: [00:17:50] There may be, they may be a senior just because of how long they’ve been there or how much money they make.

[00:17:55] Marty Haught: [00:17:55] Right. Yeah. 

[00:17:56] Tyler Lemke: [00:17:56] I don’t ever want to complain about that though. So 

[00:18:00] Marty Haught: [00:18:00] although, 

[00:18:01] Tyler Lemke: [00:18:01] although I guess they do once they, if you get, if you get pigeonholed into a job and lose your job, then, then you might, you might complain about it. If you got advanced too quickly or whatever you want to call it. But I want to get back to the, the mid get like the developer opportunities.

[00:18:13] Cause you also talked about, there’s you separate these two opportunities and in the mid game, and two’s two separate sections and maybe it’s a mid game and end game, but you said one’s based on your work style and one’s on the project domain. So you said there’s five different types of work styles.

[00:18:28] And if this, this doesn’t ring a bell, then we can kind of move on to something else. You talked about product companies, consult, consulting, freelancing training, and content. Can you kind of relate the kind of your career and how you came up with these five different, work styles? 

[00:18:47] Marty Haught: [00:18:47] Yeah. Yeah. I mean, I think so.

[00:18:50]let me maybe back up and give you a little more sort of, kind of how I got to this point, in my career. So this is 2012, so I was 15 years into my career. I w I had, was running a consultancy that I had founded. It was, you know, at this point dozen 12 were probably eight or nine. total I kept hot code works fairly small.

[00:19:16]but I had. Spent some time early in my career at, startups that were, you know, product companies. So like you are on this team that does this one thing inside a large organization and digital river is where I got my start I’m in Minneapolis. And I was on this client services team that was basically using our platform, which is e-commerce to build out sort of customized solutions for some of our more like enterprise.

[00:19:44] Customers that need special things. And so I learned how to build solutions in that sort of limited sandbox on that platform. And, I moved after that to do that some consulting and then, move from sort of like more generic consulting where I’m joining a very large team and I’m just doing what is one thing to where I was more like, in a very small team of like two, three, four engineers that are building a product or building out some new, functionality.

[00:20:16] And it definitely stretched me in different ways. And so when I was writing this, I had seen a lot of these different models. And, you know, if you’re a freelancer, you have to develop a whole different. Set of skills to succeed in that world, which I think is great. And they’re there. They’re nice, but they’re different than if you’re at a product company where you’re on one team, that’s really going deep in some part of the technology stack, you know, maybe you’re doing something with email or maybe you’re doing something with, you know, content delivery or whatever it might be.

[00:20:50]and so. I think that when you are, you’ve got enough experience, to where you can start choosing your, the next job. You, you may have been working in a product company where you were known as the person who just did this thing. Maybe you’re the guy who does react, or maybe you’re a backend engineer there.

[00:21:11] Maybe you get, you’ve gone the dev ops a route, and now you’re kind of in the SRE territory and. sometimes what’ll happen is you, you might get stuck there. And like, now this is, this is what you’re known for, because what you’ve done for the last two or three jobs, and maybe you don’t want to do just that.

[00:21:29] I’ve certainly encountered plenty of folks that were on dev ops and they realize that really want to do more software, not, you know, building infrastructure. And so I think it’s important to recognize that these different types of opportunities are out there. you know, training and, and, Douglas, you mentioned the training piece, and I think that training is really nice because you have to think differently than if you’re just shipping software.

[00:21:56] And I think there’s also something to be said about, like, if you’re on a, On a product facing team, or you’re building a product and you’re working very, very quickly, but you don’t get time to ever really go deep and really sort of like scale up or sort of a hone or shine something up because you’re building features so quickly.

[00:22:16] So like early stage startup, you’re going to be, is it a very different mode than like you’re at an enterprise? sort of like it type company where you’re, you’re just scaling and really making this one. Aspect of the software, gets to the next level. And so I think it’s good to recognize that those are all different opportunities and you might want to just try different ones, and, and see which one you, you gravitate towards.

[00:22:41] You might find that you’re more girl and you’ll want to help build products. Cause you like the creativity where, or you might say no, I really want to become the expert at this one thing. And thus, I need to find a product company or some other type of enterprise company. That’s. That has that a team that’s focused solely on that and you’ll spend the next four years doing it.

[00:23:02] Tyler Lemke: [00:23:02] And then you, then you went into, you talk about, we’ll let people kind of read more about your article, that dig deeper into that. Cause we’ve got a lot of stuff to discuss, but the, you talked about project domains as well. And I don’t know if you, you hit on some of this, but you talked about like high concurrency throughput type companies that makes me kind of think of like, you know, the Netflix and Googles of the world, like where algorithms actually, matter.

[00:23:25] Do you want to kind of touch on some of those other project domains as well? 

[00:23:28] Marty Haught: [00:23:28] Yeah. Yeah. So, I mean, you know, I mentioned rescues, which was something that is, I think rescues are a fascinating sort of line of work that you get to win. Well, generally when you have a little more experience, you’ve, you’ve been burned different ways.

[00:23:44] You’ve seen teams get burned, you know, pursuing software in certain ways to where you can walk into a, a project, or a team that is struggling, you know, that things aren’t working very well. And you can recognize here are the reasons why, and here’s how we fix it. And this is something that when you’re getting kind of towards the end game, I recommend that you definitely.

[00:24:05] Get into some rescue work because you, you already have all this, this rich sort of, base of experiences, you just know like, Oh yeah. Well, this process here is one of the root causes of why we have these problems. And so if we fix this. Then this will get better and extra thing. So I think that rescues is one that I mentioned that, that I think is really good to have that experience.

[00:24:31]the hiking currency throughput is actually like with Fastly, the teams that I’m involved with, this is the world that we live in because we have, or it’s not Google level, but like it’s, it’s serious scale and there are. Teams that are really focused on efficiency and what at one particular part of the stack.

[00:24:51] And they’re super expert at that one thing. And I think it’s, you know, when you, you get to where you’ve got to have experience, you can land a job like that. I think it’s really valuable to go deep that way. The, yeah, I think enterprise. Oh, so this I gave here is when you’ve got lots of different larger teams and there’s this collaborative cross functional piece across these different teams that you have to work with.

[00:25:17] And I think that’s a great experience as well, because if you’re like working at a small. engineering company where there’s maybe 10 or less engineers, you’re not really going to see that, but the moment you need to see a project that has four different teams at different parts of the company, you have to work together, you experience a whole nother different set of problems that, I think it’s good, especially when you’re growing to have that exposure to then, you know, be able to then.

[00:25:46] In nether situation, be able to be more effective and recognizes things. 

[00:25:53] Tyler Lemke: [00:25:53] That’s great or explaining all those different ones. Now I wanted to get into the end game sections, but we don’t have time. So I want to talk about your end game. Now. I noticed you started, hot code works. and you did that for 13 years.

[00:26:05] Can you explain a little bit about. your journey in that was that, was that like a solo, like a solo, a solo gig? Or where did you have your own company or? 

[00:26:14] Marty Haught: [00:26:14] Yeah, it was initially, it was me freelancing essentially. I mean the, the, the short answer of why I started is that I was tired of working for idiots and, you know, I, I had just recently come off a project where some really questionable management that was really bad, like really toxic.

[00:26:32] And I’m like, I. I was frustrated that I had a lot of experience at that point and they weren’t really listening to me. And it’s interesting that at the moment I became a consultant, all of a sudden these same types of people they’re paying me money would actually listen to my advice when, and when I was an employee, they wouldn’t, it was just like, I couldn’t believe it.

[00:26:54] It was, it was so true. and I mean, I think. I traded one set of problems for another set of problems. So I think it’s okay. And that’s fine. I think with, with hot code works and starting that I made a ton of mistakes. I, the, one of the classic problems is I was. working in the business, not on the business.

[00:27:13] And so that’s the idea that I was focused more on, how do I write great software? How do I help build good stuff, software, as opposed to, how do I build a consultancy that does those things? And I eventually caught on to that. But like, I didn’t think of that in the beginning. I was very focused on the craft of creating software and shipping projects and all that, which is fine, but I really need to be thinking about other things.

[00:27:39] So, but it CA how code works, pretty good, quickly moved in from a, I landed a nice contract for myself to where I wanted to do projects that required more than just myself to do. And so I needed scheme. And so I started to build a team into those projects. And I had enough experience where I had built systems.

[00:27:59] I’d been an architect and lead designer, a engineer on several projects to where I was comfortable. If I’m going to be the boss, if I’m going to be the one who goes to say a potential customer who wants to build a product or whatever, that I, I could do it all for them. And I’ve seen plenty of freelancers that.

[00:28:22] Got into the situations and they hadn’t had enough experience and they’re actually the ones that would end up rescuing because they would make lots of mistakes and, and they just didn’t have the experience to know any better yet. And I don’t blame them for that, but, but you know, that happens quite a lot.

[00:28:37] So once I got comfortable with that, that’s when I knew it was time for me to, or I, you know, it was time, but I felt it was time for me to try out running my own. Consultancy and that worked and, and, you know, I may have done it longer than I should have. I, I, you know, it’s kinda like the, you know, we talked about having, you know, a lot of years experience, but like maybe the last five were kind of repeat of all those years and I could have moved onto something else, but it’s okay.

[00:29:06] I think it’s important that you do what you love, but. I did scale up to where we had, you know, usually three to five projects at once going on and we are largest at 13. So we were never a very large consultancy. I kept it purposely small. but it meant that we had very interesting early stage work where it was teams of two to three to four building out something.

[00:29:29] And it might only be nine months. We built an MVP and we, we turn over to them and they would. Scale it up or whatever. 

[00:29:35] Tyler Lemke: [00:29:35] It’s not a tiny company though. Like when I, when I think of, I think I like one mantra, you’ve got 13 other devs. That’s pretty cool. 

[00:29:41] Marty Haught: [00:29:41] Yeah, yeah. Yeah. It was, I did all nontechnical stuff. and the others were all engineers, building software.

[00:29:48] So we were super lean that way. And I think, 

[00:29:52] Douglas Hirsh: [00:29:52] I think this is super important that if anyone like comes, like when people come in to listen to this, I want to reemphasize what you just said about going freelance. Because I made that mistake myself. I actually went freelance and I shouldn’t have, and I wanted to go write code.

[00:30:09] And that was, that was the problem. And a lot of people who would listen to the show that would think that they might be the point where they want to go freelance. You need to have in mind that when you start a business, It’s not just about coding. You’re going to probably put yourself in it places to write code, but you’re running a business and you know, it’s the E myth revisited comes to mind really quick.

[00:30:33] That’s a really good book that if you ever want to think about going into business for yourself, read that book first before you make the leap to do it. And if you still want to do it, you gotta do what you love. Like you said, you really should do it. Try stuff. It’s fine, but right. But have kind of an idea of what you’re jumping into.

[00:30:51] Cause if I had known Douglas Judy to go, you know, and I was lucky, I was really lucky. I always had another client. I was when one client dropped, I had another client. my network was strong enough that I could just go, Hey. And usually within 12 hours, I would have someone else that would pay me money to write code.

[00:31:09] But. I never did what you did, which was now I want to scale up. Instead, someone offered me more money than I was making, doing the stuff that I was doing to go back and be an employee. And I was like, you know what, tired of doing this. I’m going to go back and be an employee for a bit and see what, what happens.

[00:31:26] And it was, that was a mistake too, but that’s a whole nother story. Yeah, 

[00:31:31] Marty Haught: [00:31:31] go ahead. I can say a hundred percent on that. It’s, you know, there, there are, it’s just a different deal and, you know, I stopped coding. I actually got to the point where if I’m wrong writing code, if I am taking on, you know, a feature work, something’s gone very wrong because, once you get to a certain size, I had to make sure there was work for everyone because people were counting on me, right.

[00:31:55] To keep them busy. And, you know, I, if I didn’t, then I would have them. Very large, expensive problem on my hands. And so, yeah, you get to very much where you need to either have partners that are going to help with some of the business aspects or else you’re going to own it yourself. And you’re pretty much not going to code, but maybe that’s okay.

[00:32:17] [00:32:17] Douglas Hirsh: [00:32:17] For not coding anymore. Right. 

[00:32:19] Marty Haught: [00:32:19] That’s right. For sure. 

[00:32:21] Douglas Hirsh: [00:32:21] You had told me that like, like I really, at the time when I did this, I loved code. Right. But it was like, I’m going to go do it for myself. And that’s, that’s the thing that I w I would, I would actually really encourage people just from your experience.

[00:32:35] Like we could, we could. Put our two experiences together and it’s like, you, you, with the right way, you’re like, I’m going to stop coding and go hire people and get really big projects. And I was like, I really want to go back and write code some more and, You know, both of those were not bad to say, right?

[00:32:52] They, both of those were just a difference in the way that we wanted to do things. I still wanted to play around as a technician a little bit more while you had the options Purdue or newer, and manage your mentality. So bringing in more of that E myth revisited book into a, into place, a really good stuff.

[00:33:11] Yeah. So 

[00:33:12] Tyler Lemke: [00:33:12] I’m curious, did you, you had mentioned how FA did Fastly acquire your company or, or can you talk about that at all? You said that, your, your whole team joined Fastly. Can you talk a little bit about that? 

[00:33:23] Marty Haught: [00:33:23] Oh, but yeah, it was not an acquisition in a true sense. you know, product companies like Fastly.

[00:33:29] Really want nothing to do with a, a consultancy, cause it’s a different business model. It’s all liability, but there was a, arrangement. So a bulk hire, if you will, to take the whole team over, that we worked out. And so I, I ended up closing hot, good works down. I actually had two contractors that didn’t want to.

[00:33:47] Follow us to Fastly and they helped the transition and we did over three or four months, depending on the client. And so, but yeah, it was, it was something that I had been considering. I was, I was ready to not. Do the running a small consultancy thing anymore. I mean, I’ve been doing it for 13 years and I was like, ready for something different.

[00:34:09] And, you know, you get to a point where like, and this is where I kind of talked about with the mid game earlier, where like, you know, you can get pigeonholed and stuck on doing this one thing. And I think it’s good to like, what else do you want to do and make, and, and chase that. And so that’s kind of where I got to where I, I mean, I loved.

[00:34:27] My team, I really, that was hard to not work with them anymore. So I wanted to find something where we could all go together. And also, I want to really be careful about what was next. There’s so much choice. And obviously we’re blessed, to have so much choice. And especially when you get longer in your career, like I like.

[00:34:49] Like where I am like, yeah. I mean, you know, I could choose lots of companies if I, if I were just Twitter. Hey, I’m, I’m available for hire. If I probably be overwhelmed like 20, 30, 40, you know, invitations to interview and talk about their startup or join. Stripe or whatever, you know, it could be all these different places that they’ve known me through my network or through conferences and they would, you know, want me to join them.

[00:35:15] So, so I really thought about what I wanted. and I took, over a year to find the right place for the, for the team and I know land and, been very happily at Fest. It’s, it’s, it’s a great company and a lot of different problems. It’s neat to go deeper with that. but yeah, that’s kind of how it all happened.

[00:35:37] Douglas Hirsh: [00:35:37] So you mentioned, you did mention, like if you put the call out that you, that you might need, you know, that you won’t work and stuff like that, you’d have a bunch of people contacting you and, and you mentioned conferences and that’s something that I’ve noticed you have spent some time at. I noticed your name on an O’Reilly conference.

[00:35:55]you know, I’ve noticed like you you’re, you’re pretty prolific. I, you know, and so, you know, maybe, maybe talk a little bit about that and. 

[00:36:04] Marty Haught: [00:36:04] Yeah, absolutely. So I would say the first seven years of my career I was, was, drifting or was sleepwalking or whatever you would call like a wasn’t really very intentional.

[00:36:16] And, it was towards the end of that, where I was more involved. I started going to user groups and started talking to more people and it’s a whole, it opens up a whole. Bunch of doors. The moment you do that, you have to put the work in sometimes depending on your personality type might be super uncomfortable to go to a meetup or to a conference where you don’t know anyone or, you know, very few people.

[00:36:43] And you’re super shy about. talking to someone and introducing yourself, and it’s something that you kind of just need to get over. one of the things I tell folks that have that problem is that, well, you’re here at this event because you both care about this subject. So you already have a bunch of things in common, and there there’s some easy icebreaker questions that you can start with.

[00:37:05] And no doubt like you, you can ask, like, what are, what. What are you working on? What’s cool that you’ve explored lately, that those questions are easy. And usually if you’re, if we’re talking about programming and some sort of meetup or conference where that’s a thing, the other person will be happy to tell you about the cool things that they have discovered or they’re interested in or things they like to do.

[00:37:26] And that you mean you can talk for, you know, probably hours if you’re pursuing that. And so. But the reason why this is so important is the more folks, you know, the more people will know you, the more you’ll hear about this, that, and the other. And a lot of times the best jobs are going to be referrals.

[00:37:47] Like, you know, me and my friends got this team and they’re going to be hiring, opening a rec for this position. I think this would be perfect for you as those kinds of, of. that you want to have happen. You know, you want to find the jobs because someone knows you been, when you’ve been working together, chatting at a meetup, or maybe you’ve been working on some open source together and they vouch for you and you, you don’t even go through the normal interview process because someone’s like, you need to hire X on your team and they just make the intro.

[00:38:24] Douglas Hirsh: [00:38:24] Referrals are top. Like, if you can get a referral, you are, you are so far ahead. 

[00:38:30] Marty Haught: [00:38:30] Yeah. And I think the other thing that’s really important with conferences is that you’re dedicating yourself to learning, to exploring. And all of a sudden you hear about this cool thing that you wouldn’t have heard about if you hadn’t gone to those conference.

[00:38:43]and so, when I started, I intentionally chose to do this when I moved to Colorado from Kansas, I didn’t know anyone, but I knew at that point that if I wanted to have. More options for work. And this point, right? I was fairly, I was far enough from my career that I probably could have thrown my resume out there and I would’ve gotten played there.

[00:39:04] He was eventually gotten something, but not to the point where people would refer me for positions because that is, they know who I was. I was brand new. And so I made the point of going lots of different meetups. I started talking to, for people telling them what I was interested in and asked what they were doing, where they worked, if they, if they liked where they worked, you know, tell me about the teams there.

[00:39:22] I would, I would just. Talk to him about that. And, and so that was one piece. And the other piece was learning about the cool tech that was coming up, or like this company is now doing this one thing. And like, I didn’t know about that. I should. And that’s how I, which I discovered rails and Ruby and that it was back in 2005.

[00:39:39] So that was, it was just now coming on the scene. And so I was very interested in digging into that and finding people that were talking about it and using it and, It was just very magical. And I think, any of us can do this. You can go, there’s plenty of meetups, although I’ll go right now with COVID is a little bit different, but you can, you can seek this out, in a virtual sense as well.

[00:40:03] And I think it’s just sort of, this is kind of two prongs here. One, it’s just sort of this learning aspect where you’re, you’re hungry and you’re trying to learn new things and understand what’s out there. And the other one is just expanding your network. 

[00:40:16] Douglas Hirsh: [00:40:16] You’re talking about the, the virtual meetups.

[00:40:19] I noticed a few, quite a few of them that I used to follow just like dropped off the face of the planet when, when COBIT hit. And I’m like, you know, I’m thinking to myself, why would you do this? Like we’re, we’re in technology, just fire up a zoom meeting or whatever. I hope that more conferences really kind of take, take that.

[00:40:42] And we could see some innovation in how to, to, to navigate like conferences and user groups, because I really do think, cause right now I actually do spend my entire day on a zoom call. So it is a little hard for me to jump into a zoom call at the end of the day. because I’m in a zoom call all day talking to people all day and, But I really, I hope to see some sort of innovation, coming in, you know, in the near future.

[00:41:10] Cause I don’t think this is something that’s this is not a blip on the radar. This is, this is something we’re going to have to adapt to and innovate on. but. No, that’s, that’s kind of, when you, when you were talking about that, it just, it brought that up into mind that that we’re, we’re at a different stage.

[00:41:26] Now, do you, how do you, do you think that the same tactics are going to work in these, these electronic or virtual meetups than, than how they work when you actually walked in face to face with people? 

[00:41:40]Marty Haught: [00:41:40] I think it’s probably mostly we’ll work. It might be a little bit harder, but, I think it still can.

[00:41:46] I mean, Boulder Ruby went virtual and it’s not exactly the same, of course. but you know, you have the ability to do direct messaging and chatting. And so I think, you know, if you’re having. In a virtual setting, more conversation. And I think this is kind of the key is that, you know, in looking at virtual events, how do you share a recreates or the interactivity?

[00:42:13] How do you recreate the hallway track? And, I don’t know if we have any great answers, but I think there are. options where you can have dialogue about something where maybe someone posts a question and, you know, you have, if the meetup isn’t too large, like maybe there’s 20 or last, you can have people talk about it and you’re seeing faces.

[00:42:33] You’re seeing what they’re talking about. You can say, Oh yeah, that person right there. I should ping that person. Talk to them about this. Cause I have a question and I think that’s, that’s sort of like, Maybe the easiest way to pursue that is like you identify someone who maybe you’d love to have a conversation with.

[00:42:51] If you have a question you’d love to ask them and, and do go ahead, ping them. And maybe it’s, maybe it’s something you do over Slack or, or maybe email or Twitter or something like that. So it’s not exactly the medium that maybe you’re in when you’re in the meeting and that’s fine. but maybe then try and set up like a, like a virtual coffee.

[00:43:10] Set up or something like that, where you can chat afterwards and have a direct one to one conversation, because I think it’s, it’s finding the people you should be talking to is key. And then just initiating those conversations in whatever format you all feel comfortable with, but then you can get pretty close to that.

[00:43:27] Yeah, I 

[00:43:27] Tyler Lemke: [00:43:27] think it’s interesting. Cause I think you have to, I’ve been to several meetups and I actually liked going and, and going to meet up. So though I can be, you know, sometimes it can be shy. Sometimes I can be outgoing. But I think it’s, what’s your experience with, with, cause you talked about meeting the right people.

[00:43:42]I’ve had experiences where I’ve gone to meet up and I’ve handed out a business card and I got work through that business card. I wasn’t, I was just trying to connect. And can you talk a little bit about, you know, meetups where you’ve met tons of people or meetups that where you’ve met? No, no one or conferences.

[00:43:57] And how, can you talk about like the. 

[00:44:01] Marty Haught: [00:44:01] The, 

[00:44:01] Tyler Lemke: [00:44:01] the frequency of, of doing it. And if people just go once that, why they shouldn’t give up, 

[00:44:06] Marty Haught: [00:44:06] maybe. Yeah. Yeah. Well, you know, if you just go once the chances that you’re gonna meet someone that’s going to have a ongoing relationship with, or that will lead to some sort of referral or work is probably not very high, but you never know it, but there’s definitely something to becoming a familiar face.

[00:44:26] To where like, Oh yeah, I saw that person show up to this meetup and, and maybe that person asked him interesting questions during one of the sessions, or I remember overhearing that person talking about this cool technology that they’re they’re dabbling with. And, you know, I’m interested in that. And so, so the more you do that, the more that those opportunities can come about and that, if.

[00:44:51] If they’re not happening, then you have to kind of make them happen by seeking people out, you know, asking them questions. you know, trying to get that conversation started handing out business cards is fine. I think that that’s, that works too. it’s really just. You know, getting out there and talking to folks and see what happens, that that’s really key and sticking to it.

[00:45:10] And, and don’t just go to one meetup. Like, I think it’s good to go. If you have a particular, like, if you’re into Ruby, then obviously, you know, if we get a Ruby meetup scrape, but maybe, maybe you’re interested in multiple languages and there’s different types of meetups in your area that all kind of cover those.

[00:45:26]there’s the spectrum there then and go for it and then go to all of them and, and, and. And most likely you’ll find someone you’re really interested in chatting with, like, this is a really cool person that I want to learn more and maybe we’ll collaborate. Maybe, maybe we’ll, you know, grab some coffee sometime or something like that.

[00:45:44] And the more you do it, the more chance that that’s going to happen. 

[00:45:49] Tyler Lemke: [00:45:49] I think that’s really good. Thanks for covering that. Now you’ve spoken on a lot of good points so far one that I’m interested in. Cause I like, I like speaking, I’ve actually spoken at a few meetups before, but how, how do you, how do you become a speaker at a conference or meet up?

[00:46:07] Do you just need to be, you know, this wealth of knowledge or is it something that you can do earlier in your career? 

[00:46:12] Marty Haught: [00:46:12] Oh, you can, you can do it. From day one. so usually the first piece is one you just have to commit to, to sharing. And I would pick something small, like at your meetup. See if you can do a little lightning, talk on something cool that you learned recently, and there you’d be surprised how many.

[00:46:30] Folks will value hearing your experiences as a junior or as a mid dealing with normal stuff, like how you solved a problem or this interesting, sort of challenge you overcame. And you don’t have to be the world’s expert at this thing. Matter of fact, none of us are really, but that doesn’t mean that you sharing your experience.

[00:46:52] Isn’t valuable because there’s most likely there’s going to be a lot of other folks in the audience that will, that will resonate with. You, you might have stumbled upon something that they haven’t heard yet, and that will help them, or maybe it might be to more of a senior person will hear about like some struggles or challenges that you, you have faced that you didn’t overcome.

[00:47:13] Right. Did they be like, Oh yeah, I love to like. You know, help you with that, or let me offer you my experience and how I, I dealt with that when I was at that phase in my career. And so there, you absolutely can do that, even as a brand spanking new junior, that that just is out of a code school, or maybe even just interested in that code school.

[00:47:33]But I think there’s, I don’t have any resources off the top of my head, but there, I think you could look up to like how to put together a really compelling lightening talk, how to put together, a presentation and start small start simple. Don’t you know, you’re not trying to, You know, present definitively on this is how you do one thing, you know, tell your story, people love stories.

[00:47:56] And, the main thing is you just get going on it and then you’re doing so for a place that you want to share something, your experience, something that, you know, maybe your passion for something, and you start with that and, you just get better. You just, you just work on your craft and you just give it.

[00:48:14] And I mean, I’ve given plenty of user. group meetup type talks at work. Not very well. They were, they were polished at all. The slides were terrible and it was just me talking about this thing, but it was still useful because people were like, that’s great. I love hearing your stories about this Marty, and you know, over time, if you, if you want to become a speaker.

[00:48:33] And I do think it’s really good because there’s something about teaching people that you get dramatically better at that thing. And. It pushes you. And, you know, we’ve kind of talked about that several times tonight, but that, that speaking is that at all whole nother level, plus the moment you start speaking at conferences, you have, I mean, this sort of this authority effect where like, clearly this person is on stage.

[00:48:59] This person must be an authority at something, right? They wouldn’t be on stage, even though they might be sharing their experiences as a junior engineer or whatever it’s still is served. It’s one of our biases that we have. and it’s, I think it’s worth doing because all of a sudden new doors will open for you.

[00:49:16] If you start speaking and sharing. And if you keep working on that craft, 

[00:49:21] Tyler Lemke: [00:49:21] That’s really cool. So you start, you talked about doing lightning talks and stuff. And can you go dig a little bit deeper in, this is kind of selfish of me, but, how do you, how does one get, how do you get to be chosen to do a conference?

[00:49:35] Cause doing meetups is much easier. In my opinion, like I can go ask a meet up direct. I can go ask the, meet up director directly on meet up. I’ve messaged people that they let me come or they don’t. Right. 

[00:49:44] Marty Haught: [00:49:44] Yeah. So conference talks, I mean, the first thing you need to understand is is that, why are you giving the talk.

[00:49:52] Why wouldn’t you even come to the talk, it’d be really clear. What’s the message, what they get out of this and you have to sell it. So when you’re writing an abstract, when you’re submitting to a CFP or some other process for a conference, you need to get really clear on why. The thing that you want to share with them is valuable to their audience.

[00:50:14] How is what you’re going to cover, going to make someone better. Right. And there’s actually, if you’re not familiar, Kathy Sierra is really good at this. you can look her up. She’s got a book called badass, making users. Awesome. So if you ever get usability, this is a really fantastic material to get into.

[00:50:31] She has a. Had a blog, you can look up Kathy Sierra and she really talks about, you know, thinking about your users and how do you make them better. And in this case, you’re thinking about how do you make the audience better? What are they going to get out of going to your talk? Right? And as soon as you can identify what that is, then you make sure you sell it in your abstract.

[00:50:52] So that if someone, you know, someone who’s attending a conference was to see that in a program, they would be like, wow, We’ve got to go to this because I want whatever they’re selling in this thing. I want to learn whether they’re going to present whatever it is, like you want that reaction. And so, and it might, I mean, there’s a lot of luck in, in this, but there is a craft to, you know, selling what you’re going to present.

[00:51:18] That like, this is valuable. You don’t want to miss this. This is gonna really help you. And, the other piece is to understand the audience of course, and what the conference is looking for, hopefully in their CFP process or whatever, they, they make that fairly clear. and also just to do it a lot, like if you don’t submit a lot of proposals, you’re not going to get a lot of proposals accepted.

[00:51:39] And I don’t know what my proposal exception rate was over the years, but it was not good. Like maybe 25%. I’m like, it was, there was embarrassing. It, there were points where I was like, this is really terrible. Why can’t I get in my talks except yeah. Well, until you have a name for yourself, you, you know, it’s really kind of, did you sell it well?

[00:51:57] And is that what they’re interested in? It could be that you wrote a fantastic talk, great abstract, and they’re just not interested in that topic and that’s okay. Like you just don’t take it personally. You just gotta keep at it. I do think that. If you’re serious about that, you go to meet ups, present, ask for feedback, ask someone who does go to these conferences and say, you know, tell, give me honest feedback back on how I am.

[00:52:23] How close am I to, to having something that’s like conference grades really high quality. And, think about that. Think about how Ted talks. Work, how they really focus. There’s no fluff in those. They’re like, you know, five, eight, 12 minutes of pure focused story that really delivers whatever they’re trying to deliver.

[00:52:43] And you want to make sure that when you put your talk together, that you keep that in mind with every single slide that you put out there so that there’s no fluff, you can have fun. You can, you can tell jokes, get silly stories and whatever, but that’s. Entertainment and that’s there for a reason, but do you have just filler slides that go on and on now?

[00:53:02]they probably won’t know that, you know, before they accept your talk, but, you know, hone that, get, get good at that when you’re at immediate, because, you know, they’re, they’re very forgiving usually about who they let talk. So, 

[00:53:14] Tyler Lemke: [00:53:14] all started. You’d need to like tell, tell a good story. And maybe that book you’re suggesting talks about that, but that’s like one of my weaknesses, I’m like, I’m really good at facts and like presenting things factually, but not good at weaving a story.

[00:53:26]have you had any experience with that or? 

[00:53:29] Marty Haught: [00:53:29] Well, yeah, I mean, usually stories are, are how, humans connect and can internalize something. Like, if you imagine. you know, if your prediction just presenting facts on a slide, you know, that might be interesting, but it might not be very memorable, but if you weave a very compelling story and people were falling along and, and the, the lesson learned at the end of the story is the point you’re trying to make more impactful because you’ve woven this narrative around it.

[00:53:59] And, you know, if, if you’re not great at making these things up, you know, you can just, you can find existing stories out there that people have told or that you’ve heard or that you personally experienced. Like if it, if you can’t make it up or if you can’t fake it, that’s fine. Like, you know, you don’t have to be that way, but stories are fairly compelling for humans.

[00:54:20] And, I think it’s good to, to. Weave a story in anytime you can give like, activity examples of the thing that, that you’re trying to present, I think probably can come up with it. Like here’s a time when I was building this feature and I use this pattern or I used, you know, I didn’t do this one thing and here’s what happened.

[00:54:41] And here’s where I learned about that. And here’s why now I. Yet the importance of writing these tests or, you know, getting those codes or wherever it might be, that you’re the point of what you’re exploring, you know, trying to find some sort of story where you make it more personal. 

[00:54:59] Douglas Hirsh: [00:54:59] Yeah. I really liked that point because the way that we learn, like, if you look at any of like memory techniques for people, it really is come up with an outlandish story in your mind to remember the facts.

[00:55:11] You know, it really is the crazier, the story, the more you’re going to remember it. And that’s that really does kind of come down to weaving stories. Storytelling into trying to get people to remember the fact that you even told them something. Cause if you just, like you said, if you just give them the facts, they’ll, they’ll hear it go in one ear, kind of like my eight year old, it goes in one ear and out the other, anything I ever say to him, but you know, as far as talking to adults, if you, if you give a really compelling story with it, that’s really good advice, man.

[00:55:42] Appreciate it. 

[00:55:43] Marty Haught: [00:55:43] Yeah. Yeah. I think if you look at Ted talks, To tucks are a really good example. They’re very accessible. They’re all over the place. You know, think about how like, you know, break down what they’re doing, you know, how are they weaving the narrative into it? How are they teaching with the narrative?

[00:55:57] How are they using stories and how the facts get in there? And, you know, it’s, it’s interesting to see how they break it down. 

[00:56:06] Douglas Hirsh: [00:56:06] All right. So at the, you know, at the end of all of our podcasts, we do ask one final question, which is what is, what is the question we didn’t ask you? What is something we didn’t ask you that you want to?

[00:56:24] Marty Haught: [00:56:24] Hmm, what is the question you didn’t ask me or that’s, I mean, I don’t know. so we’re, we’re for, this is for junior mid level engineers. So maybe like some advice to possibly pass on, maybe. I mean, I think that, that there’s, everyone’s paths going to be a little different and. It’s okay. If you go about ways about this in a different way than anybody else, you know, you know, it’s your, it’s your story.

[00:56:54] It’s, it’s your truth. And I think that. It’s really good to get clear about what you want. there’s an interesting, the thing that I remember hearing recently, which is, you know, just because you’re good at something doesn’t mean that’s what you should do. You should try and do the things you want to get better at, not the things that you’re good at.

[00:57:13] And so if you’re not. If you’re not good at something, it doesn’t mean you can’t get better at of course you can get better at, so maybe you should pursue that. And I think it’s really important when you’re growing and you want to get better to be intentional about what you want to get better at and then seek those opportunities.

[00:57:30] And I think if you can get your foot in the door, you know, so if you’re a junior, get your first job or your second job, then you can. You have more options as we kind of have our, I talked about and so be really clear about what do you want and it’s okay to like go and, and I mean, it’s okay. You don’t succeed.

[00:57:49] Especially the first time. Like, you know, it’s not all about being successful every time, you know, failure is an opportunity to learn and get better. And so you shouldn’t feel bad if you didn’t succeed at something. But if you don’t try, if you don’t get intentional about what you want to get better at, then you’re probably not going to get better at that one thing.

[00:58:09] That’s great. I 

[00:58:09] Tyler Lemke: [00:58:09] love that. That’s probably going to be a clip because I think that was some great advice. So, Marty, what’s, what’s the best way people can get in touch with you if they want to reach out and, and, or 

[00:58:20] Marty Haught: [00:58:20] follow you. Yeah, I’m not as active on social media anymore, but I do. I do. If people DM me or if they mentioned me, I will see it.

[00:58:29] I’m happy to, to, To a chat or, respond to things. 

[00:58:35] Tyler Lemke: [00:58:35] So is Twitter the best place or 

[00:58:37] Marty Haught: [00:58:37] Twitter’s probably the best place. 

[00:58:39] Tyler Lemke: [00:58:39] And what’s your handle on Twitter? 

[00:58:40] Marty Haught: [00:58:40] M G hot. So H a U G H T. Awesome. 

[00:58:46] Tyler Lemke: [00:58:46] Well, we’ll put that in the show notes. Thanks again for your time. I think we could have talked for hours 

[00:58:50] Marty Haught: [00:58:50] and hours about a lot of different stuff.

[00:58:52] Tyler Lemke: [00:58:52] We got some good conversation there, so it was great to get to meet you and, and, We’ll hope to be falling in and see, see what happens next in your end game here. 

[00:59:01] Marty Haught: [00:59:01] All right. Nice. Well, thanks. It’s a pleasure. I love the chat.

Episode 9 – Myth of the 10X Developer

Douglas and Tyler discuss the 10X Developer. Do they exist? Does everyone have to try to be one? We also discuss the 1X Developer




Tyler S. Lemke: [00:00:00] Hey everybody. Welcome back to Junior to Senior Dev. I’m Tyler Lemke
Douglas Hirsh: [00:00:06] and I’m Douglas Hirsch. And today we are going to, huh, we’re going to
Tyler S. Lemke: [00:00:12] talk about something interesting.
Douglas Hirsh: [00:00:14] Yeah,
Tyler S. Lemke: [00:00:15] we always, he
Douglas Hirsh: [00:00:16] wouldn’t even let me give it a, this is great. I love this. We’re going to get these intros down at one point, but this should absolutely stay in the show. We’re looking to edit this out, but today we’re going to talk about the, the, the unicorn, or should we say the 10 X dev? Does this person.
Actually exist in what, what do we mean by that? So let’s, let’s kind of jump into this. Tyler, what do you think? What does a 10 X dev?
Tyler S. Lemke: [00:00:48] I think it’s interesting. So 10 X developer, I think of kind of the rockstar, rockstar, developer, you know, all those catchy name phrases like Ninja, you know, coding Ninja. basically I think of developers who are able to crank out code, very quickly and outperform their teammates, whether or not they actually produce 10 X. I it’s hard to, what type of metric you’re talking about is hard to control, but I think it’s someone that’s like noticeably much better than their peers at cranking out production code.
That would be a general definition.
Douglas Hirsh: [00:01:23] So the, I mean, seen other people throw around as the actual definition, they literally mean that this one dev would be, would be as effective as in devs on your team. And yeah. I don’t know. I don’t know.
Tyler S. Lemke: [00:01:42] I mean, it’s possible and I got some proof to back it up, but the, so there’s this, as you know, I’ve read code complete before, which I think is a really cool book.
Cause, you know, I’m, I’m, I like yourself are largely data driven. I like good data and inside a code complete, it says, it says an, a class, a classic study by sacrament Erickson and grant showed that productivity of individual programmers varied by a factor of 10 to 20, a to 20 during construction.
And that was a, a study in 1968. And then, numerous other studies from Curtis Millis, Curtis card, valet, Marco Lister. And Bowen, if you’ve, if you’ve read any, probably heard of bone before, cause he has quite a few different, articles, have all have all said that. So I think you, there are developers who are 10 or 20 X better than other developers.
Right. But it’s like, what are they? Are they 20 to 20 X better than the average developer? I don’t think so from this I have now I haven’t looked at these studies directly, but it said they can vary by a factor of 10. So the worst developer to the best developer could vary by a factor of 20. So you could have a 20 X, 10, 20 X developer.
That’s 20 times more, more productive than the worst developer. So that is a thing.
Douglas Hirsh: [00:03:06] So productivity is, is an interesting question, right? Are we literally only measuring? and, and we can’t measure lines of code, right? Because, well, we could, we could say, can they crank 10 times more code out than someone else?
But we know, we know that measuring lines of code does not necessarily measure productivity because someone could be extremely verbose and write very inefficient code and produce 10 times the amount of code. But then also. Produce a lot more time than other people have to go through that code and see what it is doing because they are produced so much code that may have been able to be produced in much.
Fewer lines of code. So it really this conversation, I don’t know if we’re going to come out of it with a definitive. This is, this is yes. The 10 X dev exists. No, the 10 next step doesn’t I do agree that there will be devs that are more productive, but it is, it is how. I don’t even know if it’s really easy to measure that, that productivity gain that you get between, between the devs at different talent levels.
And maybe, maybe, you have devs that are more talented and can get 10 times more information out of a project owner or product owner than the other dev. But then you have this other dev that can. Like 10 times faster, write some code up, you know, then, then other deaths. So even the fact that what is the measure?
What is a 10 X dev is something that perplexes me a little bit.
Tyler S. Lemke: [00:04:53] So let’s, let’s do another, let’s talk about a different way too. So let’s talk, I don’t know a ton about golf, but I know there’s, I think there’s, I’ve heard there’s like 20 million golf players in the U S. Right. And if you think of the, think of the upper echelon of golf players, right.
They’re much, much, much, much, much at the top. 1% is much, much, much better. So I think if we break things down, I think, I think clearly if you look at distributions on the, on the fringes, you’re going to have 10 X developers or more right. At specific things, they’re going to be 10 times. They’re going to write the code 10 times faster.
Right. And let’s look at it. Let’s, let’s look at it another way. Douglas. So the, the, if, if you were to compare yourself to a developer, that’s in, that’s your teaching in one of your boot camps, right? You’re probably at least 10 times faster than them writing code, if not magnitudes faster.
Douglas Hirsh: [00:05:50] Right? Well, the, the idea would be.
Can I visualize, right? Can, can I actually sit there and go, I need to do this task. I want to create a new application. Do I know exactly what to go do? Or am I going to have to go look those steps up and at the point where I can just go do it? I’m going to be a lot faster than someone that has to go look it up, which actually kind of, that’s another point you’d like to make a lot, which, which, when we had Jeff on the show, when we, when we get to hear, when everyone gets to hear the interview,
Tyler S. Lemke: [00:06:23] it’ll be there at all be out.
Cause we’re releasing that one. So,
Douglas Hirsh: [00:06:27] so this will Jeff’s interview will go out before yeah. Show, which is cool. So, you know, in the interview with Jeff, we talked about the fact that, that, you know, If, you know, if you have more in your head, you don’t have to actually stop and go and look things up. And that makes you that can make you a lot more efficient at completing a task where you’re trying to write some code out.
So yeah, your, to your, to your question. Absolutely. Much more efficient in starting it if an error occurs. So if something, if something occurs, I’ve also seen a lot more errors than they have. So it might not be writing a line of code, but where a student might sit on an error for two hours, I might come in and look at it and go, Oh yeah.
In one minute or 10 seconds. Oh, that error means that something’s wrong right in this method. Oh, That means you need to change this because that’s, it’s not going to work where it might take someone who hasn’t been doing it for as long, a couple of hours. So not only is there like output of code. But there’s also the, the idea of, of even just being able to fix or, you know, just even be able to understand what’s going on in the application
Tyler S. Lemke: [00:07:46] about vast amount of time for a lot of developers.
I mean, I know I spend a normal amount of time debugging, really silly things with environment issues.
Douglas Hirsh: [00:07:57] Right. And, and so I will say that, that, and this is, this is another thing from experience when I did. A couple of really complicated projects using test driven development. I spent very little time with the debugger.
I wrote tests and either those tests passed or failed, maybe sometimes if something really weird was going on, would I fire up an interactive debugger? But when I was writing code to exercise my code. It was, it was a much different thought process and no, I didn’t spend on those projects. I spent very little time sitting in a debugger because there was nothing coming from the outside in some of these unit tests that I was, I was working on
Tyler S. Lemke: [00:08:39] of debug.
I don’t mean just spending time in debugger. I mean, just fixing, you know, issues. In general, I’m using it as a more general term, like, cause I have like, I have an issue right now at work. that my company Peter is the only, is the only one that needs a special piece of that XML inside of the Bay configuration file.
Right. And I had to, I was working with our architect to try to figure this out and I ended up figuring out the problem cause I spent a lot more time on it, but I spent. in order to amount of time, uninstalling, visual studio, uninstalling, uninstalling, all that, these different things in the, in the doc Netspace to try to end reinstalling them, to try to get it working and.
the issue is still there. I have to, I have to actually replace this piece of code that I have. I always have to carry around with me from each, get each, each commit and make sure I don’t commit it if I want it to make it work. I can’t remember how to add it. Cause it’s been in a while, but I’ve added this piece of code back and it’s just silly things like that.
That can take an order amount of time. But I wanted to get back to your point about productivity, because I think you made an interesting point. What is productivity? Right? Because. I think you, can I be interested in dig into these articles more and see how they measured it? Because I imagine that use the, they use some type of metric because if you do, yeah.
After the fact, right? So if you do lines of code after the fact and developers don’t know they’re being measured, like that’s probably a better thing than saying, Oh, I’m going to measure how much lines of code you produced. Right. Cause that kind of starts to even it out, because if you’re not, if you’re not measuring it as a metric, right.
If you don’t tell them you’re measuring their lines of code, then it, th th that’s not in their minds that they’re going to measure it by
Douglas Hirsh: [00:10:18] it. Well, I want to say without. Without actually looking at the lines of code that a developer is writing, that you, you would, you would still have a problem there because you could have a less talented developer writing, more lines of code.
But if you’re only measuring lines of code, then. Then your really talented developer that can very concisely communicate to the computer to do something and mind you in a way that’s still a human readable. So there’s actually multiple variables here, is cool to be more talented than someone that even if you’re not telling them, you’re measuring lines of code has to write multiple lines of code for something that might, should only be one.
Or two lines of code and they’re like doing five. Well,
Tyler S. Lemke: [00:11:08] yeah. And that’s, there’s, there’s other debates about that too is cause I, I actually write so for my, if statements, one thing I loved from, from, from, code complete, for example, was, was the fact that, you can. If you’re, have you ever had a bunch of like oars or, or ans inside like a huge conditional that has like four or five ORs or ans inside of it?
You’re like, what does the same doing right. And that’s what I used to, I used to see quite a bit and I’ve started to break out every single piece of it. I break out into its own variable. So now it just reads if is this, and is that, and is that. Then it go into this, go into this method. So that produces more lines of code, but it’s much, much more readable,
Douglas Hirsh: [00:11:54] right?
Tyler S. Lemke: [00:11:54] In my opinion, like in the, and you know, you can debate about some things, but I don’t see how you could, like, you don’t have to think about it as you’re abstracting away the underlying detail and going. Is that, does this do what I want it to do, which is actually documentation,
Douglas Hirsh: [00:12:11] right? That’s where your, your code, your, what is it?
yeah, you know, uncle Bob has said that, that your code should read like good English prose and, you know, naming variables in ways that don’t lie. Right. You don’t want your want them to lie, but in essence, you could write code that reads like what it should, and what you’re describing is what you’re talking about.
So there is, there is bit of a, You know, balance between being super terse and going, Hey, I just wrote this thing on one line of code that really in your head, you would have to think very long and hard about what this one line of code really is doing, as opposed to having, having your code broken out into separate, like, especially your, your.
Your bullying logic that you’ve broken out and you’re doing all these ifs. Let me ask you something. Do you ever get any pushback on code reviews? As far as that’s concerned? I am curious if anyone has a problem with that.
Tyler S. Lemke: [00:13:11] I’ve only started doing it more recently, but I haven’t gotten any pushback on it so far.
I used to look at code that actually did that. Like, I was like, why did he, why does he, like, I was looking at this code base at one point and I was like, actually, that’s. That’s not bad to actually say what you’re, what you’re trying to return. Cause I know of another developer who would do the same thing for each return value and actually named that return value instead of just, you know, doing some complex statement, or return before it, I think that’s where, you have to value readability over terseness.
Right. Like you have to value, your code being much more readable. And part of that comes down to most developers don’t understand that your code is read nine to 10 times more than it’s than it’s written. Right. It’s read many, many, many, many, many more times than it took you to write it. Right. If you don’t count, right.
If you don’t count, you know, the actual mental, the mental, like, you know, effort, it takes to, you know, decide on patterns and, and implementation details and everything like that. But even then a lot of people, when you code go into a code base, you’re, it’s going to take a while for you to understand.
And any junior developer out there is pro is saying that same thing. Right? Cause that’s what I, that’s what happened when I was a junior dive, when I was actually an intern, I was like, You know, we need comments in this code base. I have no idea what’s going on here. Right? Cause, cause things, and whether that was my own lack of my own ignorance and, and, inability to study it, what could have been part of it.
But, I think code base is in communication. you have to, you have to speak to your lowest common denominator on your teams. Now, if you think everyone’s going to be a senior developer and they all have roughly the same experience, you might communicate differently. Then if you have a bunch of junior devs and that’s just like, if you were to write a book, right?
So going back to the writing analogy, if you’re going to write a book. Are you going to write it to teenagers that are in the adolescent and their youth, or are you going to write to, college students or to grad graduate students? Right. And so, and I think you’ve had this experience as well with even architectures.
I remember you said only one project you’ve worked on. It had so many, what it was microservice-based has 164 different repositories and. and it was very hard for you to understand. I could imagine if I tried to jump in it right now, I’d probably confuse. And then a brand new developer that’s coming out of your bootcamp would probably be very, very, very confused.
Douglas Hirsh: [00:15:40] Yeah. I, I was, I was the, when I walked away from there, I was like, they were really lucky that I was the one that walked in the door. Cause there’s not many people I know that would even have had the patients like they would have come in and looked at the code base and been like, I quit. It wouldn’t have even been like to be in it.
I enjoy stuff like that, but it was painful. It was actually very painful to piece together what was going on and even feel comfortable enough to make changes because of how spread out it was. This is one of those situations where, one day, if we ever want to get into it, like the difference between using multiple repos and motto repose.
that would be, or a single mono repo, to do stuff like this and get, would be an interesting conversation to have, because if we, it had a mono repo at that job, but all these projects, then at least I could have seen how everything connected together in this one on a repo. But that is not how it worked.
And so it was, it was a very painful setup. It was painful to maintain a, it was 146 repos to be exact, that number is seared into my brain forever because
Tyler S. Lemke: [00:16:55] 46. Yeah.
Douglas Hirsh: [00:16:58] Yeah. I mean, do you ever walk into a place with 146 repos? And you’re the only developer in the house? It’s it is, it is not a fun time, but it’s up to you, whether it’s success story or not, you know, most people, it wouldn’t be, I would say that most people would not have the wherewithal to stay in and, try to try to figure that out because there’s places you can go work that are much less cognitively heavy than having to try to work that problem out.
Tyler S. Lemke: [00:17:28] So productivity, what, what do you think are the, I’ve got some ideas for what, what, what productivity is, right? Because we’re, we’re still kind of figuring out what’s this 10 X mean? So what are the different, what are the different pieces of productivity? I think part of it could be. You know, very, a very, non granular metric is lines of code.
Right? I want to say that is some metric, whether how good it is is very debatable, but it’s something right? Because it tells you a little bit of something it’s not, it’s it doesn’t, it doesn’t hone in on whether or not they’re really good or not. But you know, if someone can crank out a million lines of code a year, another, person’s doing 10,000, the million lines of code.
Is probably more productivity, whether or not it’s great. It’s more work, right? Like overall, can we agree on
Douglas Hirsh: [00:18:18] more keys on the keyboard being put, right,
Tyler S. Lemke: [00:18:20] right. That’s what I’m saying. But I’m
Douglas Hirsh: [00:18:21] saying whether that code, whether that code is doing more than the 10 then than the 10,000 lines of code. That might be, that’s a, that’s a really interesting question, but the fact is that, that they, they, they typed out a million lines of code.
Now we don’t know how long those lines are. Like maybe they put their curly brace for the, if statement on the next line and that gave them an extra, a hundred thousand lines of code or something who knows. I mean, if you do have a million lines of code, who knows if that, if, how you do your curly braces after, You know, for your functions and if statements might actually affect how, and I’ve seen some styles where the curly brace goes on the next line, instead of on the same line, as, as your if statement.
So, I mean, just even simple things like, will you talk about a million lines? I go back to. What does the code do? Not necessarily, what did, how many lines of code that they write? And that’s where things get a little strange, because it’s really not. productivity it’s software development isn’t necessarily about writing the right code all the time.
It’s also avoiding writing the wrong code and, and writing stuff that, that, isn’t going to be needed. And cause, I mean, maybe they did specked out like a million lines of code, but only, only a 10,000 lines of that code ever sees, you know, is ever used. Even in that system with a million lines of code in it.
Tyler S. Lemke: [00:19:54] So that’s yeah, I think that’s a good point. So the. But it is some form of metric, right? So it’s some form of metric. Cause you get, you get to something else with the complexity as well. Right? Because actually code complete goes into different complexities. Like the diff it depends on, are you in the aerospace industry, right.
That’s going to be a completely different lines, the completely different type of code versus, you know, you know, spitting out web code. Right. And then, or, or doing, or what if you’re, you know, making lifesaving devices, right. You’re, you’re, there’s different, there’s, you know, there’s different requirements and there’s also, you know, you build things differently in those different environments.
At least I would think so. I
Douglas Hirsh: [00:20:38] think there’s different cultures too. Right? You may not even have the space to have a binary that is. Above a certain size or to use a certain, you know, you can’t use more than a certain amount of memory. So you’re going to have to write things differently to, to be able to, to handle the environment that you’re writing code in.
So, you know, that’s, that’s the thing. I think if, if I really wanted to throw like, like just a wide swath out there of stuff that, that, you know, what I would consider. Hey M. A 10 X developer would be, it’s gonna sound like there’s no, there’s no definite metric for me, but it would be the person that writes the right code knows when not to write code knows when not to even do a project.
That was how to argue against the fact that maybe this project is not something we should be doing and has that experience. you know, even, even to that point, And that means that that, no, it doesn’t look like they were very effective, but they basically stopped an entire development team for working three months on something that, that, that would have been absolutely useless.
So it, it, yeah, you really get off into to this, this, what is a productive. Member of a team and that comes down to what does a productive senior developer, what is a productive junior developer? What is a productive, mid level, you know, and that’s, I think it’s, I think that there’s so many different, what’s a productive art, software architect, you know what, cause I’ve, I’ve kind of had my finger in all those different areas.
And does that make me more productive? That I’ve been in those areas. If I look at a problem and go, yeah, we never want to go down that path. This is the path to go down. Here’s the exact code that we, you know, to, to solve this problem. But then like there were 17 other different possibilities that occurred.
But I narrowed down to the simplest one. I didn’t write 5,000 lines of this other code, but I wrote a hundred lines of this code that did that accomplish the end task. At hand, is it, is it about how fast can we maybe it’s about how fast we can create a solution for the person or for the, for the company or our manager or the product owner that they’re requesting a solution, you know?
And it conforms to what they think that solution, you know, what it conforms to. What they think it should be. Right. It actually does the thing that they ask for.
Tyler S. Lemke: [00:23:30] So I think, what do you think about special, especially because what comes to mind with what the Tenex developer is specialty? Cause we’ve talked about this before as well, like with, there’s a business idea where you basically.
use perfect something and you crank it out over and over and over again. Right? So you, you perfect. Perfect. It actually might be a piece of code, right? So you’ve actually written this piece of code once, and then you go and, you go and reuse that piece of code over and over and over again. So one example might be how about someone that uses Google maps, API.
Is there a developer that could be 10 X on that versus you or me and I haven’t used Google maps very often. I’m sure there’s developers who are 20, 30, 40 times faster than me, especially given the, a specific domain that uses esoteric API APIs. Right. So, I think if you think about specialty and you think about developers who are really good at one thing, we’re not used to having developers who are really good at one thing nowadays, everyone’s trying to go over to the full stack dev so they can kind of, kind of get milk you more for the money.
And it’s just, and you know, smaller teams need people who can do lots of different things. Well, I
Douglas Hirsh: [00:24:44] was gonna say that, that when you said milk you for more money, I’m I’m my, my mind is going to people who want to pay one developer per for what they would normally hire three people. So maybe, maybe give me 25% more since you’re going to only hire 33, you know, pay out 33% of the salary.
You know, that’s,
Tyler S. Lemke: [00:25:05] I’m not against it. I’m not against that business model either. Cause I don’t think they necessarily, like you might have to hire just as many developers, but now you have a more diverse team. So instead of hiring, you know, one front end person and one and two back end people, you might get three full stack devs, and then they can all work on everything.
Douglas Hirsh: [00:25:29] Yeah,
Tyler S. Lemke: [00:25:31] well, might be a much slower than that front end person, right. They might be, you know, half of them that thrown in person could be three times faster than them at doing, working in a framework.
Douglas Hirsh: [00:25:44] Right. So think about that for a minute. So someone that specializes on the front end, who loves CSS, who loves HTML, really has studied how to do semantic HTML properly so that they could just write in the first try.
They write out HTML that screen readers understand for instance, and they do their CSS in a way that looks beautiful to the eye. And, and they’re going to be the, that developer who does. You know, front end, HTML and CSS, and really knows both of those languages very well. And some JavaScript, maybe so pure front end.
They’re going to walk in and someone’s going to say, I need a front end that looks like this, and they’re going to go type, type type. And here’s here’s that. And maybe not even have to go Google as much or anything like that. but if you were to tell someone who specializes more in the backend, Oh, by the way, we need you to make the page look like this on the front end.
Well, you’re a person who specializes more in the backend who has that skill set is going to go, okay. They’ll do the back end. They’ll go to the front end and then they’ll sit there and Google and everything. And, and that’s not necessarily bad. I’m not saying that’s bad, but specialization will help in productivity because if you can narrow the number of things that you have to keep in mind all the time.
Then that reduces the cognitive load of doing your job. It lets you pick the tools that, that narrow set of tools to get the job done faster.
Tyler S. Lemke: [00:27:14] It goes down, it goes down to chunking. Right. Have you heard of it? The, the, the black, the black cat drivers in London? Have you heard of that? Yes. Yeah. So you’re familiar with, from all the different books we’ve listened to, right?
It’s an, every one of those books,

Do you want to relate it a little bit? Yeah, let’s talk, let’s talk about that. So maybe you can correct me, but from what I understand there, I think it’s a certain type of cavity. I forgot the exact, there’s a, there’s a, basically a test that they have to go through.
Sure. And I think on average people fell it like multiple times on average, before they get it, like, I think I’ve heard it’s up to you. I want to say 11 times, but that sounds, it sounds really high. do you, were you able to find which one it is
Douglas Hirsh: [00:27:57] like trying to look it up right now? Cause I know what you’re talking about.
There’s a lot of books that we listened to that talk about learning. And one of the things is that when, when one of these cab drivers and this is in, this is like in the UK,
Tyler S. Lemke: [00:28:13] it’s called the knowledge.
Douglas Hirsh: [00:28:16] And, and, but, but when they get their license, in fact, people have done studies on the brains of these cab drivers because they have to memorize.
They basically have to do what, what Google maps does for you. They have to, they have to come up with the best route to get from point a to point B and they have to do it all in their head and write down the route. I mean, there’s no Googling for them. They have to memorize, literally memorize the streets.
Tyler S. Lemke: [00:28:43] Yeah. So it’s today they have to study 320 routes, 25,000 streets and 20,000 landmarks, and then they have to memorize them all. And they’d done. Did you talk about the brain scans they’d done yet? So people’s
Douglas Hirsh: [00:28:55] brains actually. They changed scan the brains, right? They, they, they change too to be more geared toward a spatial.
spatial ability and, yeah. Right. They’re
Tyler S. Lemke: [00:29:06] not born with this either by the way. No, so, and there’s nothing they’ve done. They’ve done enough studies that show and you lose it. Once you stop doing, you lose it. And so that’s the same thing that happens. This goes back to why I liked the space repetition stuff is cause you don’t lose it.
Cause you’re going to actually go back and learn what, like remember it. But, the,
Douglas Hirsh: [00:29:26] by the way, it’s called a Hackney carriage is what type of cat is. Yeah. The Hackney carriage drivers are the ones that have to pass the test called the knowledge. And but like you said, you, you threw the stats out there about what they have to do, but it’s.
That’s an amazing feat, right? Basically become a human, a human GPS.
Tyler S. Lemke: [00:29:47] Right. And there’s there’s developers who don’t, who’ve done this. I’m thinking there’s this developer who has his own like video service where he he’s a Ruby developer. You might know who it is. I’ve tried searching for him. I couldn’t, because I come across so much different stuff online.
I’ve found him a long time, but he does TDD. And he types it like 120 words a minute while he codes. And he can think he can think that fast when he’s typing. and I’ve just read about what, how, how his videos are. I haven’t actually watched it. but I think people like that come to my mind and go, okay, there’s something different.
If you can type that quickly while you’re coding and you’re actually able to crank it out, that means that you’ve, you’re kind of like these taxi drivers. Right. For at least some things you can crank out code that quickly because all the APIs are in your head. Like you don’t have to think about, you know, the, the design patterns that are all chunked down and you, you you’ve optimized your brain in such a way that you can code potentially five or 10 times faster than.
The average developer. I think it’s definitely possible. I don’t think it’s common. Don’t get me wrong. I don’t think it’s common, but I think it’s definitely possible. And I think he’s one of the examples. That’s
Douglas Hirsh: [00:31:04] not common, but she would have to have so, so it would happen to be a narrow enough space, right?
You’d have to say maybe, maybe I’m going to be in dotnet or I’m going to be in Ruby. And these are my tools that I’m going to use to do the things that I need to do. And then you could actually create that kind of, that kind of internal GPS routing, like you were talking about, to, to be able to crank code out.
Now I do want to say something about. If it’s in a video and someone’s typing, if, if they are. Cause there’s ways to do videos where things look faster. And, and I mean, I, I don’t know. I’d have to actually see the person do it. And, cause I’ve watched people who’ve done these videos and they’re like, I’ll speed the video up to get the typing out of the way as quick as possible.
So I could talk about what I just typed on the, on the screen or two, they have the code sitting at another window next to them. So they’re just typing and talking at the same time, but literally transcribing code, not actually live coding per se, but, but. They’re they’re transcribing a bit of, of what’s going on, but I could see, and this is where I, what I do concede, right.
Is that, is that if you do have the, like, like the, the cab drivers, the Hackney carriage drivers, and yeah. In the UK, if they’ve got, if they’ve got all the streets in their head, it’s someone gets in the car and says, I need to go there. They don’t have to GPS. They can just go and start and start going on their way to get to the place, to, to get there, to get their, the, the writer there.
But the, the other piece of this with development is I could see if you stay in the same, in the same language and you stay with the same API APIs and you do a lot of the same things. You know, maybe just a little bit, you have to do things a little bit differently though, in order to be building skills up.
But I could see someone say, I need to get data out of the database. I need to get it onto a form. I need to do these validations on it. And someone knows exactly the path to drive to get to that. To that position. They know that like, if you have a, a common, a common architecture in.net is, you know, you’ve got your, your services that talk, well, first of all, you got like entity framework and then you got to service that, that acts as an intermediary layer between that.
And then you’ve got your controllers that use the services that you’ve got. You may even have another layer between that, the business logic layer that uses the services. I don’t know for sure. So I’ve seen a lot of different, a lot of different architectures. You have a controller and you have a view and, and if you know how to wire all this stuff up, you’re going to be very productive.
You’re going to know how to get from point a to point B very fast and maybe, maybe. Maybe 50 times faster than, than the new dev that walked in the door. Right. You know? Cause you could visualize every place that has to be touched. Right.
Tyler S. Lemke: [00:33:58] And you know, so that’s part of it. Right. And the other part is the.
The developer like yourself, you know, that project, we keep going back to where you did TDD and I’m a fan of TDD. I don’t, I’m still not practicing it, but I’m getting more used to unit testing and doing more unit testing lately, trying to work my way there. But, Where you did that, you did that project and you said they basically didn’t have to touch the code for like eight years.
Right? So the amount of product dev productivity you had on that project with when you take into account maintenance costs, which is typically, Oh, man. I can’t remember exactly. I think he said maintenance costs are, I want to say it’s like 50, 50% or more of the PR 50 to 80% of the project is maintenance costs.
for, for software development, I might, I might be wrong on that. You’ll have to go refer to code complete, but, maybe I can find it here while I, while I look. But, that’s amazing, right? Because you consider how productive was that, right. If you’re writing, if you wrote something, you wrote it once and you did it in a reasonable amount of time, you know, and granted productivity is hard to measure, right?
We’ve already, where is very said, productivity is hard to measure, and this is why there’s no, there’s no good tooling out there for measuring productivity. Right. Except for the best thing that we have is maybe a scrum and agile, right. Where you try to point things and see, you know, you kind of compare people to their peers, but that’s only comparing people within their same companies within their own domain.
Right. It’s, it’s hard to know is this person at that company 10 times faster than me, right. What are your thoughts on that?
Douglas Hirsh: [00:35:41] So I would say that that’s a, that’s a really good point because the, they didn’t need to add new features to the system. Then they, it may not be, have you been the primary system that they, that they were using for that, like that, that payment system may have not been used a lot, but still any time someone did a transaction on it, it worked.
And so that’s, that is the, the important thing is that it actually stuck around. I mean, a lot of times you write code and things just start. Having problems, but so that code was written with the thoughts of, of dot lions of code, but flexibility and architectural design, architectural boundaries. We can each of the components.
So things just didn’t do things that they shouldn’t be doing. I kept things, I kept tasks in, you know, I kept, yeah. Architectural boundaries. And I worked really hard at maintaining those architectural boundaries, even though I was the only one working on it, I could have done whatever I wanted. Once I set a boundary, I let that boundary be set and I didn’t cross it just to get things done a little bit faster.
And so I was very disciplined about that project and the code involved. In that system, maybe this is there’s a correlation here that we don’t, that we could investigate at some point, but the actual amount of code that I had to write to make all that work in the end was very minimal. Right? It did a lot.
It actually handled, it was a payment system. The, the point of sale system, talk to my payment system. And, and essentially we got, whether transactions were okay to start or not. It got whether they had like, they, you know, Text messaging. When was, was a, was it input into it? The point of sale was an input into it and even, our ACH gateway, was it input and also, well, yeah, basically an input.
Cause you’d send out, Hey, are they good to start this transaction that they’re trying to do a $300 transaction or a $100 transaction? Are they good? You know, are you good with them doing this? And here’s all their info. So. The amount of code involved in that project though, was very minimal. the sad thing about the fact that they hadn’t had to touch it in eight years, and I think they lost all the code is that they lost all the code though.
Like I had a whole suite of tests and everything. And if you’ve lost, if you’re decompiling the binaries, you know, if you’re decompiling the DLLs, you don’t, you don’t have that test suite anymore. That’s a really scary thought. So, I really wish that there was a way that I could have helped with that when, when I got that phone call from the developer at that, at that company.
But, you know, I wrote it intentionally to be something that would just run. I didn’t want anyone to ever have to go into the code and do anything. And it worked. But that was that’s another case. Right. I could have used a lot more code. I could have, I, I was one of these guys that, that, you know, it was like, like don’t repeat yourself and, seagull responsibility principle, and you know, all, all of those, all of these things were in my mind as I was working on this, but other developers that were next to me didn’t know those concepts.
Right. You know, they weren’t familiar with them. So that, and that was the reason why I was working on the project because they, you know, when, when the guy at the top said, I gotta make sure this is done, it’s gotta be done right. The first time we can’t go back and do it again, they threw it at me. Right.
And, and, And not that that’s not a brag, right? That’s yeah. Sometimes I wish they had thrown it at somebody else to be perfectly honest with you. Cause the, the, the few months I worked on that project, it was, it was a real pain. but yeah, it’s a surprise that when I left the company, it just kind of, it kind of kept itself running.
So, and I’m sorry, but, but that’s productivity, right? So. What is productivity? No one had to go in there and look at that code all the time. Yeah. I wrote it once I spent three months, I wrote that code once and no change requests.
Tyler S. Lemke: [00:40:06] You’re the Tenex dev at that company, man. That’s it right there. You were the Tenex dev for them at that time for that as project.
Douglas Hirsh: [00:40:15] for that project that would have been five
Tyler S. Lemke: [00:40:19] X or whatever. Yeah. Like let’s say it was two X, 10 X, whatever. Right. It’s it’s some factor you were much, you were probably much better than other developers would have been. Right. Cause no one had to come and touch that code again, which is really important.
Douglas Hirsh: [00:40:36] Right. I mean, if you’re, if you don’t need to make a change to the code, then, then you shouldn’t have to go in there and, and make a change where even that system was a little, Actually, it was kind of cool because I even made it to where you could modify it from the database. Like it would go in and pull in.
We use stored procedures. Like this is, this, this company did not subscribe to entity framework or anything like that. So stored procedures, whereas a place to do a lot of things. And so, if you add it stored procedures with the right names, it would actually create new commands for the text message parser.
Like you could literally just never touch the.net code. Wow.
Tyler S. Lemke: [00:41:16] That’s really cool.
Douglas Hirsh: [00:41:17] So, no, I mean, that’s, that’s kind of, that’s, that’s kind of the stuff I was trying to do. I was trying to make it to where we didn’t have to recompile and drop new binaries every time someone wanted to do something. And, there was very, it was a very dumb application in the end and even the store procedures were pretty simplistic.
By the way, I test drove the stored procedures. So in case he wants, like, but you didn’t do TDD and the database, TC Quilty absolutely. Was doing test driven development in the database. yeah, so,
Tyler S. Lemke: [00:41:48] so. Yeah, I think so. I think that’s, that’s interesting. We discovered a 10 X developer day, everyone, so
Douglas Hirsh: [00:41:55] well now my face is turning red.
If you’re listening, you can’t see it, but it may be, even if you see the video, you can’t see it. Cause I’m a little bit in the dark. Right.
Tyler S. Lemke: [00:42:04] Douglas, we all know you’re very humble and I’m there you go. Testicle ones. So, but the, so there’s a few articles that we kind of came across in this and. you found one on Twitter. Do you want to read that? I guess there’s was a tweet by, someone, I don’t know if we want to, I guess I had the link in there, but this
Douglas Hirsh: [00:42:22] Scott, go ahead.
Tyler S. Lemke: [00:42:25] Sorry. What’d you say?
Douglas Hirsh: [00:42:27] I would say I don’t, if it’s the one, I think it is, I don’t want to read the whole thing, but maybe we can, we can summarize it a little bit.
Yeah. It’s cool.
Tyler S. Lemke: [00:42:34] It’s quite long. I think I came across this as well. now that I’m seeing it here, cause you said this was quite controversial, so what’s the gist of, sh I think his name’s checar, was saying, how do you spot a 10 X engineer? And, I believe there’s another link I have that, talks a little bit about it on, LinkedIn that I dropped in here, but, he’s a venture capitalist, so there’s a few different means 10 X engineers, hate meetings.
I think a lot of developers hate meetings. I think that’s,
Douglas Hirsh: [00:43:07] that’s, that’s not a telltale sign of a, of a 10 X Def, because if you hate meetings, it means that you’re not going to take input in from people. And part of your code has to conform to some input that they’re, that they’re giving you.
Tyler S. Lemke: [00:43:20] I mean, it depends.
It depends on if, if you have perfect, if you can get, if you can get perfect requirements to a developer and they don’t have to, let’s say that they are, you know, not neuro-typical, let’s say they have Asperger’s or they have, they’re autistic, right? Cause I have some relatives that are autistic that want to become members.
And, let’s say that they have that and they have a immediate, they have someone in between that gives them the requirements in a way that they can understand them. Right. Could that still be a 10 X dev? I’m just trying to play devil’s advocate here.
Douglas Hirsh: [00:43:55] Well, again, I mean that’s, but that is not the tail.
That’s not the end all be all to a 10 X step. Right. They may be good at cranking it.
Tyler S. Lemke: [00:44:06] Yeah. Most of them.
Douglas Hirsh: [00:44:08] Let me give you. Let me give you a story. So, you know, because communication is hard, right? Getting, getting something down that someone’s asking for on to a, into a document and giving it to a developer and letting and making sure that they understand what that means is, is actually really difficult.
And I remember when I was working in logistics, That there was this one time where, I would, I was working on a feature and the product owner would come down and tell me they need this. And I would produce that and they would come back and go, no, we don’t need that. We’d eat this. And I would produce, and I was like, wait a minute, can we just get it?
Like, where’s this coming from? And they’re like, well, one of our customers is asking for this, but we can’t seem to get it right. I’m like, well, put me on the phone with the customer. Like let’s get a meeting set up. So the customer could tell me what they’re trying to do. And then I can, I can take notes.
And then I did, and I was able to, I take the notes down and it was entirely different. Like telephone, that telephone game was in heavy play because the person in the middle was not understanding, meaning what the person wanted. And when the person told me directly what they wanted, I could actually see the code that needed to be written to make that work.
And the next try was a success and we were done. So I’ve had times where it was a lot more inefficient to have someone pull the code. But if I couldn’t talk to someone, if I couldn’t talk to that customer, Then I would have never been able to pull the requirement out and maybe it’s the fault of the company I worked for.
Maybe they didn’t have,
Tyler S. Lemke: [00:45:46] that sounds like a problem with elicitation of requirements. Right? That sounds like that’s the issue. Not, not the, not that, not that you had to be the one to do it. It has to do with Zipcar. Was it good at their job or at the job that you’re given?
Douglas Hirsh: [00:46:03] It took some kind of context of understanding what was going on underneath the covers to really be able to get what needed to be done, to make what they want it happen.
And the one sentence that the person gave me when they said it, it clicked with me what they were, what they were trying to do, but the way that someone was recording it, that didn’t understand how, you know, what the system was doing underneath the covers, kept writing something else down instead. And so that, that five minutes that literally one minute, the first minute with the customer, that when we started talking about it, I was like, Oh, I know exactly what you’re trying to do.
Like, let me, you know, I can go do, and it was an important customer. So that’s why I’m like, look, we don’t need to do this. Let’s just sit down and talk to the customer. and these and this person was good at acting writing requirements down, right? This that we were, it was just the communication, the way that the customer was asking for it to be done and what the person in the middle understood how things worked.
Was not, there was an impedance mismatch between the two. And once I came into the picture and could had it in my head, what the code was doing, that they were asking about changing. I was like, Oh, so you want to do blah, blah, blah, blah, blah. But if I couldn’t talk to someone and I couldn’t even talk to the person above me, well, to tell them that I think we have a problem, I need to sit down and talk to the customer, that.
That would have been, that would have been a, that problem may have never been solved or it may have taken a lot more tries to get it solved than just like on the third, try, go in there and get it. and you could lose a customer over the number of tries. It takes like, Hey, we did it for you. And then it doesn’t do what they want.
Hey, we did it for you. It doesn’t do what they want. Eventually. They’re like, we’re going to take our a hundred thousand dollars and spend it somewhere else. So
Tyler S. Lemke: [00:47:52] I think that’s, that’s kind of, it goes to good analogy of like, you’re trying to climb up a building or something. Right. And you put your out ladder against the wrong wall.
Like, it doesn’t matter how, like how far up the climb up that building. You’re not going to be at the top of the other building right when you’re done or I’m mixing it up, but you get the gist of it is that it requires me if, if. If people don’t understand requirements gathering is so important because if you build the wrong thing, you’ve wasted the most amount of time possible.
Right. So he said all the time critical all the time.
Douglas Hirsh: [00:48:21] Yup. Right. And,
Tyler S. Lemke: [00:48:22] and all the opportunity costs. Right. Cause if you build the wrong thing and you missed out on millions of dollars of business, because it was time, it was time critical. Right. If you’re in a startup or, or, or something’s going on, that is very, Very costly and it’s very important.
Douglas Hirsh: [00:48:39] but that’s why I’d never, I didn’t mind going to meetings. Right. But it had a meeting like that was important to me. Now we did at one place, I work have a meeting where all of development met in one room and went over all of their projects. Like what everyone was working on. So what would happen is because of equalization, you know, in games equally comes from game theory.
Everyone felt like they had to say something. So everyone kept trying to say stuff for longer to make it sound like they were doing more. So these meetings that they had, like $20 Clippers in there kept getting longer and longer because everyone felt like they needed to say at least two or three minutes worth of stuff to get, to get done are to sound like they were doing something.
And what would happen is, is that, like we had one developer who fell asleep during this meeting and we had another developer who would shoot pictures of the sleeping developer. And that meeting to me was like that. Yeah, I resisted those kinds of meetings. I really complained a lot about like having meetings where people were just shooting pictures of people falling asleep, and that was the value that people got out of the meeting.
And, and so I think it’s, again, They saying that they, they hate meetings? No, I loved productive meetings. I hated meetings where we just went and spent time talking about, you know, things that didn’t, that didn’t help me do my job better and try to help me get, get, you know, for more productivity for the person that was paying me a lot of money to do the work.
Right. That’s that’s a misnomer right there. I think.
Tyler S. Lemke: [00:50:17] So this, this article though, going back to the article, I think it’s, it’s, it’s kind of comical reading it, right. It almost seems like a piece of humor to me. And I don’t think it’s entire, it seems like satire, but I don’t want to rag on, I don’t want to rag on Chicago.
Right. I don’t want to be like, Oh, why? Like, I think there’s well, as I read this, like just like kind of unfiltered, I see, like this person doesn’t understand software. Like or development. Like this person is not very technical. That’s how it comes across to me. Things like this are said, 10 X engineer, laptop screens, background colors, typically black.
They, they keyboard. He is such as I F X are usually worn out more than a S E and E it almost comes across. Like they just came up, like it doesn’t sound right. Very, and well-informed, you know, I, I, and doesn’t that seem like. Did to you as well, like this does this kind of just, that’s why it seems like really listening to like satire.
Douglas Hirsh: [00:51:18] don’t think it is. No, I think it’s serious, but this person, when, when this, this, Twitter threat came out, it. And this was, this was a year ago. Like we’re literally talking about a Twitter thread from a year ago. If I remember a Twitter thread from a year ago, then it must have cost something because, there were a bunch of people that responded to this.
Like how do you know? there, there were a bunch of other, other people on Twitter that, that just like tore this to pieces and not, not in a way, like directly torque to pieces, but just like
Tyler S. Lemke: [00:51:50] Twitter, come on.
Douglas Hirsh: [00:51:51] That means you don’t just. Just the memes. We could literally do an entire show talking to each of these points and maybe we should have, maybe this entire show should have been talking to, to, these points because a lot of these are the myths, right?
I don’t hate meetings or what have you. And I think a lot of,
Tyler S. Lemke: [00:52:14] yeah, why don’t you pick up, pick another one and, and debunk it or agree with it. And maybe we can pick a few and, and point them out.
Douglas Hirsh: [00:52:26] Well, I don’t want to have too much of a, too much debts, you know, let’s see here. So, Let’s see, 10 X engineers are peers as they can’t teach others on what to do or parcel of the work. They also think it takes long to teach, or it takes too long to teach or discuss with others. I would rather do it myself.
They are also poor interviewers. Okay. That just describes a title of developer. Maybe not one that I would want to work with. Right. That’s that’s the thing is, is that. And I guess this may be the path that I went down. Right. I went and did development for a long time. And then I said, I want to go teach, right.
I, the heart of a teacher. And, but I don’t know many people that are like that. Even the ones that were really good. Even sometimes we would go too much into stuff. And I was, we’ve been guilty of that at one time. Right. If someone said, Hey, what about this? I would just go through the whole like, like throw the whole architecture out there and, you know, put too much out there, which that’s a skill too, figuring out how to give just enough information.
That’s what the teaching helps with. The teaching helps with how much information do I have to give someone for them to learn a new skill? I don’t have to give them everything. I don’t have to teach them everything in my head. I just have to give them enough to let them make the leap to the next point.
And, but I do. I do know. Yeah, it’s it is, it is definitely a hard skill. Actually it’s a soft skill, but let’s talk, it’s a hard skill.
Tyler S. Lemke: [00:53:58] It’s a hard, soft skill to require.
Douglas Hirsh: [00:54:02] But, but this is, this is absolutely another one of those where. Where, if you want a good team player, you might be able to find a dev who is a hundred times could do a hundred times more work than another dev.
But if, if they can’t do all the work by themselves and they require a team, then at that point, everything, all that house of cards falls down. Because, they’re not going to get as much work done because the rest of the team is going to be not working well together. And that’s going to cause that’s going to cause productivity loss across a set of developers.
You’re going to bring down what the potential of a whole group of developers, because one person won’t communicate and I would not want, I would actually say that if I had, if the 50 X or the a hundred X a, I had an opportunity to hire one. I wouldn’t, if that is. A requirement of them, which is that they would rather do it themselves than, than have mentor.
Because at that point I can’t, you can’t scale it anymore. There’s a point where you stop being able to scale. I don’t care how X, how much Xs you have in your, you know, in your skillset, you will hit up into point. You will not be able to scale beyond a certain point. And if you cannot communicate with a team.
You’re going to bring an entire team down.
Tyler S. Lemke: [00:55:29] No. Yep. I totally agree. there’s a lot to, to tear apart here and th
Douglas Hirsh: [00:55:36] this is a good one. This would have been a good one just to even base the entire, the entire episode around, because it
Tyler S. Lemke: [00:55:43] is, I think I want it to be fair. There’s a lot of things in here that I think. Could be applicable to some people, but to say, I think, and you know, what the internet loves, loves when you’re polarized.
Right. And neither one of us are, you know, I’m, I’m dogmatic about certain things. but I think we can both. We’re both rational and we both try to get at the nuance, but, which is probably a problem for actually getting traction and getting people to do things. But, you know, getting like riled up behind things.
And I think that’s why people responded so much either negatively or positively to this message was because. to me, I get this visceral response. Like this is a lot of this is wrong. Right. And I could, I could go part a lot. I could go into a lot of it, but I wanted it to be, this last one. it said that 10 X engineers basically don’t write hacky code.
Right. They don’t hack things. They write quality code and know exactly how the code has to evolve and to have a mental model, the overall code structure. And I actually know an architect who, who, he, he said 10 extra years or people who actually do write hacky code and they’re just produced quickly and they produce junk code quickly.
Right. And he said there, that could be a 10 X engineer. And I could see, I could see both ways. I get to people that crank out code quickly, but it’s not necessarily the highest quality code. It might not be the most readable. It might not be the most, right. If you’re playing code golf with your code, is that the best code?
Well, you know, maintenance, I was just reading, and code complete maintenance programmers spend 50% of the time, time, reading code. Right. So someone’s going to have to come back and, and, on average, you know, re look at your code and go, you know, what does this pile of junk? Right. And that’s what I, that’s how everyone looks at their old code anyway.
Right. They look at their old code.
Douglas Hirsh: [00:57:32] I’ve talked to my students about that. Yeah. Definitely. You’re not going to love your code. If you have to come back and look there,
Tyler S. Lemke: [00:57:37] especially other people’s code, you’re going to go back to their code and you’re going to judge them just as, just as much, if not more.
Right. Cause you’re like, well, I didn’t do it. So they’re even worse. And then I’ve come to realize, man, I don’t think I coded any better. So I should probably be nicer. Right?
Douglas Hirsh: [00:57:50] Well, well the other, the other, the other part of that too, is that if you, if it’s been so long, you, you don’t really know who wrote the code, but you’re like, who wrote this piece of garbage and then you go into blame and realize that yourself.
That’s a, that has happened to me. That’s that kind of mellowed me out quite a bit. Like who wrote this trash? Oh, it was me. That’s so true. So, so that’s, that’s kind of like, Oh, we’re always learning. We’re trying to get, we’re trying to be better at writing code. but yeah, no, the hacky piece about it is, is that now if I had written hacky code for that payment system, how many more devs would have had to jump into the code base?
And, and work on stuff after I left the company. How much is it? Depends on your values, right? It depends on how long the code has to run. I have a hard time writing the hacky code to be perfectly honest with you. If someone came up to me and said, hack something together, as quick as possible. That’s for some reason, my, my background put me down this disciplined coding path, where I think about things I’m methodical about how the system is designed.
I don’t know. Right. I don’t typically I say purposefully write hacky code, and it’s really hard for me to do that intentionally. So it would actually take me longer to write hacky code than to write. Thought out code.
Tyler S. Lemke: [00:59:13] Yeah. I, I like, I like the idea yeah. Of not having hacky code, but I typically end up writing hacky code a lot of the times for whatever reason.
Like, when I was in the legacy system recently, because I tip, I tend to overthink. And over analyze a situation and then it like takes longer to get the code out. So I’d say if you have that same, I don’t think many developers will, but if you’re listening, you have that mindset. I got taught a cool thing by one of the developers on my team and he was like, look, just, just get it out.
Get the code out and then iterate on it, make it better. And that’s really the whole purpose of, of it, especially when you’re learning. Cause if you try to do all the good practices, right. And you’re only in your first couple of years, it’s really overwhelming. It’s very overwhelming because I’m like, I’m trying to do TDD and learn how to land when the API is and learn this and learn this and, and learn like all these technologies right now.
And it’s like, Dude, if I can just do unit testing, that’s great. Like, you know, if I’m doing, if I try to do TDD or approach it, that’s great. You can’t do everything at once. So that’s definitely, cause you just end up overwhelming yourself.
Douglas Hirsh: [01:00:18] Well, the cool thing about, about TDD. Like if you think about this, you could write some hacky code.
Right? You could write something just to get it out. If you’re doing TDD, because what is it? Red, green refactor. So you go read you, you, you get to green. You’re like, I don’t like the way that is. I want to, I want to make that a little bit better. Then you get into the refactor stage things turn might turn right.
Again, you make a green doing the new thing. Maybe you write another test or two and, and you’re good, but you’re right. So the, your. The dev on your team is exactly right. The way to, to get through a problem is to get it is to get the problem written down in some form that works. And then you can look at it on the screen outside of your head and start to look at that and go, Oh yeah, it should be like this, this and this instead.
But if you spend all the time in your head thinking through the problem and never writing a line of code. Yeah, I could see where that would absolutely be a problem. And in the first couple of years, it’s really hard. Like you really don’t want to do it. That’s a culture thing. You don’t want to do the wrong thing, but maybe you don’t want to do the wrong thing because someone on your team is that, is that person that will just kind of filet you in front of everybody because you, you did the wrong thing in the code.
And, You know, what you want is to be on a team with a mentor that you, you go to code review with. It says, you know, say, you know, maybe that way is that right? The best way let’s talk through it. That’s what I always tried to do with people that I had to do code reviews with. Sometimes, sometimes they come back to me and go, Hey, this is what I was thinking.
And this is why I did it that way instead of the other way. Okay. But, you know, if you have someone that publicly shamed someone, or even not even publicly shames, like why are you such an idiot? You wrote this code so poorly, that’s going to make them not want, that’s going to make them think really hard.
and, and not even, you don’t have to say it. Just the look on your face. Just the look on your face when you look at the code and you’re like, you give them a look like, okay, you may not, you know, that, that, you know, that that communicates volumes of speech. I don’t know if you heard the sound or not that I made that, you know, that kind of like, like little bit of, you know, starchiness in your, you know, the first response to it.
and then you’re like, well, why don’t you just do this, this, this, and this. And, you know, people that do that, you don’t want to deal with those people. And so you may want to always have the code written in a way, and you spend so much time overthinking the problem because the person who’s reviewing your code may just be a real jerk.
Tyler S. Lemke: [01:03:00] Right? So I think this might be a good place to end off. We have this, rules of thumb for Onex developer. And I think we both found this article, separately. I haven’t gone. I’ve actually only skimmed over part of it, but I thought it was a really interesting, article. What do you remember from this article?
Douglas Hirsh: [01:03:23] Well, Give me a sec. I wanna, I want to bring it back up so I can see it. What I thought about this article is maybe this person is, is being very humble because some of these rules, they have experience in them. And this person may be, may say, rules of thumb for a Onex developer. But when they say, when someone, when some people say 10 X developer, they think of someone who just eats sleeps and drinks code, right.
They don’t, they go, they go home and they work on more code and they get up in the morning and they work on code before they go to work and work on code that code in their code. So they can code while they code. Yup. You know, that’s, that’s one thing where this person is saying that I don’t do any of that.
And I may not be as quick to go pick up a new framework, but the rules that I read in here that this person goes by, there’s there is there’s wisdom in these rules, which means that there’s experience. And this person may be the 10 X developer, like, like we’ve talked about that, that knows when to write code when not to write code.
And you may not be able to measure their productivity in a really good way. And they may even be, they may be putting themselves down. Right. And that’s, but what I see in here is good wisdom in this article. And I see someone who has some experience with writing code and probably is better than me at hanging up the computer at night and going and doing something else.
Tyler S. Lemke: [01:05:01] Yeah, for sure. so we didn’t really define what he meant by one X developer either. So from what, from what I gathered, the one X developer is basically, I think he says in here that he wanted to be, maybe try to become a 1.1 X developer, right? He says, if I’m feeling ambitious, I would like to be, come a 1.1 X developer.
And basically he, he, he likes going home and just doing this, he’s doing his own thing. Right. he said he raised, he raised three kids. I’m assuming, I’m assuming this is a guy, might be wrong. but he raised three kids and, yeah, it says, it is a guy. So the, Taking care of his family. He first contributed to open source project like a year ago.
And it sounds like he’s been developing for some time. So, and I’m not that I’m not that you know, that 10 X, if you want to say 10 X developer person who eats breathes and sleeps code, but you have been in the past, right? Douglas you’ve you’ve done that in the past.
Douglas Hirsh: [01:05:59] Yeah, totally put it down. Right. I. I always felt like I was behind the eight ball.
And so I would go home at night. I would read about stuff. I would, I was the person that would do that. And maybe I did it in my more formative years. Maybe I spent that time and took those. It took the hits early, of doing that. But what I really sitter I was doing was I was getting my CS degree, agree.
I was getting the information I needed that I was missing because I didn’t go get a CS degree. And, and that kind of put me in a place that was really interesting because people that had their degrees didn’t think like I did, I would read stuff about how you should code and patterns and, and scalability and all this stuff.
And no one else was talking about that stuff around me, but they had degrees. And it was so funny. I worked with someone who had the, you know, got their master’s degree. And I was sitting there with them. We were talking about the school, you know, they were all talking about schools. They graduated from and I said, I didn’t go to college.
He goes his fault. That’s so weird. You talk like, you basically talk like I do, you know, and he has his master’s degree. Right. And so the thing is, it was a master’s degree in computer science. And so. Maybe that time I spent, there was a lot of imposter syndrome. I dealt with that a lot and I think that people early, there’s no way I could, I could stop someone from dealing with imposter syndrome.
I can try to reassure them and let them know that as time goes on, you’re going to learn more. It, you don’t know everything when you first get started. I can try to do that, but I cannot mitigate it completely. I dealt with imposter syndrome for an instilled, maybe even somewhat to some extent still do.
Cause I’m teaching. Like, look at, look at me with no degree and, and I’m teaching people how to write software, but I have all this experience that I can give out in class when I’m talking about. That’s where I have to be careful though. I can’t give them too much of my experience because a lot of it wouldn’t make sense to them, but I have to go back to when my, my, my, my junior years and bring stuff out and go, yeah, we totally, or something where I show them something like I’ve had to deal with this.
Five or six jobs. And this is something you need to think about, you know, when we’re teaching it. But I try to keep from going into like the really deep stuff that I have in my head. When I look at things like for instance, I’m in spring right now, what we’re doing is, is, you did model binding to a, to a controller.
And so. I mean for anyone who’s done like.net or something similar like MVC framework, she could put an object in your controller method and, and the framework will bind properties that are coming up either through Jason or through a form to that object is what I mean. Well, if you, you know, Right now, we’re just trying to get them to be able to do that successfully.
We’re not teaching them about like going through services and going through a and all this stuff. And I was, I said something to my co-instructor I’m like, you do realize that this is an overposting vulnerability and he’s like, well, I might, I’m just saying to you, I’m not like this wasn’t during a lecture.
I’m like, I, I want to give them all of that, but it wouldn’t make sense to throw everything at them at once. Right. We got to get them to the point where they can post a form and then we get to the point where they do it better and then they do it better. And then they do it better.
Tyler S. Lemke: [01:09:37] I think if I definitely suffer it, that when I teach, I tend to give too much information because my brain just starts making all of these connections.
And I think that’s where I’m, I definitely need to, do better and, come off of it. But I think there is, there are certain details that you can give. That are valuable, but you have to know which exact ones to pick. Right? Like, sometimes like I teach like arguments versus parameters and what those are like, that’s a small one.
That’s like, I try to really emphasize. Cause I’m like, look, you know, communication’s important, right. When you’re talking to other developers and it’s little things like that, that could help you. To get hired when you’re, when you’re talking to other developers, right? Like if you use the right terminology and you’re coming out of the bootcamp, like that could definitely help you.
Douglas Hirsh: [01:10:23] And we try to model the right terminology. That’s actually the way that we, we model the right terminology. And so they hear it all the time. They hear how we talk about the different things. Cause I’m, so this was the, this was a funny thing we were talking about this today. We are alive coding every day in front of our students.
I mean that’s we’re lecturing. So not only are we teaching, but in our lectures, we live code during our lectures. And you see all the people talking about in, in, you know, at the conferences about, Ooh, don’t like try to put your code on slides because something may. Mess up don’t live code. And I’m like, I live code every day for a living in front of people on zoom all the time,
Tyler S. Lemke: [01:11:05] things go wrong,
Douglas Hirsh: [01:11:07] fix things will go wrong, but there are mitigation tactics that you can, that you can put in place to keep them from going wrong.
And I’ve learned those mitigation. I’ve learned a good number of them, but even with that, things still do go wrong. And I had it happen today. Like it just, it just happened. I’m not scared of it so much, but no, I think the reason that we were talking about. About this as the number of facts that we give out at one time, we want to try.
We want to try to give out facts that are pertinent to what they’re trying to learn. Not anything that could distract from the actual lesson content that we’re trying to give them, because we can give them more content later. But if there’s something really specific that we’re trying to get them to get to like a new place, we’re trying to get them to, to make new connections.
We want to try to avoid as many extras. As, as possible that will take them off the path that we’re trying to get them down. Because when you say something, they don’t understand, they stop listening and they start trying to think about what you said. And so that’s a challenge. Yeah. It’s a, it’s a challenge.
And so, no, I mean, Yeah. Knowing what to say when to say it is, is something that we y’all learn it. Like I said, the imposter syndrome was something I was trying to roll this back imposter syndrome, even in that sense, because I’m teaching and I didn’t finish college. Right. There’s actually a lot more to that story.
And one day we might actually do an origins episode. I have not decided if I want to do that on this podcast or not, but there’s, there’s a lot more to that and would make a lot more sense to people. Why, why I do suffer or did suffer a lot from imposter syndrome? it’s still do to a certain extent. but I think with that, I’m, I’m pretty close to we’ve we’ve been recording quite a while.
Tyler S. Lemke: [01:13:02] we have, I think, so I wanted to make some final comments, so let’s do it. Yeah. Let’s make some closing arguments or closing statements here. Act like lawyers for a second or whatever. I’m not a lawyer, but I play one on my podcast. Right. So, the
10 X developers, I think. For the concept let’s back down from TEDx developer and let’s just talk about good developers, right? Everyone has an idea of what a good developer is, right. A productive developer versus okay. Developer versus a nonproductive developer. And so let’s it. The terminology of productivity developers, different developers.
You might have a developer at one company that is looked at as being a very productive developer and at another company they might be looked at as unproductive, right? And this I’ve kind of learned through experience and through like my own experiences that, Oh, like you don’t have to, you don’t have to conform to this one particular idea of what a developer is.
You can use your own strengths and depending on what company, and I iterate this idea a lot, but depending on what company you go to, they’re going to value your strengths or not. So I think the 10 X developer is different. For different companies or productive developer. Right. And that has a different idea idea of what that is for each company.
so if you want to become this more productive, let’s say it’s the 1.1 X developer, right? You’re a better than average. If you want to become that developer, you have to understand what your strengths are, double down on them and then find companies that will, that, appreciate your strengths.
Douglas Hirsh: [01:14:42] Yeah. I mean, to be fair, the article that we’ve been talking about, the guy has a, the guy works for Amazon, or at least that’s what it says in the article. So if you work for Amazon and you consider yourself a Onex developer, then maybe this standard of one X, if you were to go, like you just said, this, this falls on what you just said.
If you were to go to another company, you might actually be a 15 X developer. You got into Amazon.
Tyler S. Lemke: [01:15:10] It’s funny. Cause they actually said, one of the books I read, I think it’s radical candor or something like that. They said they, I forgot which book it was, but they basically said they actually have to let people go at Google and say, look, you’re not a good fit here for whatever reason, you’re either not, you know, for lack of better terminology, not smart enough, it would be, I don’t want to say smart enough, but you don’t produce enough of the type of code that they need or whatever that means.
Right. So they know that if you go to a different company that you’ll actually be more successful there. And this is an interesting concept mountain. I think Malcolm Gladwell talks about, of, of. students that try to get into better universities sometimes do worse because it’s more competitive there.
So if you go to Harvard, for example, you actually, versus, you know, a local school that’s not as difficult. you might actually perform worse because your peer, you will feel worse in that environment because you’re not the smarter person in the room. Right. Or you don’t feel as smart, right. Cause you might be at the bottom of the class.
So it might be better to go to a place that is. where you might be average versus being the worst. I don’t know how to say that in a, in a different way, but hopefully people took it in the right way, but
Douglas Hirsh: [01:16:20] I think it’s a good concept. Yeah. It’s the same thing of like being the, the, the big fish in a little pond.
Right. It kind of comes down to that. To that analogy. If, if, if you are the biggest fish, then, then you might be a tiny fish in the ocean and be eaten up instantly. But man of that little, that little pond you’re in you are you’re, you are at the top of the food chain. So, you know, I kind of feel like it goes there.
So here’s my final summation for right now, because my mind could change over time. My final summation is does the 10 X developer exists? Yes or no? I think yes and no. And it depends. It depends on the company that they’re in. Like we just said, Tyler, I’m just feeding off of what you said. They could be 10 X better than another developer next to them.
But if they were to go to let’s say Google, they might be at the bottom. They might be all the way in the left hand side of the distribution. Right. They might be the worst. So, you know, maybe, maybe, really, if you want to be a. Maybe 10 X developer is not exactly where you want to be, but you always want to be the one striving to be better.
Right? That, that may be what you want to do is strive to be better. Always go to where you’re not all the way at the left of the distribution, but maybe go to where, where you have room for improvement. You might be a little bit to the, to the left of the average. You know, a little bit lesser than, than the average, and you can push up to it and then go to companies that are more and more challenging over time.
And then eventually, maybe anywhere you go, that’s not like a top company you might be in 10 X engineer. Great.
Tyler S. Lemke: [01:18:14] Great. So emotion, we’ll see you next week, guys.
Douglas Hirsh: [01:18:20] Have a good one. Y’all.

Episode 8 – Letters to A New Developer – Interview with Dan Moore

If you would like to support Dan consider getting his book with 20% off (expires in Aug 2020) use coupon GiveMeMoore08 – https://www.apress.com/us/book/9781484260739

What we talked about:

  • Letters to a new developer. https://letterstoanewdeveloper.com/
  • Editors and IDEs
  • Mistakes
  • Perfect the Enemy of the Good 
  • Starters vs Finishers
  • Top 4 Things to tell new Devs
  • Imposter Syndrome / Overconfidence
  • Don’t bag on other people’s code
  • Should You Start Your Own Consulting Company
  • Best Code is No Code


Douglas:  [00:00:00] welcome to another episode of the junior to senior developer podcast. I’m Douglas Hirsch.

Tyler: And I’m Tyler Lemke today. We’re here with Dan Moore. Dan Moore has been programming, for about 20 years now. He’s worked at large companies like Oracle and level three, as well as small companies, startups and academia.

He’s run his own consulting company. He’s an author blogger presenter. It sounds like you’ve done it all, Dan. thanks for coming on today. Do we leave anything out there?

Dan: No, but thanks. Thanks so much for having me.

Tyler: Yeah, so we, it’s really cool. Cause we actually connected through LinkedIn and we found that we share the same passion.

You have this really cool website called letters to a new developer.com. Can you tell us a little bit about the background of that

Douglas: website?

Dan: Yeah. So about, I actually wrote a technical ebook that I’ve self published in 2012, 2013. And it was a [00:01:00] 45 pages and a lot of effort. Yeah. And I decided that, as soon as we actually, as soon as we started, as soon as I finished the book, it was super esoteric.

the company I was at stopped using the technology. And so I decided that I wasn’t going to ever write a book again about a technology because I’ve been a Jack of all trades. Throughout my life and my programming career. And I just couldn’t see coming to another technology enough to make it worth that investment.

and about two or three years ago, I started to think about maybe trying to write note or book and kind of spitball some ideas. And I thought of, I want to think of something that was more evergreen and that could actually help more people broader rather than deeper. And I, had been a senior developer and a team lead and engineering manager, and I decided to write something and I’d also talked to a bunch of.

Bootcamp grads, new developers and realize there’s a lot of stuff that after a couple of years you get [00:02:00] internalized. And I decided to try to write that down in a blog form to see whether I could help people. And then, the back of my mind where there was always the idea of Oh, I could turn it into a book.

I’m of the mindset that. You can’t write 10 blog posts about something. You definitely shouldn’t write a book about it. The Congress is necessarily true, but, yeah, so I started writing it and what’s been really fun is now that I have a little bit of following, I’ve had a couple of posts trend on some social sites and I have decent traffic.

I’m actually able to use as a platform for other people. and they’ll write guest blog posts. And I think some of them really enjoyed that experience. So yeah.

Tyler: Awesome. You got it. You got the next question, Douglas.

Douglas: So I’m going to say that kind of read my mind a bit. Cause I was looking at that and I said,  this could actually have been a book from the beginning. when I went back and looked at the first couple of posts, and are really enjoyed reading the articles on your blog because they’re.

They’re [00:03:00] concise, short and have good advice in them. the first couple of posts or are, learn versus control. Well, I mean, that’s really important. We happen to teach our, and I don’t know if you know the stamp, but I do work for a coding boot camp called Coda. I’m a web development instructor and we teach version control, like from almost day one.

So it just gets crazier and crazier. Let me start learning about this thing called get all through the five months and, that they’re there and, it just gets yeah, get pretty crazy. So then on top of that, that it was learn a text editor. Guess what?  we say here’s a text editor and then we show them an IDE and we take them up through that list of stuff.

And so  I thought the, the posts were really, really good to someone who may not have had that exposure. Especially, maybe even the person trying to push into development, not necessarily even a new developer. I saw some stuff in there that would make sense even to the new developer. do you think that was part of your target?

Two was to [00:04:00] like hit the aspiring. Developer,

Dan: I wouldn’t say the blog  and I don’t want to talk too much about the book. Right? Cause this is not like a book advertisement, but when I wrote the introduction to the book, I actually thought about who I wanted the book to be for. And that it was, it’s a bunch of revised posts.

So it’s not just the content, but I really thought of new developers first and foremost, and then aspiring developers or people considering that because. the content of the blog is such that it’s some of it’s technical, right? Like my wife, who’s not a developer. We have no idea what version control is.

But I try to explain things in concepts that people who are reasonably capable with computers would understand. And then third one was actually mentors because I thought that the book would be a nice. Discussion point, or like study, not necessarily study guide, cause it’s not that structured, but  basically  a third voice to bring into mentor mentee discussions.

But, certainly when I was starting the blog, I did not think about, helping out aspiring developers at all. It was really here’s [00:05:00] some dumb things I’ve done, please don’t do these dumb things.  and I have my own dumb stories about guests. Or text editors or other mistakes I’ve made that are more kind of people oriented.

And I was trying to document those so that people could look at that and just understand. there’s a world of difference as I’m sure both, you know, between learning something by. Touching the stove or learning something by reading the manual and the manual says don’t touch the stove.

Right? And the book is definitely, or the blogging. The book are both definitely that second category, but still it’s helpful to know that there is such a thing as a still.

Douglas: That’s right. That’s right. No, we talk about on this podcast, we talk about the difference between, declarative and procedural knowledge all the time.

The declarative is I know what stoves are, or I’ve read that there are such thing as stoves and they, they produce heat and the procedural would be, I tried touching the burner in it hurts. So I will never do that again. [00:06:00] Yeah.

Dan: I’m actually, I mean, I listened to like, I think an episode or two and I’m, I was.

I’m really looking forward to it. I’m really important. Yeah. Just because I think you all have like a much better theoretical model of learning than I do. I have never studied it. I’ve never really done anything other than self-education. And I can tell both of you actually have some, no theoretical underpinnings of how people actually learn, which is fantastic.

So I’m looking forward to discussing that

Douglas: too. Yeah, for sure.

Tyler: We can definitely definitely touch on that. I think so. I think it’s interesting. what, and we didn’t talk about this before, but, what. Who do you think will benefit most from your letters to a new developer website? And this is, just to clarify, this site’s completely free, right?

So, who would benefit most from that? Or are you seeing that, that, brand new developers like are aspiring developers? Is it junior developers? Mid-level developers. Who’s who is it? Mostly targeted towards?

Dan: Yeah. So, you know, when you [00:07:00] put something out there on the internet, it’s really hard to know who is actually reading it.

Right. People reach out to me. And so, you know, I have some anecdotal evidence and the people who kind of talked to me about it on slacks or at meetups have been newer developers. I have had, there’s a, you can sign up for free the newsletter, which just basically sends you the blog every week. And I have a little field there, which says how many years you’ve been it on that.

And I’ve had people sign up with as many as 20, you get three years of experience, but the vast majority is five or less. The people who choose to tell me. Right. so yeah, so I think it’s really a target is I’ve graduated from a code camp or a CS degree and, or I’m in the middle of it. And I realized that there’s a lot more to software development than programming.

Programming is hugely important. Don’t get me wrong. You know, you can’t, you can’t be a developer without being able to program, but there’s so much more [00:08:00] comes into delivering software.

Tyler: So it sounds like it’ll be really beneficial for, anyone else that’s looking for more, more content and likes our podcast.

So that’s, that’s cool. so you, you have several different, I don’t know how many, Douglas wants to cover, but you had several different, cool articles that I, I liked, And Douglas, you touched on, you touched on a few. I remember you talked about one here. the, that your very first post was learning a version control.

did you want to go into, did you have a followup question on that Douglas?

Douglas: No, I just, it was more of kind of giving an idea of, of the kind of knowledge and the brevity, but the value that the, the articles, the articles provide there wasn’t, you know, I think, I think as, as seasoned developers that have that well, As we, we actually have different experience levels here, but as someone who has done this for a long time, I actually absolutely do subscribe.

[00:09:00] Now, my only question to you, Dan, is that VI or Emacs,

Dan: you know, I, I’m a

Douglas: via text editor itself.

Dan: I’m a VA person myself, but I have, I have friends who use Emacs. So I’m ecumenical. It comes to that.

Douglas: That’s okay. We’re we, we, we are inclusive of text editors.

Tyler: I thought we were gonna kind of cut off politics Douglas, come on.

Douglas: So, so that’s actually really funny, Dan. I am a, I spent a couple of months of my life in them just to like, get my, just to really get. Into it and understand it. So now it’s like, like I just jump in there and it’s like riding a bike. I don’t every, I don’t know everything and well, actually anyone who claims they know everything about them, they’re lying.

They’re lying. Do you have a 20, you know, unless you’re, unless you’re a, what is it? The, you’re what is it? The VMRC we are, you know, unless that things like, like 20 years old and you’ve got probably still even have stuff in there, [00:10:00] remember that you put in there, you know, that’s, that’s a, that’s a thing, but no, you absolutely should choose an editor now.

That’s. Now, whether that’s like, like in, in today’s world that like vs code as your text editor or sublime text or, or whatever. And even that causes fights, like I have my co-instructor he’s like if, if I had opened that in sublime text, it already would have been opened by now and vs. Code takes. Two seconds to open it.

He’s right. He’s right. I mean, vs code is an electronic based app and, and sublime text is a C is I think a C plus plus app and it’s native and it just like it. They barely even, you know, they even bleak. Go ahead.

Tyler: Do a bunch of optimizations though. That’s why, if you guys remember Adam and brackets, the reason why the S code is so much faster is because they’ve done a bunch of optimizations.

on top of, electron to make it much, much faster, like they were at a bunch of stuff and like C and C plus plus, but, yeah. yeah, I liked vs code more. I, I haven’t done jumped [00:11:00] into the Emacs or, you know, I can’t, I, you know, The little experience I have when I can’t even exit a commit message. I just, you know, I just, I just, it was like, I don’t want any part of this.

So I guess I just put my tail between my legs and ran away from those editors.

Douglas: Oh, man. The only reason why. And actually I would add to that advice, which is like, learn, learn at least how to get out of VI because, or how to save and how to get out of VI. Because if you have to jump into Linux boxes for any reason, it’s or actually most Unix. Are positive space boxes vis everywhere.

You can always get a VI editor up and running, but nano may not be there if you need a regular type editor, man, I’ll tell you, we’re getting into some stuff here. He

Tyler: didn’t know. We’d go this deep on down.

Douglas: Flaming going on. What do you, what do you meet him? EMAC. What is he backs?

Tyler: I use an iMac. What are you talking about?

Dan: I mean, I, you know, I mean, [00:12:00] I will say, like I bought a, so I bought that blog post and I shared it around and there were some people flaming me. Right. Who said, you know, come on, you don’t really need to know a tech editor. Like you can do stuff from within your ID. Yeah, yada, I’m way more productive in my IDE.

And so I actually ended up bringing a companion post that was learning IDE because I think both of them are valuable. They’re just different tools, right? It’s like I have a hammer and I have a saw, what am I going to do? Well, there are things that the hammer is appropriate for and the things I saw is appropriate for.

And you should, as a, as a professional developer, you should have a working familiarity with both of them. I think. Your your point, Doug Douglas is mastery is a long way away. Right?

Douglas: Good. You should have a good set of tools. Right. And I mean, the text editor is great for. you know, not every developer in the world, every developer is going to be jumping into Linux boxes, but I’m going to tell you when I am in one and I can just type VI whatever the file is and start editing and no con you know, no, mostly what I’m doing in there. [00:13:00]

and I didn’t have to install anything to get that to work. I can just jump in a box and rely that it’s it’s there. So that’s a good text editor to know just for that. That’s the, that’s the scenario, that’s the tool. Where, where you might want to really be good with an IDE and, you know, for your day to day, like your entire job, like if you’re doing Java, you know, the, intelligence is a really, really good IDE for Java.

I mean, I’ve, I sit in intelligent now a lot. I actually teach from intelligence, but I used to use something in the.net world called ReSharper. Back in the day, like long time ago, used it for the longest time. Like as long as I was a professional, dot net developer actually still kind of am, but, I have the re I have the JetBrains toolbox, which means that I have all those tools if I need ReSharper I can bring it down, but I’m on a Mac now.

So I’ve been using their C-sharp IDE, I think about that. They’ve made a C sharp IDE for Mac.

[00:14:00] Dan: I mean, thinking about the supported, like the Le the Linux subsystem and windows 10, right? I mean, yeah. It’s a crazy stuff. It’s a crazy different world, right? Like, so. Anyway, so

Douglas: no, no, no, no, no, no. It’s it’s it’s cool.

I kind of like Tyler, I, you could ask him, I like reminiscing about old stuff like that sometimes, but also another post that I saw from you that I really thought was a very encouraging post is you’re going to put some plates in toasters. That one stood out at me as I was scanning through. you know, it’s this back it’s for back in may.

I only went back into it to like January the end of January, beginning of February. So this was one of them where I thought the story was hilarious, but it is definitely, It definitely kind of goes down our path of, you know, you got to do things and fail and you’re going to fail. Right. Just be okay with that.

So, you know, we, we tell our students [00:15:00] and I refer back to that a lot because as a student of software development, And as a new developer, you’re going to fail. And I remember failing a lot and how bad it felt. I just tried to make, tell them, look, you’re going to fail. It’s good to feel bad about it.

Cause that means you want to fix it, but try to work more on fixing it than the feeling bad part. That’s, that’s kind of the way that I’ve put it. What do you, how do you approach that?

Dan: Yeah, so I, I think of it in terms of mistakes and there’s actually, I had no posts where I have an entire. A chapter about mistakes.

And, you know, I mean, to me, the important thing with mistake is one acknowledge or first realize you’re going to do it right, because everyone does. And, you know, an example of a mistake that I made. Not in the too distant past was I thought the first time I was using getting a team setting, I thought that the way to check out our branch was to get checkout dash B, which is for anybody who is not a good person, that actually doesn’t.

That doesn’t [00:16:00] check out our branch that actually creates a new branch. And so I was checked, creating new branches that already had remotes that have the same name and that would pull down the remote. And then I would basically be doing this, like mish-mash merge of these branches in a way that was totally unintentional.

And luckily we didn’t push code to production that was there, but. I made the mistake. I admitted it. I worked with a team member to fix the mistakes that I’d made, that come out of that. And then I made sure that I, I learned enough get to be better and to make sure that never happened again. Right. So those are the three stages of mistakes from my mind.

It’s like, no, there’s, you’re gonna do a mistake. When you do acknowledge it and then three take steps to prevent it from happening. And that could be learning something new. It could be an automated system that you’re going to implement. It could just be just writing a blog post about it so that it’s seared in your memory.

it doesn’t, lots of people I know have notebooks, right. That they write stuff down and that doesn’t work for me, but I know it does for other [00:17:00] people. So, mistakes and failures happen all the time. And. Even people with 20 and 30 and 40 years experience still do that. So, but the scope changes for sure.

Right. I wouldn’t expect somebody with 10 years or 20 years of experience to make the same kind of mistakes as a, new developer, but the experience of failure persists. For sure.

Tyler: So I have a follow up question to that, cause I think it’s, Cause I think you wrote, like never make the same mistake twice.

I wanted to get your, and I didn’t read through going through a lot of them pretty quickly, but what’s your feeling on like, if you were to make that same mistake again? when do you think it’s acceptable and make the same mistake? The, to make the same mistake, given that where there’s so much complexity involved with software development.

Dan: I mean, that’s a really interesting question, I guess I would say that. The goal is never to make the same mistake. Right. now I guess you could [00:18:00] start to like, hedge and think about what the word same means in this context. Right.

Douglas: I was thinking that

Dan: to your point. I mean, Tyler, like, yeah, there’s so much complexity.

you know, if I did that same thing about branches with mercurial or something like that, and that might be a permissible stake. I mean, I guess the goal is. I think that the goal behind don’t make the same mistake twice is that you want to give permission people to make mistakes, but you want to have some kind of mechanism to encourage them to them, to learn from them.

Right. So that doesn’t mean that anyone’s perfect. Right. And if you make the same mistake, five years after a year after. you made the original mistake, you know, we’re all human, but I really wanted to kind of try to put 500 people’s butts to like, make them realize that we should, we have the tools aren’t automation around learning.

To, to not make mistakes repeatedly, but it’s totally okay to make new mistakes. Right. [00:19:00] And that’s, that’s actually, one of the goals of the blog is just, I want everyone to make new mistakes because you should be able to learn from other people’s mistakes. Does that? I don’t know. I may even be like wishy-washy here.

I don’t know. That was a really,

Tyler: I think it’s fair. Yeah. I think, I think it’s fair. Just think, I find it’s easy. I think I th I find it’s easy to make the same stakes when you don’t use the same technologies all the time. So let’s say you went away from get for a while. A long time. I find it’d be, it’d be easy to forget and have that fall out of your head and go.

I forgot that, you know, How branching works because I haven’t used it for six months. Right. And so I think it’s, I think it’s just interesting balancing those two, but I do think it’s very liberating. How, how is it, you know, you know, you know, don’t be so hard on yourself, right? Cause I think, there are some, some people out there who are hard on themselves, there’s other people who don’t, you know, don’t take responsibility and are hard enough on themselves.

You have the opposite side.

Dan: I think they would say honestly, [00:20:00] especially when you’re a junior to junior to mid dev. Like you want to be proving yourself, right? You want to be excellent as excellent as you possibly be in a good way to do that is to take note a mistake and then like set up a system or a learning thing to make sure that you never do it again.

And to your, to your point, like maybe the answer is you just decide, Hey, if I go away from technology for a little while when I come back to it, I’m going to revisit my notes or I’m going to take a 30, you know, Find a tutorial or something like that. And that’s enough of a system that you are going to prevent yourself from doing that.

But I mean, I can tell you, like, I’ve been an engineering manager twice, and that is like an entirely different profession than, being an individual contributor. And I made multiple steaks. repeatedly with, with, with engineering management, because it’s not grounded into me the same way that I see mistakes.

I like to think I don’t make the same mistake around just playing a Colby coding anymore, but I, I wouldn’t. I, if you, if you, if you may [00:21:00] be, if you hope, if you, what’s the word I’m looking for? If you maybe about my life on it, I probably wouldn’t that I’ve never made mistakes. The same mistakes again.

Sometimes you just forget mistakes, which is nice. So

Douglas: that’s, we’ll say that, that the, the idea that you could make the same mistake in management. More than once actually makes a lot of sense, because you may not even know, realize because computers are, are really cool because you could write the code and if you write it wrong and you learn how to write it correctly and can remember how to write it correctly, it will continue to do the thing correctly.

But with humans, you can remember how to say the thing again, but to the next human that you say, that thing you might be making the same mistake you did before. Even saying the thing, the way you thought, you know, giving the advice the way you thought you should, because everyone’s experience of reality is a little bit different.

So the language that everyone uses his entire can be, can be [00:22:00] just nuance slightly different enough to. You know, just, just that nuance can be just off a little bit where you could have hit, hit the same brick wall and not realized you, you had done it. And, yeah, management’s been something that, that I try to, I pulled, I pulled a little while as a CTO and, and.

I’m kind of happy to go to B to be doing the instructor thing and not having all, having the butt kind of stop with me. And that in that realm,

Dan: I definitely it’s different, different set of responsibilities, for sure. For sure.

Tyler: So I think it’s, I think it’s interesting that you bring that up. Cause it reminds me of like, I feel like not enough technical books go over the.

The gotchas to different, like the gotchas different thing. And I think part of that is because people who write technical books maybe have so much experience in that technology that they forget how hard it can be. when either when you’re brand new or if [00:23:00] you’ve been in technology for a long time, and it’s just a brand new framework.

But, I like to think of, you know, the mistakes as maybe like, if you remember playing RTS is back in the day, like red alert. I used to love red alert, The game shroud where you, I don’t know, what’s on the map. Do you think of it that way? Like, If you make a mistake, you’re kind of defining the boundaries of what is it exists within JavaScript or within, you know, Ru I know you’re a Ruby dev and you’ve done a lot of different, you’ve blogged about a lot of different technologies and you

Douglas: kind of

Tyler: circle get the map until you kind of discover, Oh, I’ve made all these mistakes now.

And your mistakes are kind of representative of you going to the different areas of the map and going well. I ended up over here. This is the totally wrong place. Like there’s no one over here. There’s no resources. I can’t do anything over here. I think that’s kind of how learning works is you kind of just eventually discover what we’ve both, what Douglas and I have talked about is this mental model of, of the different technologies that we learn.

But one is [00:24:00] a transition to something else I think is kind of similar to mistakes is you have another blog post, and it’s really cool about these blog posts, who is their, their, Douglas doc touched on as these are like really consumable. These are not fluff pieces that like go on and on for 2000.

Words, right. They’re like, yeah. Good for Google. I like how they’re condensed and very consumable. And you talked about, the perfect being, the enemy of the good and some of the questions that you, that you talked about in here was how often will be, how often will this, this be used, like, like how often will this, feature be used?

Like, is it going to be used once a second, once a year? Once, what are the risk factors if it fails? what is the team quality ethic? I want you to touch a little bit more on perfect being the enemy of the good and how many times it’s burned you personally.

Dan: Sure. yeah, I mean, so I think, that, [00:25:00] that, you know, you know, I do a world.

Where we were all artists that had the time and money I saved. Yeah. You can write some really beautiful software. The unfortunate truth is, or the fortunate truth in some ways is that. Software exists for a purpose, which is to accomplish some goal. usually it’s a business goal. At least that’s been best majority of my experience.

And although it can be a side project where it’s just a goal to learn and have fun, which is a totally different experience and has a different set of constraints. So once you get there, you’re, you know, once you accept that your software is lives within a constrained world research in the chain world, you need to make trade offs.

And the most important thing about tradeoffs in my mind is not to make them unconsciously. And so I don’t think that at every meeting or every sprint planning session, you should like break down like, Hey, this is exactly what we’re going to try to do. Right. Like, this is only gonna be used one time, so [00:26:00] let’s go ahead and we can write it like in bash.

Right. And just like, and I’m put in birth control. Right. but I think that. When you are confronted with the problem, especially to me, it’s taking you a while or that you predict will take you awhile. I think you want to have an honest conversation with your team and with yourself over what’s good enough to, to ship and what’s good enough to support.

And then also, you know, so what you don’t want to, You know what won’t cause more problems than the lie. I’m an example of this and I, I think frankly, you can be surprised, right? Because what you, we tend to be, we tend to yeah. Have high standards, especially. I think the people that are listening to your podcast are probably people would want to improve themselves.

People that are really interested in software. And I remember a startup, I worked at, a co-founded actually I was. Putting together like a MB MEP and my co founder. [00:27:00] And I were both just so embarrassed and I was embarrassed because I built the software and I, I knew what really great software could look like.

Yeah. She was embarrassed because she had a vision in her head and we showed it some users who it was actually solving their problem for. And they’re like, Oh my God. This is so much better than anything that anybody’s shown us. And so I think shipping something that will work and we’ll write things right.

But like the, and I think I might’ve put this in the blog post, like the most perfect, awesome extensible, beautiful unit tested piece of code or tested piece of code that doesn’t get shipped. Doesn’t do anybody any good? And so, I think that you need to, and this actually is. I noticed in some of your podcasts, you talked about like what makes a senior developer?

I think that having that awareness of those trade offs is a good barometer of how senior you are, because you’re aware of all the other kind of pressures that are around your coat. you know, so, [00:28:00] yeah, so that’s what I would say about, of perfectly good. Oh, there was a second part of your question, but I don’t recall it.

I’m sorry. I

Tyler: just wondering how many times it’s burned you, because I feel like it, it gets me a lot, or at least I tend to overthink, what I’m developing. and it makes I lean more on the side of perfection versus shipping personally.

Dan: Yeah. That’s actually a really interesting perspective because I tend to lead it.

I’m more pragmatic. Right. Which probably means I’ve shipped stuff that was. Less quality than it should have been. which is why I’ve gravitated more towards the startups in Canada, the smaller companies, because if you screw up, like it’s, you know, I I’ve screwed up in having to call users before, but I didn’t have to call a thousand users.

I had to call like 10, right. And apologize to them for the mistake that I’d made. So I think there’s spectrum. And I think, you know, you want. People have their own predilections and then the code itself and the requirements around that code have their own, influences as well.

Tyler: That’s actually really

Douglas: cool that you’ve [00:29:00] mentioned that, that like you have this strength that you can put out code that does that.

And I don’t want to say mostly works, but, but you can put, you have like this, this barometer that you can use, to put code out and. You know, you said you’re more pragmatic. So sometimes it gets you get, it may not be as high quality as it should be. And that kind of gave you that, that push towards startups.

That’s actually a really good awareness that you’ve got over the kind of co or not even the kind of code, but just how you want to write code your streets is what is what I’m getting at. I just read a book or I’m reading. the, the tools of the Titans by Tim Ferriss and in there, he talks about success is finding your it’s, it’s finding your, your, what you would think is your weaknesses, but actually, building them up as, you know, actually focusing and exercising around those and making them your strengths.

And so what you just said was kind of an illustration of this point that just got hit into my [00:30:00] head while I was, driving in the car with dinner home, you know, on the way home. And, I thought that that’s actually really cool that you said that because you know, some people would say, and I have a hard time with that.

I have a hard time writing code that isn’t tested that isn’t, you know, it really kind of bothers me. It makes me lose sleep at night when I do that. And so I want to go to places where they’re like, we need the code, right? The first time I’ve written a payment system before that code could not, if someone.

Did a transaction for $10 could not pull a million dollars out of their account. And I had to prove that it wouldn’t do it. Okay. I really loved writing that system where it makes me really nervous to write stuff that I don’t have like a full test suite around. And I can’t, I can’t control it, but I have worked in startups too.

But I think you’re right. I think you should absolutely go where your streak is. This is more of an observation of what you just said. I really loved it that you, that you actually said that out loud and, and, [00:31:00] and, really liked that.

Dan: Yeah. So I got a couple of, couple of things to say there, like one is I’ve written a payment system to, and I wrote a lot of tests around it because I think there are things that you just.

That’s a case where the situation, the code made sense to make it more robust. Right. but even then I still had mistakes. Yeah. Still wrote tests for the new mistakes. The second year is that, I had a mentor once who said that there are people who are good at starting things, and there are people who good finishing them.

Right. And so people who start, you can give them a blank canvas and they’re ready to like dive in and explore things and figure it out. And there are other people who, when they see a blank canvas are kind of like, Oh my gosh, I’m not quite sure where to start. And they like Kevin Hyde. And then there are people who are really good finishers, right?

Who things all the way through who documents stuff who are really good at maintaining things. And again, I think you just need to pick your pick, your they’re both necessary. Right? They’re both great. Attributes to have you just need to find what [00:32:00] resonates with you. And then a third thing I would say is my current job is actually Devereaux and I migrated to this in part because it is a great job for me in terms of.

You know, I’m running a lot of code and code examples, but it’s not, it’s going to be an example for someone to take and productionize, right. Or to build on within their own system. It doesn’t necessarily need to be, you know, a full on, you know, fully tested, like robust production system because it’s example code and

Douglas: mission critical when it’s example.

But your example code can help your company immensely poet. Yeah, no, I love it. I really liked where this went.

Tyler: So I think, I think Douglas and I might have to write a book called the paranoid paranoid program or something like that. It’s like the opposite of refrack Radek although, although Douglas is very pragmatic, I think I tend to be a little bit more dog dogmatic on things, but, it’s actually, I think it’s actually good.

I kind of, [00:33:00] I’ve kind of learned from my current role that it’s good to have a mixture of different types of devs on teams. To help move things in and have a good balance there, I guess kind of like a, a, maybe a, you know, a good partnership or marriage might have a mix of different strengths and weaknesses.

So, so what are your. What are your, I wanted to go, what is your top three things that you like to tell new developers, either from your book or from the, maybe from the letters to a new developer? I’m sure a lot of there’s a lot of overlap

Dan: there. Sure. Yeah. Especially a little bit and make it four things.

I, and I’ve actually done a talk, based in part on this. I think that there’s, you know, obviously we’re talking about technical skill, right? And I’m not like, if you want to ask me about react or like Liz hot technical thing, I’m not the right person to talk to about that. so there’s that aspect of development, but I think that as a new developer, there’s, if you do [00:34:00] four things, you’re going to really Excel.

And I think that that is, Ask good questions. And that’s a balance between doing your own research, but also knowing when to stop because I I’ve done, I’m sure we’ve all on this call have done this where you reach your research yourself into a, into a spiral. Right. And you’re just like digging up, digging the hole further and further, and you’re like banging your head against the wall and then you talk to somebody and they’re like, Oh yeah, yeah, no, this is the reason why it’s like this.

And you’re like, Oh, if I only asked you an hour or two ago, but doing some research, but not too much. So asking good questions. Mistakes. We were talking about kind of taking responsibility for your mistakes and then, showing up and being consistent. Right. Just like trying to be a little better every day, because there is that like flywheel where you will ingrain things, right?

The first time you. have to write a filing VI VI is going to be a painful the second time. It was painful. The third time, a little bit less painful and so on and so forth. And I think [00:35:00] the fourth thing, which I think this is good for everybody, not just developers is to. Do what you’re say, what you’re going to do, like communicate what you’re going to do and then do it.

And I struggled with this myself because it’s very easy for me to overcome it. And, but I think especially as a new developer, a new person on the job, it’s better to commit. To less and really knock it out of the park than it is to, or, or even just really deliver it on time, the quality level, in fact, than it is for you to say yes to all kinds of stuff and then get overwhelmed and not be able to move forward on anything.

So those are kind of four pieces of advice I’d give.

Tyler: That’s cool. Cause it reminds me, I think in that if I’m not mistaken, the perfect, the enemy of good or another article you wrote, you said it’s better to deliver like 110% versus be like 90 to 95%. So it’s better deliver like 110% of that smaller portion versus 95% of a larger thing.

Is that kind of what you’re getting at? Yup.

Dan: Especially early days. [00:36:00] I think as you maintain, as you gain reputation in a job, you have more room for. Like overestimation, right. Or, or for saying, Hey, I’m sorry. I screwed up. Right. But like, I just. Again, not to harp on perfectionism. I just feel like it’s better for everybody, right?

It’s better for the team. If you commit, tap that thing that you thought was going to take you, you know, if you commit and deliver on this one small thing, then commit to five things and not don’t deliver them all. It’s better for you because you feel better about yourself and you learn more, right.

Because you’re not like you can focus on one thing. So, I’m a, I’m a huge fan of, of, you know, it’s that old. Under promise and over deliver is way better than the other way around. It’s just more fun for everyone. And as a manager, I’ll tell you that’s true too, too, right? It’s way. It’s way better for you to say it’s going to be, I’m going to have it done on Monday and give it to me on the Friday before then.

Vice versa. [00:37:00] It’s just, even if it’s a small thing, those things add up.

Tyler: I think that’s great advice. I think that’s excellent advice.

Douglas: I was gonna say the idea about the whole manager and timelines thing. I used to, I had this manager once that, that he would, if I said something was going to take me two months, he’d go, you could do it in three weeks.

But if I ever came to him and said, I can do it in two weeks, he was like, Oh crap. He basically, he was like, dude, you’re not giving it enough time. But if I ever said that, I needed a lot of time for something, he would go, you could do it. You could do anything at three weeks. But if I ever said. Oh, it’s easy.

I’ll do it in a week. He’s like, no, you won’t. I’m not going to, I’m not going to deliver that daddy body. He didn’t trust

Dan: stress summation at all, basically. Or do you not trust anybody’s estimation or what

Douglas: was that? I think it was, I think it was, What is the principle where you’ll take up a you’ll take up whatever time it’s given to a, to a task is, is kind of what, what he always got at.

[00:38:00] And sometimes I think he actually understood what my capabilities were better than I did. And, and also I have made the mistake. I would actually, if I had to do it in three weeks, I would, whether that took, that took nine weeks worth of hours to get it done in three weeks or not.

Dan: So

Douglas: he was right. I could get it done and I can get it done in three weeks.

I just might hate his guts for it after I was done. but, but if I ever said one or two weeks, he was like, he really zeroed in on that. He goes, well, okay. Let’s, let’s figure out why you said one or two weeks. Cause you’re my. You’re like, this is a six week long deal. And, and, so, so he would, he would get real finicky about it, but what he never told me when I worked for him was that he was always telling people when he said three weeks, he was always telling his, his people above him, like four or five weeks.

So he was, he was doing that. I just never do it. But it would be, I don’t know if it would be possible to have that kind of honest [00:39:00] conversation with your manager or not, but I just thought you’re, you’re, you’re under promise and over deliver. It was kind of one of those things where I think he was trying to engineer that in, in, in those time estimates, I wonder if you ever pulled any of those kinds of tricks with when you were, you were in management.

Dan: I would encourage people to, if they gave me a number. I would encourage people to buffer it. I wouldn’t, I wouldn’t do that without their knowledge upwards, but it was at a small company too. but I always, you know, when people would say a task would take 15 minutes, right. And a small task, right. I would always say, Hey, just round up to an hour.

Right. Because for a couple of reasons, right? There’s always things, some things kind of flex around and sometimes some you think is going to take eight hours. Actually she’ll take you 10. And the other thing is that there’s just. Around software development, even a small change to a small site, like documentation changed conceivably, right?

There’s version control. There’s getting it code reviewed. There’s all kinds of other [00:40:00] pieces that go in that you, when you’re a developer, you just think, Oh, I just need to change this function. You know, finding the function where it is and finding what else calls it and updating the tests. And I think that, it’s very hard to internalize that time.

We were all. At least most developers I’ve worked with are insufferable optimists just low. And it’s, it’s good because otherwise it’d be really tough, but like, especially when it comes to time, it’s just really hard. I find it hard.

Douglas: Well, I worked, I worked with this guy talking about, talking about like the, no in it.

No innocent code change. You know, this guy, he was a, you know, much older. He was a smoker, you know, he had this real grumpy voice and, you know, and they called me puppet this job. Would he go, you don’t pop, there’s no such thing as an innocent code change. And that’s just, that’s, that’s stayed with me when you said, you know, that’s, that’s just like, like that’s, that was my first corporate gig.

And, and I sat next to that guy. I was working [00:41:00] on a, Heck, I even remember the computer. It was like a, a Pentium Pentium, four

Dan: he’s fast screaming fast, right?

Douglas: Boom. Yeah, no, it was really crappy. It took forever to compile everything. If you need, if you need to change your head or file you just, you go, I knew why he smoked, you know, physically change the heterophile go smoke, come back and then keep working.

Oh man.

So I noticed something else. Oh, I just happened to have a question that popped into my head and I wrote it down. You know, we talked a lot, you talk a lot to do develop, and I got a feeling that you experienced questions along these lines all the time and people who watch or not watch listen to our podcast, might have the same question, but what do you say about imposter syndrome?

Have you, I didn’t see anything that kind of flew out at me about a conversation about that. Do you, have you suffered from [00:42:00] imposter syndrome? Have, Do you know, you, I’m sure you’ve met people that have, what advice do you give them?

Dan: Yeah. so my wife actually doesn’t talk about imposter syndrome, so I’m kind of a little bit aware of it.

And, you know, I think it’s, it’s, it’s definitely something that I. Have encountered in my own professional career. And I, and I know other senior developers who have as well, there are very few people I talked to that professionally that don’t have some form of this. I think it’s just a natural thing to, to, to feel.

And I think, you know, Just like anything else, the answer is to kind of, work through it. Right. And you do that a couple of ways. One is you can model behavior that you think it should be. You can discuss that with other people. I think that like peer groups are the slacks that I’m sure that all the bootcamp grads have access to are great places to talk about this.

Right. Cause. It’s [00:43:00] funny, you know, one person’s imposter syndrome is another person’s strength. It’s speaking back to what you were talking about, like strengths and weaknesses. You know, some people might have imposter syndrome around front end UX, and other people might have imposter syndrome around data modeling.

And so you can all be supportive. But I think, I mean, honestly, one of the joys and the terrors of being in software development is that there’s always more to learn. Right. And that’s really great in that you’ll never be bored, right? It’s one of the great careers for learning. I’m sure there’s other great careers for learning.

This happens to be the one that works for me, but it also means that you’re always a novice, right. And it can be not maybe, maybe not always. A novice, but you’re often a novice is partly because once you get canvas expertise in something like you kind of tend to admit, at least in my experience, I tend to move on or I tend to bundle it up and like document it and hand it off to somebody else.

so imposter syndrome. Yes, totally [00:44:00] prevalent. I haven’t never actually had somebody kind of come up and talk to me about it, or email me about it. But I think it’d be a great topic for the blog. Looking for guest post writers. If, if you both, you seem like you have plenty of time don’t you guys don’t seem busy at all.

So. Happy to have you, right? I guess lots of work.

Douglas: Just got it. You were joking there.

Dan: Sorry. Sarcasm. The chat.

Douglas: You guys, you guys aren’t doing anything? What? Just write blog posts.

I have an inverted. Sorry, go ahead. No, I was, I had a, I had a thought pop into my head, but I lost it. So Tyler, you go ahead.

Tyler: I thought I popped her thought bubble. So, I wanted to ask Ann verse. I don’t know, maybe you haven’t thought about this since you haven’t written about the imposter syndrome, but have you thought about, are you familiar with like the Dunning Kruger effect?

It’s like the opposite of imposter syndrome. It’s where you think that you’re smarter a smarter than you are at a subject when you’re really new at it? [00:45:00] cause it doesn’t get talked about a lot and I think it’s, Have you, have you ever run into that in your career with either other devs or yourself that’s burned you before or other people?

Dan: Yeah. So there was a time, I don’t know whether this person thought they were. Competent, but they still had a job where they should have been competent and they weren’t. And I was a contractor and I basically had to help them with this project and like drag them through it. And that included some Saturdays and some kind of unpleasant experiences.

And, you know, I was a contractor, so I was getting paid by the hour. I wasn’t thrilled, but it was okay. But I mean, I think that, You know, you just have to. I don’t, I don’t know any way to get people to change if they don’t want to change. Right. So when you come across somebody like that, you know, my best advice is to kind of try to get away from the scrutiny as [00:46:00] possible.

you know, the, the other alternative is like to do politics, right. And kinda cordon them off. I’ve never been really good at politics. I’m just not good at it. And I imagine that would work as well too, if you had that skill sets. But, yeah. So that’s been kind of where my one experience that jumps right to my mind.


Tyler: Oh yeah. I think that’s, I think that’s great advice. So you’re saying, you’re you’re saying either get away from that person. So as in like switch jobs or get on a different team, Is that what your advice would be is, is because like, can you, can you explain a little bit more? I think, I think I understood.

Are you saying that you want to get away from that person basically? Cause they’re going to drain your time and resources as well as make you look bad or what’s the, what’s the big underlying underpinning reason to get away from them?

Douglas: Sure.

Dan: That’s a good question. I mean, I think that the underpin, a reason to, to, to get away from somebody who.

Thinks they’re competent, but isn’t, which [00:47:00] I think is what the Dunning-Kruger effect is. As far as I can tell from your, like, I’ve read about it, but you, you have a great summation of that is that it’s going to SAP the will of the team to deliver the value and, to deliver good software. Right. And so if you’re okay, punching a clock and just, you know, Getting getting paid and like maybe delivering less software than you could doing it, less quality you could, which by the way, is a perfectly fine thing to be, right.

Like not everyone needs to be a superhero. And there are times in my life when I was a more of a clock puncher than there are than other times. So I’m not saying everybody eats like. Like be listen to this podcast and always be trying to level up. Like, it’s good to sometimes just take it easy, but if you’re not in that situation then, and the times when I haven’t been in that situation, it’s been really frustrating to me to have someone that you have to kind of work around to help the team move forward.

And so, you know, like I [00:48:00] said, one option is to try and get them off the team. Another option is to move genes or move jobs. And, you know, I think this gets back to something that’s a real interesting point, which I’ve had managers. I trusted at various levels in my career, some high level of trust, some low level of trust.

You know, if you have a management, you have a high level of trust with, I think that. You never want to, you don’t want to throw any team member under the bus because it’s possible you don’t have the full context. Right. And it’s possible. I didn’t have that full context with that guy. That I, I mentioned, you know, being really dissatisfied with maybe he was really, really good at a certain aspect of the job that I just didn’t see.

Right. So, but I think it’s worthwhile to point out yeah. Actions to a manager that you trust and say, Hey, I don’t understand why. Person X is doing this it’s right there. They’re redesigning the database access layer again, right? Like, is that a good thing to do? I don’t. Can you help me [00:49:00] understand why? and that might be, you know, their approach to take, because that’s going to widen your context and there may be a very valid reason.

Maybe the CTO dictated that we needed move to.net core five, and you’ve got to redesign the data access layer. So, I guess that’s a third option, so leave or coordinate them off or try to understand why they seem to think they know more than they do, but maybe you, maybe your eyes just aren’t seeing the whole picture.

Douglas: I mean, you don’t know everything. That’s a really good that third one is like one of my, my favorites when I mentor people and they walk in, they tell you it’s so bad here. And I’m like, well, usually there’s a reason why things are that way. Maybe you actually decided to join the wrong company if you think it’s really bad, but before you go in there and tell them how bad it is right before you do that, you should start asking some very interesting questions about.

Hey, I noticed that we’re doing things like this. [00:50:00] Why, you know, just out of curiosity and, and kind of get that context around it, and maybe there are real reasons why, and that makes you seem curious instead of confrontational, they both start with C one will make you friends. The other one will make you enemies.

Dan: I, I wrote a blog post called, well, again, I don’t know if I can curse on this podcast, but don’t bag on other people’s code. Basically, because you don’t know the constraints that that code was written under and I’ve walked in and seen things that I was like, Whoa, why on earth? Would you do it this way?

But approaching it. As you suggest Douglas with the error, an adjunct curiosity is far more constructive at improving the code, improving your job, improving the teams performance. Then tell me in, and especially if you’re a new person coming in and bagging on stuff, it’s just not. Not constructive, not helpful.

Douglas: It took me awhile to figure that out. It took some missteps to figure that one out.

Dan: Yeah,

Tyler: guilty. We [00:51:00] go. Where that, where that badge.

 so what’s your, I noticed that you started a consulting company briefly went over to the post on it. Would you recommend, I guess, in what context would you recommend that people go and start their own companies as, you know, as far as consulting companies go being that you do, bespoke or custom software or websites for other people who like who is the, Who’s the right, type of developer to go into that.

And at what experience level do you think they might be most successful?

Dan: Great, great question. So, you know, I would say that the first thing you want to do when you’re thinking about this kind of thing is to start your own company is to be aware of your risk tolerance. And take steps to minimize the impact it’s going to have.

Right. So that includes savings cutting down on your costs, if you can. I think that also makes it more of a good option for people with either spouses that have jobs [00:52:00] or, you know, single people with like low monthly incomes, or no, sorry, low monthly expenses. I think that’s just part of. The risk, right?

Cause it’s just, you’re, you’re at a higher risk than you are if you go be an employee. but a friend of mine says that there’s and he’s been a contractor for years and years, and I’m going to kind of mix contractor and consulting, even though we can talk about why they’re a little bit different. and he said, you know, there’s always three parts to any job.

It’s finding the work, doing the work and getting paid for it. And when you’re a consultant, number one and number three become really, really important. Whereas when an employee, it tends to be number one, number three, get taken care of for you, or you can focus on one of those three, right? You’re a salesperson.

So you do the find the work, your accounts receivable. So you focus on getting paid, or you’re a developer. So you focus on doing the work. So I think that, Being a consultant is really good for giving you a broader perspective of how to do things. It makes you think [00:53:00] about what the market actually wants.

basically you’re interviewing for your job all the time, because it’s very easy to let consultants go, which I find keeps you really sharp and makes you at least it makes me stay more in tune with the technology than I, in the tech world than I normally would. So, yeah. So I think you are interested in kind of stepping out from beyond being a programmer and you want the flexibility and you’re willing to accept the risk consulting lead.

Right? Like I did it for seven years in my thirties, in my twenties and thirties, and was able to take lots of time off and it feels really good to fire a client. If you’re like, Hey, this is not the right. Fit for us. that’s really freeing. It’s scary too. but I think it’s, it’s because of the way developers are and the demand that we have.

I think it’s a really good thing to do. I wouldn’t start out after from a bootcamp and go [00:54:00] be a contractor. I think getting, some expertise. Around other developers for a couple of years is a good start. And then also we’ll get you more ingrained in the community. I actually have a post, a blog post called of woodworking alone, where I talk about some of the difficulties, if you’re like a sole technical person.

And if you’re a solo consultant, that’s really what you’re going to have. Right. You’re not gonna have any other people working on the same projects necessarily, and that’s not a great place to be when you’re kind of trying to form your good habits.

Tyler: Awesome. That’s great.

Douglas: We agree with that jeans. Oh man. I was going to say that the, the, the idea we tell people that we, you know, when we’re trying to get, when we get into placement with them, that we don’t want them to go to be the only developer.

And I’ve had a mentee of mine who made that mistake, where they, he wasn’t the only developer, but they expected him to work on all this [00:55:00] stuff alone. So, again, it’s kind of in a silo and it did it and work out well for him. He was more junior and, and I had to have that talk with them. Like, let’s sit down and have a talk about, you know, it’s, you failed at this, but it wasn’t your failure.

It was actually a failure. Of the people that hired you because you didn’t hide anything from them, they probably saw your re I mean, I’m fairly certain, they saw his resume and, and, you know, they, they knew that this person was, it was like a senior developer who had taken in solution entire, project by, by themselves.

And, and so that’s, that’s kind of the, the, The thing that I think we’re getting out of here, is that be careful about doing that? Get some experience I’ve always said before you go freelance myself, I’ve said that. And I did the same thing. I just only did it for about, I ran my own company for about 16 months and said, Nope, not gonna do it again.

For awhile. I actually do have [00:56:00] intentions of going back out, but in a different way, when I do it, it’ll be a, it won’t be doing software custom software development for people when, when the next business gets up and running. but the, my risk tolerance was I thought was like nil. And then I went, I went out on my own and realized I actually had a much higher risk tolerance than I ever thought I did because, I mean, and it was just.

I don’t know the way that I kept work. I never went without work. I always had work. And if I didn’t, I would’ve lost my house. So it was, I don’t know, tribes having that, that behind you, having it in that fire under you, like, I better find the next job, but I also had to network. Right. That was another really important thing that if you’re brand new, if you’ve just started development, you don’t have the network.

When, when I went freelance and, And I had the, the Rob, I left by salary position for fizzled out on me earlier than, you know, much quicker than I thought it would. I called a friend up and said, Hey man, I’m in trouble. And he said, Hey, talk, call my boss [00:57:00] up right now. And I used to work with him with his boss back at another company I worked at, I had immediately had a new contract gig up and running.

And had worked within 12 hours of, of losing of losing. In fact, they came back and said, Hey, we were just kidding. And I’m like, I’m sorry, I already committed to a new trip. You told me I was, we were done. you can’t do that. If you really weren’t done. So I, I had new work within 12 hours of, of that, but dude, I’m gonna tell you something.

I don’t know if I ever want to do that again.

Dan: I mean, that’s actually a really, that might be a good, to speak to your, your question, Tyler. Like that might be a really good, test. Is,

Tyler: do you,

Dan: when you think about finding work, are you thinking about going to Upwork? And like some other place where you’re going to be one developer amongst so many others, some of whom are in places where they can get by on a lot less money than you can.

Or are you thinking about, Hey, here’s the 10 people I can email to say, Hey, I’m, I’m on the markets, [00:58:00] you know, do you have any work? Right. And that, that know you that want you, that would be thrilled to work with you for a little bit. And those are two totally different types of consulting, right? Like one is a recipe for misery in my mind.

and the other is, you know, a lot, a lot more pleasant and experience. I mean, I, when I was contracting basically eight weeks before my contract came up, or six weeks, I would just email everyone I knew, or the people I want to work with. Like, Hey, basically what Douglas was saying, Hey, I’m going to be on the market in six weeks.

Do you have any needs? And I was able to cobble that together, and that was way better than again, going to Craigslist back in the early two thousands or wherever you would go now. So

Tyler: that’s good to know.

Douglas: Yup. So we do have, we do have a dinner question that we kind of wanted to pose cause we saw the post on your blog.

and, and yeah, I actually subscribed to this a lot, but I thought maybe, maybe it’d be cool to hear you talk [00:59:00] about it, but I really enjoyed it. The best code is no code. That’s a really hard pill to swallow for some developers, but, I absolutely subscribe to that. So go for it, man.

Dan: Yeah. So, I mean, basically the premise is that again, this gets back to why we’re wired read software, right?

We don’t write software because it’s beautiful or because, you know, we want to impress people with our architecture diagrams or anything like that. We write software to solve business problems. And if you, every writer, every line of code you write is solving a problem, which is awesome, but it’s also incurring a cost and there’s a maintenance cost.

There’s a cognitive cost. there’s you know, costs of actually running things. so if you can solve a problem without, and the other, the other thing is that code, we tend to think of code is very malleable, right? Cause we’re in it. We can change it. We understand it. It’s our world. If you talk to anybody who doesn’t write software, [01:00:00] they think that code is like, Weird.

And like they will comport themselves to work around their code. I don’t know whether or sorry to work around applications that they have to write. So I’ve seen my wife do this where it’ll be something on a website and I’ll be like, well, no, we actually have to do it this way. Then she gets frustrated and angry that she has to do things a certain way.

And. So for both those reasons writing less code is good. One is you might be able to solve the problem without automating it, which means that people who aren’t developers can change that if things change in the future, which they pose will too, you don’t need a developer to write it. which means that it might be able to get done quicker, right?

Like the process might be able to, you solved quicker now. You can do manual stuff. You can use low code environments like Zapier and some of those other ones. I’ve seen people that were technically savvy, [01:01:00] but not developers. Build pretty interesting things with, with those kinds of solutions. A third option is to step back and wonder whether or not you actually need to do it at all.

Right. Lots of times. I think it’s called the Rhoda Abilene, was what, one of my bosses. Said once where you keep doing what you’re doing, because you’ve always done it, right. Inertia is a strong, powerful force. And I think that st you know, saying kind of a brash statement, like best code is no code is a good way for us to shake off that inertia and say, well, just because we’ve always done it this way, or because we thought we needed to do this six months ago when we expect this out, you know, do we still need to, if we do, you know, at the end of the day, I want to write code.

but that’s only in service of the larger business value.

Tyler: It’s like a, it’s like a, it’s like the extreme form of like YAG me. I kinda think of like, it’s like, it’s like, you don’t need you’re yanking Anita. Right. Or you don’t really need it. So, I liked [01:02:00] the phrase. Yeah,

Douglas: I think no. I mean, and, and it also, I kind of zeroed in on the like let’s piece things together that exist that have been tested, you know, like we teach our, you know, we show our students cause it’s part of teaching them how to use things outside of, You know, outside of just code that they write it, like bringing a library in or bringing in an external API.

We have an external API that we bring in that handles file upload. Right. That, that could be a real pain if you’re trying to do that with your own, you know, Java spring, boot application, which we could do. but. Making that part of your project where someone will handle that for you. And it’s really cheap to let them handle that for you and you don’t have to handle it.

it, that best code in that situation is usually the one where you don’t have to write the code to get the functionality you need. Yeah. And they could spit all the time. They want. On file uploads. Like if you, with this service, you file [01:03:00] upload and it’s a picture, they let you crop the picture. They let you do some manipulation.

You’re not going to put that in your project. And my in a junior is definitely not going to put that in their project. you know, when they’re trying to get ready for it, the end of our, our cohort. So it really is. where I would love to see someone write their own file, but you know, situation, I really want them to leverage technology.

And part of, I think our job is to, as you become more senior, I think that, that you, you kind of alluded to this Dan, before, as you get more senior, you kind of get this idea of. Should we really write the code to do this or not. And, and sometimes you have to really go, no, we shouldn’t write the code. And then that alludes to your, to this next thing that we talked about, which is the best code is no code.

I love it.

Dan: Yeah. I think there’s actually an interesting point in terms of, you know, what’s differentiating. What is, what is the differentiator for the pro the software you’re writing and Joel on software Joel, Spolsky [01:04:00] who I’ve followed for a lot of years. And I think he’s written some great posts, you know, said basically, if it’s not core to your business, you shouldn’t do it.

And I think about that in terms of applications as well. Like, you know, I’m sure that file upload is a key piece of functionality for whatever application you’re having your students. Right. But is it really going to be the thing that wows. The the, in the portfolio? No. Right. I mean, unless it’s, unless it’s a piece of open source software that is all about file upload, you just want it to work and be effective.

And so I do want to say that there were times in my career where I was. Feeling like a bit of a mechanic where I was kind of just tying stuff together. And I will say, I don’t think that’s very fun place to be, cause it’s a lot less creative. I feel like maybe now things either my perspective has shifted or, or the things that you can kind of plug in together are so much higher level.

They feel more powerful. But, so I definitely [01:05:00] understand the wine retro and file upload, I guess is what I’m saying, but I will say, you know, think is this going to differentiate what I’m building? If not, if there’s something out there, bring it in and get onto what is going to differentiate it

Douglas: for you.

Right. Or could you even write something that’s even close to this, this plugin solution in, you know, in the amount of time you have to work on this project. And I mean, in, in like the end of the cohort, like their capstone projects, they done, right. There’s, there’s no time to waste on, on writing a file upload component where, you know, you can just pull one in that’s free and it works and it’s great.

But then like maybe there are other places where, you know, if you’re writing a community, like if you’re trying to showcase what you can do in software development, and you’re trying to put like a community website together, maybe the chat portion, but the, the, A comments section of these, of posts.

That’s something you could talk about. Like I chose to use a file. This is [01:06:00] going to make them sound good. I chose to use a file upload component because I didn’t think I had enough time. Right. One, but we wrote the view because we thought this was a very core to our, to our project. We wrote the comments section.

Yeah. Like we wrote everything around the comments, in the, in the posts and how to attack, you know, how, how to match students together, you know, how to match people together and stuff like that. That’s the real, that’s the real stuff. Like you talked about the core functionality

Dan: of the product.

Douglas: Yup. Yup.

Tyler: So, we always like to ask this question, maybe heard it in some other, other ones, but what’s, what’s something we should have asked you that we ha that we missed, during our episode here.

Dan: Gosh. I mean, I was thinking about this, you already asked me kind of what my piece of advice to new developers would be. yeah. Another question you could ask is what’s the biggest mistake you’ve ever made? that’s always a fun one. yeah.

Tyler: All right. So what’s the biggest mistake you’ve ever

Douglas: made.

[01:07:00] Dan: So I was.

The senior technical person at a company that supported a sporting event that was on TV and the website that I was responsible for. It fell over during the sporting event. And, that was a pretty horrendous experience. and what I learned from that was always. Test your assumptions in his real possible way.

and I immediately took steps after that happened to make sure it never happened again. But, and I apologize to the client a couple of times the CEO apologize as well, but, that is, I mean, I’ve, I’ve written up. That experience for posterity. And when I wrote it up, like, and even now thinking about it, like my skin starts to crawl because it was just, so it was like 30 minutes of unpleasantness of me trying to troubleshoot this issue while you know, [01:08:00] the TV cameras is run and people were, you know, visiting the website during the event.

So that’s probably my biggest technical mistake.

Tyler: Sounds pretty stressful.

Douglas: Well, yeah, I can just say it makes my skin crawl thinking about being in that position.

Dan: It was no

Douglas: fun,

Dan: no fun.

Tyler: Well, that must’ve changed. what’s like, did you, did you, fundamentally change your thinking? like from a first principles, point of view, or did you only focus on that the, the, the assumptions portion, or did you learn more from that lesson?

Dan: I mean, I think, you know, it’s one of those things where there’s mistakes that you make that are like totally obvious and like boneheaded there’s other mistakes that you make that are kind of like systemic things where like a bunch of small things kind of combine, you know, snowball together. This was more like we knew what we should done and we [01:09:00] did do it.

And so, we up again, implementing some systems, both software and like process oriented to make sure that we would, we wouldn’t make this category of errors again, basically. So, and you know, it’s one of those things like it’s, it’s, easier to, I, it was interesting, cause this was a situation where this.

Thing was only televised, not that often, like once a year. And so it’s really hard to have a lot of, when you’re, when you’re in a process that happens regularly, it’s easier to like adjust and course correct. Whereas when the stakes are really high, it’s harder to do so. And so I think that this was situation where, more forethought on my part, should have happened.


Sorry, my skin starting to roll now again.

Douglas: So maybe no, no, no, no, no. I think I kinda, yeah. [01:10:00] As I say, I get, I get it. It’s one of those where I think I’ve had, I’ve had a couple of, of things that not like on a television level, you know, where people were trying to get to the website. But one of these things where I really, I wrote the code.

Yeah. It worked, my database design seemed like it was good. And then a million rows hit. And everything came to a crawl, like stop. And it’s like, well, how would I’ve gotten, where would I would have come up with a million rows, but I’m going to promise you after, after it, after it fell over, there were a billion rows forever.

And the test database

Dan: totally.

Douglas: You know, where I’m coming from. I could

Dan: totally,

Tyler: totally. No, I think, I think,


Douglas: put 10 in 10 million. Let’s go.

Tyler: No, I think it’s good because people can learn from other people’s experiences. Right. And we learned from our own experiences, probably the best, but if we can avoid.

I think, you know, a few people will probably avoid that in their career. And after listening to that and go, okay, if I know I’m supposed to do something [01:11:00] and it’s production code and it’s mission critical that I should probably do it, you know, that’s kind of what the takeaway I got from, From your, you know, if you could just put yourself, put yourself in, Dan shoes for a second and think of the amount of pressure and anxiety that must have pent up over 30 minutes while you’re frantically running scripts and, and looking every which way to try to fix a problem.

And, I think that’s a good thing to try to run away from, and, and learn from your experience, Dan. So thanks for sharing that.

Dan: Of course. Yeah. And, load testing. Yeah, for sure. If you are gonna have an event that is on television. Sure. You load tests as realistically as possible. So, to be more specific.

But, great question. That was a really insightful question folks.

Tyler: So, Dan, how can everyone connect with you and would you like to plug your book officially now since, I think this is a good time to time to do that. I S I saw that it’s going to be coming out, in a few months.

[01:12:00] Dan: Absolutely. Yes.

Thank you very much. So, yeah. So the book is available. You can preorder it right now on. Amazon Barnes and noble indie bound. Have you, if you go to letters to new developer.com, there is a book link and you can, click on it. And it has the table of contents and the, the cover and. links to all those places you can buy it.

I also would love if you just came to let her soon developer and fucked around like that. Listen, Tyler did and gave me feedback. You know, I love to hear. Hey, Dan you’re you’re, you’re, you’re crazy here, right? Like this is the wrong approach. I had someone actually write a letter or write an email to me today saying, Hey, I wasn’t sure what you quite meant.

Could you explain a little bit more and that kind of engagement, you know, I don’t know. I think anyone writes a book or has a blog, or has a podcast, you know, to, to make. Making a lot of money or to be famous, right? Like you’re doing it to help people. You’re doing it because it’s fun and interesting to you.

And when [01:13:00] you get feedback, that just makes you feel so good. So I also tweets, some more DSS, M O R E D S is my Twitter handle. And we’d love to connect with you there too.

Tyler: Awesome. Well, thank thanks again for your time. It was, it’s been a pleasure and, we’ve learned a lot tonight and, it’s, it’s been fun to talk about so many different topics.

Dan: Yeah. Thank you.

Douglas: Yeah. Thanks.

Episode 7 – What Should You Learn Next?

We talk about the principles of what you should learn next in your career as well as:

  • Understand How Devs Talk to Each Other
  • Understand First Principles in Your Language





Tiny Habits Book – https://amzn.to/3iPMAEB

Atomic Habits Book – https://amzn.to/3iPMAEB

The Phoenix Project Book – https://amzn.to/2CrdpxY

Welcome to another episode of junior to senior developer podcast.

[00:00:05] I’m Douglas Hirsch. And with me. I learned Lemke. It’s a day. We’re going to have a very interesting conversation, but first, before we do that, if you could do us a quick favor and to give us a review on the Apple podcast app, Stitcher, or essentially whatever else you decide to use as your podcast app, that would be really great because reviews will help us out a lot to get our show to as many people as possible.

[00:00:34] And now that that’s out of the way today, we’re going to talk about what we need to learn next. So you have become a junior developer you’re in the field. what, what do you do next from here? And I, I think that what I want to do is go ahead and kick back over to Tyler and let’s, let’s kind of start this off.

[00:00:53] So I think this is something that all junior developers or mid-level developers would be asking them that themselves. At various moments in time, right? You’re going to be saying, what am I supposed to be learning right now? Cause we have a finite, we have a finite amount of hours during the day to, do things on the side or perhaps you have sometimes sometimes work during the week to also learn things.

[00:01:18] And you might be asking yourself, what am I supposed to be focusing on? So I wanted to ask, What your experience has been with that. and then maybe you can go into some of my experience and, and kind of, bounce back and forth and talk about what’s the best thing to focus on. Now, the first question I have Douglas is, do you think there’s a one size fit all solution for this?

[00:01:41] Well, it depends on your background, right? So if you have come into the field from the computer science side of things, so you went and got a degree in computer science, and now you’re at your first job. Your set of questions are going to be entirely different than someone who taught you themselves and happened to get, you know, and then they got their first developer job.

[00:02:02] They may not have as much theory. So maybe they do need some theory where someone who has a lot of theory might need to understand how to apply it more. So there’s, there is going to be a difference. At least that’s from my perspective. And I’m going to tell you exactly where I came from. I was the person that taught myself and then.

[00:02:21] You know, realized after I got into the enterprise side of things that I really didn’t know a lot. I thought I knew something. And then I got into that side of things and, and it’s like, Oh, there’s a lot more to writing code than just making code that works. So there there’s a definite I think that’s interested in seeing how you say it.

[00:02:41] There’s it depends on where you’re at. I D I’d also say. I think the, I think there’s, there’s different things that you want to consider because we have to, we have to consider this in the context of, going from junior to senior developer. So I think the first thing that you want to consider with this subject is what does your employer value?

[00:03:04] Right. What is your boss value? So what are the things, what are the skills gap in your, the requirements? So there’s going to be, there’s two, there’s two different things. I think that exists with how you’re there. And there’s probably more than that, but you can, you can, critique my assessment.

[00:03:20] Douglas, but I think there’s the, there’s the written requirements of your job position. And then there’s the unwritten requirements. I think the unwritten requirements might be a longer, less than the written requirements, right? Depending on where you’re of how, how, your job is assessed. So things like soft skills, things like, there’s different, cultural values at the company that they, they might value, like being able to, work within a team.

[00:03:44] You know, all the there’s a lot of different things we could break down here, but I think you have to assess, you start need to start making a list of what are those . Those unseen values. So when you talk to your boss and you can ask them, and you can also just kind of, see what gets you positive feedback from your, from your, from your boss as well, and start writing those things down and go, okay, I’m getting positive feedback when I do XYZ and I get negative feedback when I do, ABC.

[00:04:10] So I need to maybe ABC is what I need to focus on. Right. So writing those two things down is I think part of the next thing that you need to, focus on and then we get into, well, now, now, if you’ve assessed these two different things, how do you actually go learn ABC? what, what’s your thoughts on, on, on, on that?

[00:04:31] Lots of ABCs, lots of ABCs, X, Y, Z, and X, Y Z is, you know, I can bring this back into, into lessons learned, you know, one of the, I’ve talked about this story before on this podcast, but. I had, one of my, my first or my first actual corporate salary gig that I got. One of the first things I did is I was like, Oh, I’m done.

[00:04:59] I need to check my code in to be sure I don’t lose it. And I just checked my code in and went to lunch. Got back and was in a bit of trouble. I have candy sitting on my desk and, my boss at the time said that, that I always give people candy right before I chew them out so that while I’m chewing them out, they’ll have something sweet that you want.

[00:05:18]that was kind of odd, but it was, it was interesting because it stuck with me like that conversation and what I had done as I checked in breaking changes in everyone, pulled them down. Yeah. From source control. Yeah. And that was a lesson that I couldn’t have taught myself then all the years that I wrote code by myself, I just checked everything in.

[00:05:40] Yeah. Because I was by myself, I wasn’t on a team. And, and so that kind of opened my eyes to one of these XYZ is, and ABC’s was, was I’m working on a team now. And maybe I need to learn how to better work on that. And there’s your positive and negative feedback that I got the negative feedback, which was key and D which was kind of positive, but I didn’t like now and laters, they were, they stick to my teeth.

[00:06:05] So I wasn’t real happy with the cane, but I was going to get, I was getting chewed out. So, It wasn’t the worst yelling I’ve ever had as an employee, but it definitely stuck with me, even this many years. Cause that was back in 2004, that that happened. That was a long time ago, dude. And so, you know, that’s, that is.

[00:06:29] I’ll never, I’ll never check in breakage. I was like, they’re going to fire me. I was so sure I’m about to get fired. You know, I checked it. I think you get that stage because I didn’t do enough. I belong there. The imposter syndrome was strong. I was like hot in here. I don’t even know how I got into this place.

[00:06:46] Much less that they’re gonna, they’re gonna keep me around. but yeah, so, so that’s. That is one of those things, right? That’s, that’s one of those skills, positive, negative feedback. that’s, that’s an actual, you know, the whole idea that you said soft skills was interesting because the, the working on a team is something that you may not know when you go from learning how to code to actually needing, to be able to play nicely with other people who are working with the same code.

[00:07:15] Well, and there’s there’s, I think there’s a lot of different routes we can go down. So I have a followup question for you. How did you, how did you make sure to create the habit? You have the strong grain habit of always checking your code in which is not a bad thing of, you know, in our current architecture of how networks and everything and how you have to do pull requests.

[00:07:38] But I’m guessing you’re using like VCs or TFS or something back in the day and Oh, this was safe. Don’t even we’re safe. Yeah. So, yeah, so some people might think it’s branching or anything like that, or at least that we didn’t talk about it. We have to explain to people, if, if you’re used to a CACD pipelines and having, multiple branches and pull requests, this is not something that was.

[00:08:02] Either existed or was very popular, back in 2004, I mean, get wasn’t even out yet. Right? You’re a year away, long ways from being even something that people talked about. I remember the first time that I brought get into a job was 2011 or 2012. It’s the first time that we were allowed to use get as part of this is in the, in the corporate environment.

[00:08:25] So today I would argue, I would argue, if I had an employer like that, I would argue and actually done this before and go, how does something happen? And I was like, look, this is half my fault, half your fault. Right? If you, if you have, if you don’t have good systems in place that prevent bad things from happening, it’s kind of the employer’s fault, especially in 2020.

[00:08:44] Right. Well, let me, let me explain how that would work then. Right? So this is a really good conversation. If I, again, if you in our program and I don’t know, everyone may not know this. I am actually a, a web development instructor at a coding bootcamp called code up and are through our entire five month course.

[00:09:04] We are, we are introducing the students to get. To branching to pull requests. So when they come out of our program, they already know about this, but if you taught yourself and you were always checking in on your master branch, you didn’t worry about branching. Even when you jumped into your first job, you may have made the same mistake I did.

[00:09:24] And just checked right in and been like, this is good. But Tyler, she just said it was really important is that when an employer knows that they’re about to bring someone in like that. There are safeguards. You can keep people from pushing the master. You can, you can force pushes to master, to come through a pull request.

[00:09:47] Now that’s using GitHub, or if you’re using GitLab, you can do the same, the same things. I, I don’t think that get itself has that enforceability. You might be to put a hook in there that says don’t. You know, don’t let people push to master, but it’s not as easy as it is with like get hub or get lab or bit bucket PRS.

[00:10:09] Aren’t part of get itself. But yeah, you could do right. Different things, but you could force, you could actually make it to where you lock your branch. You could still lock the branch to where only certain people could pull. Could, could merge changes into the portal. I think. I think you can, right? You can use a cook.

[00:10:25] You can actually use hooks that if, if someone tries to push, you can just say it’s not allowed and then maybe come up with a way around it. I think you could still use get, get in a way that you could, you could make it to where people can’t do it. but I’m not sure. And I’ve never tried it, but it gets a really cool, yeah.

[00:10:44] It been other systems to do that, like Bitbucket and other things, so right. Get hub. Yeah. Get hub, Bitbucket, get lab. They all have that stuff built in, but that’s, you have to be using one of those, right. Or else you have to have someone who’s very like, like has the ingenuity to go in and figure out how to make, get, do it.

[00:11:01] And people just probably won’t take the time to do that. You would use get hub at bucket or one of the, one of the big ones. So some, some employers might not like that response. Right. And so you’d have to. I think it’s a, I think it’s a valid response in 2020 of saying, look, this is half my fault, but you like, we need to put, and this is, this goes back to me.

[00:11:23] I like processes that are repeatable. Like I love dev ops. I love tests. I love things that make things repeatable and. Reduces risk, but I that’s my mindset, not a lot of developers, aren’t of a risk free mindset. That’s why a lot of golfers don’t care about tests and they’re like, I want to code and get that stuff out the door.

[00:11:41] And, but that’s how I think. So I, that plays to my strengths to be fair. Other employers might be like, you know what? That was a hundred percent your fault. So let’s say that your ad employer that says that’s a hundred percent your for your fault. And you’re fine with that. Right. How you, how did you make sure to keep doing that?

[00:11:58] So you maintain your job. Was it fear? Maybe, maybe the guy that I worked for was a genius. I don’t know, but for some reason the candy and the, and it was a little bit, can I use, I don’t know if I can, could use vulgar words are not on the, on the podcast, but like he literally said I will. And, and well, I’m going to still try to make it sound not vulgar, but he said that that, whenever he choose someone’s rear end out, he gives them, he gives them candy.

[00:12:27] While he’s doing it. Right. And so like, everyone knew I was in trouble when they saw candy on my desk. And so that was like a, the candy was the thing. Let’s the, the, the, if I get ready to push code, I started thinking about candy. And that was, that was, I guess, like either he’s a genius or it was just by accident, but that’s actually, what did it in my head was I think it was the whole ceremony around, around doing it.

[00:12:50] And it wasn’t like, It wasn’t the same kind of public shaming that you get now, right? Where when you check something into your source control and CIC D picks it up and it doesn’t pass the initial checks. And then everyone on the planet gets emailed about it. That’s a little bit different than, than even what happened.

[00:13:08] There’s a group of seven of us and, and, you know, they, they were like, Oh, pup got in trouble. You know, that’s. That was, that was kind of the, the, the attitude about it. I was the youngest person on the team. I was in my early twenties and they were, they were all in their forties. So I was in fifties. I was literally the youngest person.

[00:13:30]so I kind of had that, but like I said, the answer to your question, which is that it just was how it happened. It just kind of always came back into my head. And even now I still think about that. Right. So I think there’s, I think I want to try to give some suggestions for tools. Cause I think that that is you have some, I think there’s, you know, if I want to try to psychoanalyze it.

[00:13:51] You know, being that I’m a software developer, not, you know, whatever PhD I need to do it correctly. Right. Can I give you my theory as to why that worked? Because the way that we encode memory, usually we encode memory around things that cause great emotion. Hmm. And so a couple of things that happened.

[00:14:14] One, I got the candy and then I found out I was in trouble. So I was like, Oh, Katie, who would have left? Like, I was like, Ooh, left be candy. I was like, that was, there was already this, this thing happening because I got left candy. And then I found out like, no, it wasn’t like someone was giving you candy. It was, you are in a whole crap, ton of trouble.

[00:14:30] And, so there was a lot of different emotion happening and it went very wide spectrum of, of candy. What’s up with this surprise to, to basically thinking I was going to get fired and, and, you know, that. I think that, that the whole emotional roller coaster that I was on in that moment made it stick.

[00:14:52] And then what it was about was, was it was totally logical to not check breaking code in. I’m like how, and then also the self-loathing of myself, how could I have been so stupid to think that that was okay, like these guys, I don’t even know how I got right. Which is, I don’t know if that’s a, I think that’s a normal thing, but probably not the healthiest attitude to have.

[00:15:12] And I definitely have that same. proclivity myself. yeah, I think the theory behind it is that, that the way that we encode memories is when something there’s a lot of emotion. Like you can probably tell me exactly where you were on nine 11. I can tell you exactly what I was doing on nine 11 and a lot of emotion hit.

[00:15:29] There was a major shock to the system. I will not say that, that that was the biggest shock, but it was like in my first week of my first job that I fought for years to get. And I thought that I had just, you basically had PTSD. You were like up at night in the middle of the night, right? Like post traumatic stress disorder.

[00:15:46] Like, you know, not to make. Not to make it light. Like people honestly have that, but like you could have, you could have a negative enough experience. I think at work where you might have a little trauma like that, and stuff could keep you up at night, at least for a while. or maybe for, even for a long time, it depends on I’m sure your boss could have done it in a nicer way.

[00:16:07] He probably also could have done it in a meaner way as well. So yeah. Yeah, no, I, I, I didn’t, you know, I realize pretty quickly that I was okay, just don’t do it again. Right. It was, but it just, the height, that’s what I’m saying is that the height of the emotion, that’s why you’ll see a lot of people who, when you read different books on memory and how to memorize things, they tell you to use like these.

[00:16:31] Like, if you need to memorize a list of things, make it this most wild outlandish story ever in your head. Look at things vividly smell the things like, like you’re trying to get all these different pieces of like, you’re trying to elicit emotion to help encode memory. And, that’s, that’s kind of the same.

[00:16:49] I think it came from the same place, but. You know, that doesn’t really help people who, Oh, maybe it does, but it, it, it, that is one way to learn things. You get negative feedback, it causes a major emotional kickback from yourself and it sticks with you because you don’t want to look like an idiot again.

[00:17:07] Right. Like, there’s some, I’m fascinated. I’m not, I’m not good at become like improving myself constantly, but I’m fascinated with the concept of, of self-improvement, that’s something I’m always striving to, to, understand and, kind of like throwing around this idea of, of, of compiling, maybe a book someday or something of a basically we need systems, goals and habits in order to achieve, achieve greater, you know, For lack of better term perfection or, or becoming better.

[00:17:36] So I think part of this is you might want to look at, there’s a few different things you could do. So one is like looking at a book like tiny habits, for example, that one teaches you how you, how you can create habits and, how you can basically tie habits together. It’s it’s, it’s a really good book on habits.

[00:17:51] There’s another one called atomic habits habits by James clear. Yeah. So there’s that one. That’s a good one as well. I truly think, I think tiny habits is better at, action actually. they might both be good. I lose a lot of, a lot of the details behind things, but you have to take. So if you’re in the scenario, you can’t just say, Oh, I’m just going to remember next time.

[00:18:13] I don’t think that’s a very good, good approach. I think you have to go. Okay. What am I going to do? So for example, on this one, I’d say try to form a habit where you check, you have a checklist that you go and check each time before you do a check in. Right. So you have a checklist, you create that checklist and go, okay, I’m going to check this, this, this, this, and this before I check in to make sure that I don’t have anything, any of these five things that my boss hates, right?

[00:18:35] One of them is a breaking build and you have to develop a habit that, that happens each time. And this is the nice thing about systems and dev ops is, guess what? It does it for you if you’re all set an account. Yeah. But this is saying outside of that, if you’re not in an environment where, where you, you have that option or your boss is open to it and you can go look, I’m, I’m not, I’m a human, I’m not a machine.

[00:18:58] So doing this each time is, is I think it’s great in theory, but you know, If we just have the system in place, guess what? We would never have this happen. Right. That’s the ideal. But I think beyond the ideal is, and I think this is with anything else is, for example, at my work, they want us to be able to track, what we’re working on during the day and to move around, you know, you might be using JIRA or as your dev ops and making sure that you are burning down what you’re working on.

[00:19:24] Right. like, with scrum. And so. That’s the thing that I have to remember, and I need to create good habits for, and if I don’t do that, then that’s going to affect my job because it’s something that, that, that, bosses is looking for. And I think there’s all these different, small things that teams are, are your, your, your boss or your teams need you to do that.

[00:19:45] You can’t necessarily, build in the software. Right. You can’t necessarily say, Oh, each time I do X, Y, Z, you have to, to go in and, and, actually, you know, either run the bill yourself or go in, burden down a card and buy burn down. If you haven’t used scrum before, it means a burn down chart is where you were, you’re taking, what’s called a story.

[00:20:04] And you’re saying that it’s completed and moving it into the completed category so that your team knows what is being, each feature that’s being finished. so I think that’s, that’s some ideas. Well, the time-tracking thing is, is one of the, like the bane of my existence. When someone starts getting to, we want you to time track everything you’re doing to the 15 minute increment.

[00:20:26] And I’m like, I’m just trying to make things work. And sometimes I switch between things, which, I mean, we’ve, we’ve seen the research that’s you really can’t switch a lot and it’d be okay. But sometimes I’ve switched and don’t realize it. Right. And going into an application or having to write something down sometimes even when you’re doing it, I just forget to do it.

[00:20:48] And, I was thinking about this when you said it, and one of the things that you can do to help with that system, it does make things easier. this is something I had seen. I just pasted a link into our chat. But, you know, this is a device it’s called a time flip and what it is is it’s, it basically looks like a, Dungeons and dragons dice.

[00:21:12] A multi-sided dice and you turn it to what you’re working on. And it records the time that it was turned in different locations. And all you have to do is change it. These are the systems you’re talking about. These are the tools and the systems to make life easier. So you can go back and look at a report.

[00:21:29] Oh, well, I did this study. You could still forget. And that is, I don’t know how we teach that except for, Always, maybe the habit that you would need to pick up if, if this is a, if what you’re working on, and there’s reasons for this, right? It’s not, sometimes it is management trying to be sure you’re working on what they want you to work on, but sometimes it really does have to do with money.

[00:21:51] The company is making. So if you’re working on a client project, you need to show that you’re working on the client project, or you need to show that you’re working on, you know, who’s. Which project you’re working on. So they know who to bill for your time. And that has to do with money. Being able to be, you know, basically your paycheck, being able to be collected from other companies where, you know, sometimes it really is a pointy hair manager trying to, I say that, but it sometimes can just be that trying to like make you prove you’re working on things.

[00:22:25] That’s a, that’s a different situation. Well, the only thing I can think of, and I’d still have to work on this. I’d have to set a reminder to remind me every 15 minutes, what are you working on? Like, I would have to do something like that. If I had to keep the track of time like that, what are you working on right now?

[00:22:41] Write it down, you know, that, that kind of thing. So, I like lot I’ve been using it for several years. I actually kinda liked to, Track time, because most people don’t know where their time goes and I’m definitely not perfect at it. But, toggle, if you’ve ever heard of that, that’s the easiest time tracker I’ve ever used.

[00:23:00] It’s the easiest, it’s the least friction I’ve seen. So here’s what you can do with toggle, for example. So do you guys use, have you ever used like Azure dev ops or JIRA or something like that where you have all your stories inside of it? Yeah, I’ve used JIRA. Okay. So it has plugins inside of like JIRA, I think JIRA, I know it hasn’t Azure dev ops where you just go to the story and you can hit play and it’s T time tracking you immediately.

[00:23:24] You don’t have to, you don’t have to list down what it is. You don’t have to do any of that. Like you can know immediately what your. Actually working on. so it’s really cool stuff like that. Another one that can help you, if you want to try to track time. as far as like, if you’re trying to say, Oh, my focused on certain sites or whatnot would be, Rescue time will automatically tell you that before.

[00:23:45] Yeah. so that’s another one. Cool thing about rescue time is that it keeps track of your open window. So what window you have focused on, and then also it keeps track of like different websites you went to and how long you stayed there. This is really good for your information. Right. This is, this is really good for you as an employee.

[00:24:04] I’ve used this, I’ve even told my manager before I’ve used it. And then I realized, never tell your manager, you’re using a tool like this, because then what are they going to want to do? They’re going to want to take in, in and deploy that on everyone’s machine and have the reports come to them. Right.

[00:24:23] Well, and I, I told him, I said, dude, I’m not doing this for you to have the reports. I’m doing this for me to understand what I’m doing, not for you. And, I had a enough of a, a good enough rapport with my manager. That, that when I said that, I said, I would actually be very offended if you went and did this.

[00:24:39] Like, if you went and took those reports, because some of this stuff’s personal to me, like I don’t, I know that you say that you shouldn’t do anything. on the clock, but I’m here for most of my life, like stuff that I want, I need to know what I’m doing and when I’m doing it, but I can’t, I can promise you that it’s not all like work.

[00:24:57] Sometimes my brain goes off and I have to do other things. So I would really take great offense if you went and started monitoring every move of my, you know, every, every browser address every, and they can, but it would be real evident if they got those reports. Like if every week the manager got a report, a lot of companies that do that, they drive away good people.

[00:25:15]yeah, I would, I would, I would never stay at a company that did that. I would just go find someone that trusted me to get the work done. Cause I always got my work done. Right. And that’s what, that’s what most companies should, should worry about. And I think that’s a, that’s an interesting thing. just to clarify too, my, my job doesn’t my dad does doesn’t like micromanage, like exactly how many hours we work on stuff they just want to know, are we on track for our different things?

[00:25:37] So it’s like, but yeah, it’s definitely a. It’s definitely an interesting proposition. So we’ve talked a little bit about, how do you kind of manage things that are, you know, not automatic? I think, I think we need to move back into, technologies and stuff like that. Cause there’s, there’s often, Oh, I feel like I get a lot lost a lot in the different API APIs and technologies that exist in my, my brain gets overloaded.

[00:26:01] Like, even now we’re kind of switching into a. doing a lot of link stuff and it’s just something that I’m not, it’s not my strength, so I’m trying to figure out, okay, what should I be? What should I be focusing on right now? Right. Cause there’s so many different new technologies that, I’m working at work with at work.

[00:26:19] Like I’m now working with.net core three, where you’re using entity framework core three. Which is different from, other stuff. It’s kind of knowing what should I dig deep into and what should I try to understand? Because I feel like, and I think a lot of people will, I hope a lot of people will, will, will resonate with this, but I definitely don’t feel like the best developer in the world.

[00:26:41] Right. I think I have certain strengths. I have certain weaknesses and, I think it’s easy to kind of, I think it’s easy to copy and paste, copy and paste other people’s code work and try to kind of understand what’s going on. I don’t know if you’ve, maybe you’re too far removed from this, this concept, but I think a lot of developers, you probably heard of the meme of the, the stack overflow developer.

[00:27:03] That’s just copy and paste a bunch of things together from stack overflow and get us gets at working, but they kind of don’t understand what’s going on. And I’m not saying it’s quite that bad for my career, but there’s definitely things that I don’t understand, that I’m like, Oh, how the heck is this doing this?

[00:27:18] Cause there’s, as you know, in modern frameworks, there’s a lot of magic going on behind the scenes with stuff like a dependency injection and, you know, MVC frameworks and, you know, spring boot and, and, There’s just a lot of stuff going on. So what’s your, I guess this is kind of for me now, what should I be focusing on?

[00:27:36] Should I be worried that much about, what I don’t understand? Cause if you don’t, part of the thing is like, I still don’t understand a lot about, different parts of, C-sharp. And they don’t understand different parts of, the different frameworks I’m using. So I’m not sure should I dig deep into the C-sharp first?

[00:27:53] Cause there’s, there’s this argument that I’ve seen go a go around recently of like, people are like, you’ve heard, you’ve probably heard this learn, learned vanilla JavaScript first, which I’ve kind of been for versus learning a framework effort. Some people that have said the opposite, cause they go learn a framework than learn vanilla JavaScript.

[00:28:10] So that’s kind of where I’m, I’m stuck at. Right. Can I give you a, an opinion? Sure. I’m not coming down on high and I’m not, I’m not saying how it, how it is, but you should. I will, I will say that from experience. And I do remember the days of copying and pasting code and not understanding everything that I pasted in.

[00:28:33] Just hoping that it would work. Like this is the one thing that’s going to make it work because something weird is going on and I can’t figure out why this won’t work. You know, that’s that’s I think we all go through that. Yeah. The one thing that I find myself trying to tell students now, Is that you are going to do that.

[00:28:55] Right. But the goal should be to, you’re able to understand what you’re poking. What’s your posting pasting. What’s your pasting. If you can’t explain it in the code, there’s going to come a time where someone’s going to ask you about that code. And if you can’t explain it, it’s going to be a problem. So my opinion is that.

[00:29:19] I don’t think you need to understand like how a JavaScript framework absolutely works. But I think you should least understand, like if we’re talking about the JavaScript vanilla versus not vanilla, vanilla versus framework, you should understand how JavaScript works. You, you should have like a fundamental understanding of the syntax of Java script and be able to write things to the Dom and be able to use, you know, do all that.

[00:29:45] Okay. because when you get into using the framework, you’re going to have weird things happen with whatever framework you pick up. And if you don’t understand at least what, how to do what it’s doing for you. So, if you don’t understand how values get put into an input box, you don’t understand, how to generate elements on a page or you, you don’t understand how Ajax requests work and stuff like that, or how CA what callbacks are and the reason they exist and what they’re really doing.

[00:30:15] Like you’ve never written a higher order function that does take a function and, and calls it back when whatever’s done is done. Then a lot of stuff will not make sense to you. It won’t make sense. You don’t need to understand everything, but there’s some very key things. And what you just told me about link.

[00:30:31]there’s a really good article. I wonder if it was an article or a video where I was trying to learn, there was a progression of how we got to link and the video, the article actually really helped me. It’s another Scott Hanselman. Okay.

[00:30:54] There was another Scott Hanselman article, about how we got there. And it took us all the way through the point of like I understood what delegates did. Do you understand delegates? And events like the different sort of delegate and event. I mean, that’s the kind of like the underneath basis of how we get to Lambda functions and then like anonymous functions came in to see sharp.

[00:31:16] And then from there we kind of like put some syntactic sugar on top of it and got to does. And so, like, I got to the point where I read this one article or listened to this one video and, I actually got, like I could build, like I built out one of the link functions and I’m like, okay, I kind of, I kind of get this.

[00:31:37] I don’t need to know how to build everything out. In fact, building a, building out a, forget what they call them now. But like linked to SQL was considered one of them like building out a, which shows that exist anymore. By the way, I just said something that doesn’t actually do any, it doesn’t mean anything anymore.

[00:31:53]What do they call those? Give me a sec. I’m sorry. I, you are digging into things I haven’t thought about in a while, but a provider that’s it. The provider model is a very Microsoft thing, a link provider, right? So you, you. To implement a link provider is extremely complicated and requires a lot of tests and stuff.

[00:32:14] And they’ve made frameworks to help you implement link providers like linked to Twitter, and they did all sorts of linked to everything. At some point, people were like, we’re going to link all the things and, you know, yeah. Just understanding a piece of how link works, made it to where I could use link.

[00:32:30] And understand what it was kind of doing for me, where I didn’t need to know everything it was doing. And that’s, that is that’s personal experience, but I did need to understand what in the language was going on. That made me this thing work for my brain to wrap around it, for me to build the mental models up, to be able to use the technology.

[00:32:51] And that’s where I think that, that you’ll see some people who have problems. they’ll just use a piece of tech, right. And they won’t really understand how we got there and you don’t, you don’t have to understand everything about it, but you need to have like some fundamental understanding. And that’s really easy for me to say.

[00:33:11] Well, and I think, so this is an interesting, this is interesting, right? Cause this kind of goes back to the SRS stuff we were talking about before in previous episodes is, is, you know, this definitely stuff I could write down and then come back to and go, try to understand. So I think part of the, I think addressing what you just talked about as part of the, part of the issue is, I think it’s trying to relate this baby back to math is, is if you jumped straight into.

[00:33:38]you know, calculus and he didn’t understand that addition. Right or multiplication. you’re going to have some issues and I think that’s not a great analogy, but, I think sometimes I jump in and, and things are, things are getting explained to me. And then I’m like, I don’t my mental models aren’t in place or there isn’t connection between the mental models I have.

[00:34:00] And I start getting lost very quickly from cognitive overload. Like I can tell you this, this happen multiple times and different, trainings I’ve had where it’s just like, I’m not understanding what’s going on here in this particular context, because I don’t have enough, underlying. information and it seems like the other senior devs around me are understanding it very well because they’ve worked with it enough.

[00:34:26] I think part of this, part of the frustration I feel too is, if. I think it’s really nice because I have, I have a, I have a body. he just does front end work. I think it’s really nice just to dig into one technology and master that and then move on to something else. Cause having to jump back and forth between the different technologies also is very difficult.

[00:34:49] I feel like when you’re like, and that’s something that I’ve been doing is like, I’ve been jumping from different frameworks. I’ve been jumping into dev ops to front end, to Tabak end again, to new, new edition, new versions of Antony framework. And like, and so I just keep on, I feel like I never get that traction and I don’t know if you’ve ever felt like that before.

[00:35:10] I think part of it is just not, not having enough consistent exposure where I can memorize those things, which is, goes back to the SRS kind of, you know, giving you that exposure artificially. but I think that’s, that’s part of the frustration I’ve been filling is going and being like, okay, I’m lost again.

[00:35:28] Right. I’m lost. And I don’t even know how to orient myself. on this particular subject, unless I were to sit down and, you know, maybe pick, pick the architect’s brain or pick a senior developers brain, which you can’t always do, you can’t always bother every other developer until you understand a particular subject.

[00:35:46] Right. You have to dig in for yourself and try to learn things.

[00:35:54] Yeah. I mean, that’s, that is, that’s the difficult thing, but part of this really is utilization, right? I mean, this is, this, is that, that? What is it? Oh, my brain just drew a blank. Call me. I hate that when it happens, but actually using a concept. You know, using the, the concept, as opposed to knowing about a concept, and even breaking it down a little bit, like for instance, if link is bothering you, well, what, what is, how would you write, how would you write a, how would you write select, like, let me, let me, I’ll give you a bit of, of, of, Like there’s link is interpreted as it’s compiled.

[00:36:40] But what I’m saying is, is that it, you say like from something, select X, Y, and Z, well, select, you can actually write these as, as methods instead of writing it as a link query. Right? You can, you can say like you can type out your list and you can say.select. And then, you know, hammer out what you want in a Lambda expression.

[00:37:04] And if you can write select, if you could just write one of those, it will give you so much more understanding of what is happening. What link is really doing link is strange because they are taking this thing that looks like a different language that you’re embedding in C sharp, and they’re making it into C sharp.

[00:37:27] It’s the same thing. Like if you think about how JSX works in react, I think, have you ever dealt with react? I played with it a little bit. I don’t understand. I just dropped thing out there, but re react JS from, from Facebook basically uses a language that looks like you’re embedding. HTML into JavaScript.

[00:37:50] So it’s like, you’re doing this, like, like you’re doing these language jumps between like I’m in JavaScript now. Now I’m in a HTML being that it. And what really happens is, is that in the compile step of, react, you know, when it actually converts everything over, it’s actually converting those to method calls.

[00:38:10] Well, that’s exactly what, what C sharp is doing is. You write this thing that looks like from, from this array, select column a, B, and C, where, and you know, some stuff, but really what it’s doing is it’s actually converting those into method calls on the, on the collection. And, you just don’t see it. It’s just, you get to write it that way.

[00:38:34] And the compiler compiles into, into that. But once I realized that that LINQ queries could be written out as methods, and once I realized how those methods worked, I could do almost like it’s just a, it’s like a first principle. If you know, how we get to land does and, you know, and you know, kind of what they’re gonna do for you, The yield keyword is another good keyword for you to think about.

[00:38:59] Like, I don’t know if you’ve ever used the yields keyword, but, and, and C-sharp the yield keyword is kind of one of those things that you may, you may want to take a look at it. So I think, I think we’ve been digging into the, the, the. so I have some takeaways for myself from this, but I think like we’ve been digging into the specifics of, of, of, my particular issue.

[00:39:22] I think, I think as we try to wrap up this episode, I wanted to go into, Thinking again about what, what do I need to learn now? Because I’ve heard of this concept before, if you want a, if you want another job, right. Or if you want to raise, you start, have you haven’t you have to start doing those things now, and then you will get it raised.

[00:39:40] Right? So you start acting like a senior developer as a mid level or junior developer. You’re eventually going to get that role. Right. So what are the different, what are the things that I need to project into the future? To be able to get, to become a senior developer. Right. So what’s the, what’s the next thing I need.

[00:39:59]what’s the next concepts that, that senior developers know that maybe junior or mid-level developers don’t know that can be immediately applicable now. So if I were to break it down to a set of concepts, principles, right? Not, not like code, but let me, let me think about that too. So if you’re a.net developer, And you’re using C sharp.

[00:40:22] One of the things that I would do is make sure I really know. No, and I’m not saying no, like the entire.net API, but that I know what the language can do. I know what the language features are. And you’ve talked about using SRS, like space repetition systems and stuff like that to help memorize it. Right.

[00:40:38] I would really understand my language. I even went as far in this as to, I would write some code and decompile it and see what it was, decompile it into or see what, what the, What the not decompile it, but I would compile it and look at the aisle. I actually had some incidents where I did that, where I wanted to know what was happening, because I heard about like boxing and unboxing.

[00:40:58] And so, in, in vb.net, I actually did, I did do a comparison where I did assignment without declaring what type of variable it was and watched how I did the automatic box on box staying. And that, that actually adds like, I I’ve actually seen this stuff because of curiosity, in, in how certain things work.

[00:41:18]After after you master the language, you’re not going to learn all that at once. Right? This is something that I’m saying, think about don’t go off and I don’t think you need to go by, I mean, you could, you could go by C sharp in depth. It’s a really, yeah. John skeet, like is masterful over the C sharp language.

[00:41:35] He works for Google. So there might be a little irony there, but a full let’s not debate irony. Well, actually, yeah, I mean, it’s unexpected, right. You know, it was like here I’m I’m, I’m the master of C sharp and he’s, he’s a Google employee. Right. But he is, His books were very good on C sharp. And I’ll give you a good understanding.

[00:41:52] And again, this is what I’m saying. I don’t think you need to know the API APIs. Like I don’t think you’d need well, I think for stuff you use consistently, you need to know it, right. And maybe there are things that you want to keep. For example, Right. Link does. But the way that if you’re thinking about link as in typing yeah.

[00:42:10] A link query, it feels funny saying link query because the queue is query. So I’m saying link, a link query is like saying query query, but if you type out a link statement, there we go. If you type out a link statement, it feels very, it feels so close to SQL and, and, yeah, because of the, the, the, from being first.

[00:42:32] It kind of loses that a little bit, but we don’t want, we don’t even use that. We use the, I kinda get mixed up on the syntax that we, I think we use the queries versus the statements in our code. So you’re using, so when you say like, we do dot where then.to list and not, yeah. Yeah. Yeah. Yeah. Okay. So that’s your using is using the statements where you’re just using, you’re using, you’re using the API.

[00:42:55] You’re using that the, the API that links sits on top of, so the decision was made not to use the actual, embedded link statement that bolt and the same exact thing. Yeah. They’re just both compiled down. Do they go off the pilot down the same thing? Yeah. Yeah. So. But the thing is, is to understand first principles of what your language is doing.

[00:43:14] And I think a book like, like C in depth is really great or whatever language it is. If you’re going to go with the Java, that Java and what it’s doing and how it handles things, you know, especially if you’re already working now, if you’re trying to learn to get your first job, maybe you don’t need to know all those things, but this is I’ve gotten my first job.

[00:43:37] And, and now I need to keep my job and I need to do a good job. Right. And so that’s learned the first principles of the language learn. what else can I think of, learn how developers talk to each other. So that would be. We have a language and a lot of times we will use, we will use design patterns.

[00:43:59] In fact, even the fact that you’ve heard the term dependency injection. Does that mean anything to most people on the planet except for programmers? Yeah. I mean, it sounds kind of, it sounds kind of rude when you, if you just say it to someone. Oh the streets, you know, so we do have a language. It would be good for you to hear that language, to kind of understand some of them.

[00:44:21]in fact, dependency, injection is kind of one of the, That’s that’s the D and solid, right? So, so maybe a good concept of, of the solid design principles it’s related, but it’s not actually the, the D and solid isn’t that a dependency in version principles. Oh, that’s right. That may be the, I, you know what?

[00:44:40] You could do this stuff for so long and you can still mess things up. You don’t even have to edit that out. It’s fine. I want people to know that I’m real. No, the D dependency in version principle. Yes. It’s different from dependency injection, right? So it’s kind of, well, I guess you’re right. There is a little bit, but I mean, I don’t hold, I know what the difference is, but I’ve been told that it’s different because it has a different name.

[00:45:01] So well, dependency injection is the method. The dependency in version is the, is, is the principle.

[00:45:14] And I’m going to stick to that for now until someone crawls out and proofs of listening to our show and tells me that I’m wrong, which will be great. You tell me I’m wrong. And then we will just like, with the reviews, we promise to mention people who do give us. Good, you know, well, who give us any reviews, you know, it’ll be great to get reviews, but I’ll also mention if we get feedback that says I’m wrong on that, I’ll be so like, so and so actually spelled it out.

[00:45:36] So high level modules should not depend on low level modules. Both should be depend on abstractions, which has interfaces. abstraction should not be dependent upon details. Details. Concrete implementation should be dependent upon abstractions. So this goes back to, sounds a lot like dependency injection is the method that we use to adhere to dependency inversion.

[00:45:58] Yeah. But there’s probably, there could be other methods potentially. I, I, not that I know of any, but. well, we’ve accepted in the industry. Like every I’ve I’ve done Java, I’m doing spring boot right now. We use dependency injection all over the place. Right. It’s kind of the whole composition versus inheritance it’s similar, but, but that, that principle, you can still compose things without using.

[00:46:20] Dependency injection, right? You definitely could. And I’ve written systems like that where I didn’t use dependency injection, but I definitely used, I definitely use the principle where everything was built to interfaces, right. Dependency. So I want to break down dependency injection just so we can teach something and maybe I’ll I’ll mess up and you can correct me.

[00:46:38] But dependency injection is basically where you are actually. At runtime, you were injecting the instances of all your objects instead of knowing them up in the actual classes. So you have basically, there’s basically a, some type of bootstrap bootstrapper inside of your framework that will help you to go and new up all these objects instances, and those get injected at runtime.

[00:47:02] So in your code, you should base it basically in any of your classes, you should never be typing a new. And then object, right? That, that, that is kind of how dependency injection works. And what that does for you is allows you to not, it allows you to have your code be testable and, less brutal. You know what, you’re close enough, close enough where you can, well what’s, what am I being?

[00:47:26] So, so the only thing, and I think you actually really, you, that’s a good explanation of it. You, you never should be typing new. It is, it is basically the dependency injection is the fact that we do have this thing that we’ve registered, like for this interface, send down this type and you could even say for this concrete type sent down this instance, Right.

[00:47:49] We can, we could even do stuff like that with, with certain dependency, injection libraries. We can do that. But basically what happens is that in the, in the initial load of the application. And I would say that we don’t usually do this at runtime every time I’ve, I’ve wired up. I’ve wired up dependency injection, like in the past recent, decade.

[00:48:11] It has always been. You know, in code somewhere where I’ve said I’ve written some line of code that says for this interface, send, send a concrete version of this down. Like whenever someone asks for this interface, send this down. Now for that, we had some dependency injection frameworks that would actually let us wire it up in XML.

[00:48:35] And I thought that was actually really cool. I actually liked that a lot more than, than doing it in code because it meant that it meant that I could just change the XML file out and change what my concrete implementations were without having to recompile. No, I think that’s good. You made that you made that assumption.

[00:48:52] So I wanted to go back to, sorry. You made that correction to a what I stated, but I want to go back at it. I don’t think I correct it. You didn’t say anything wrong. So I wanted to go back to a understanding how devs talk to each other. Now, one way that I found that, yes, and, I’ve listened to start to listen to a lot of podcasts and YouTube videos.

[00:49:11] And that helped me a lot with understanding how devs talk to each other. And I started to understand that that was what helped me a lot to understand concepts and. Because I prefer video and audio as my learning mechanism. That’s my preference. We don’t have learning. We don’t have a learning styles.

[00:49:27] Right. We learn, we all learn the same way. We just have learning preferences, but that’s one thing I want to, but one of the myths I want to try to dispel, that’s been perpetuated, but, that’s, I think that’s one way that you can, you can do it. Do you have any other suggestions for how you can, learn how developers talk to each other?

[00:49:43]other than obviously talking to other developers and over. Overhearing what they say. So, I mean, that would be one would be that, that, watching videos, but I think even better. And I know nowadays it’s a little bit different with everything going on, but. I would have always said go to meetups, listen to how people talk at meetups because that’s actually, yeah.

[00:50:05] Real face to face, not rehearsed, not videos being recorded. You know, people aren’t on camera there, but that’s actually listening to how people talk to each other about programming. You know, that that, that does help. But I think it still isn’t the right environment. Right. You want to hear how developers are talking to each other in the company that you are in, but you also do want to have that kind of outside exposure.

[00:50:32] So you can know that that’s because that’s one thing I had to learn was that the company I worked for, that other companies don’t work that way. It’s actually why I liked the fact that I worked for a lot of different companies over, over my career so far, is that, is that I’ve had exposure to so many different styles of, of doing.

[00:50:49] Programming that I can understand, like most places I’ve walked into now, like, Oh, okay, you’re doing this. Okay. Right. I I’ve seen it before. And, but yeah, the thing is, is that corporate exposure, how are people actually writing code in the company that you’re at? How are developers talking to each other?

[00:51:08] Do they talk to each other? I would, I would actually pose that if you can’t, if you’re, if developers aren’t talking to each other, it might not be the best company in the world to be at. You may want to somewhere, you can learn, you might get an alert as quickly. Right. So, right, right. Cause if they’re not, if they don’t encourage discussion, that’s, that’s the thing.

[00:51:25] And that kind of goes into one other myths that we’ve talked about. I don’t know if we’ve talked about it or not, but there’s another myth out there that programmers are, are, you know, that’s. What is it? programmers are introverts that don’t want to talk to other people. Basically you put them in a closet, slip pizza under the door and get code back out in return pizza and coffee or pizza and energy drinks.

[00:51:48] I’d say that’s a stereotype. And I think there’s definitely people who fit that stereotype, but I don’t think you and I, but that’s not, that’s not going to be, you know, they might crank a lot of code out, but they may not be the best player because then if something happens to them, you’re damaged.

[00:52:02] Heavily like your company will be damaged. And so they talk about this in the Phoenix, they talked about this kind of in the Phoenix project. If you’ve heard of that, a book, the pragmatic programmers book, right. I think it might be, but that’s a very interesting book, or pragmatic publishers. See this, Deborah has that book, that book, that’s a very good for junior devs because I listened to that and it kind of put me, it kind of got me and.

[00:52:29] Cause you kind of, you get to listen to these conversations, these fake conversations of executives and developers and stuff inside that book. And it kind of gets you into the mindset of, Oh, this is how it can look at code from a business perspective. I can see the positive and negative things. It’s a great book.

[00:52:45] So let me put that link in here. Yeah, definitely put that link in there because anything, I I’ve done that for a very long time, but in fact, we had a show where we talked about this, you know, the, the business is your business. You know, that, that whole, that whole idea, that it’s more than just how much code you can crank out, but it’s, you know, it’s the fact that that decisions you make as a programmer to do something or not to do something can affect the bottom line of a company.

[00:53:11] And you should probably not. You should probably, you should think about those things when you’re making those decisions. Yeah. but I think it’s. It’s interesting. I think that in that book, they talk about a developer who basically knows everything about the systems. And he’s the one he’s basically the bottleneck, right?

[00:53:34] This book goes off of, there’s a book called the goal and it talks about this is what I think I’m in the eighties. This book, the goal is written. If you’ve heard of lean manufacturing, I think that’s what lean manufacturing is based off of. Is this just in time, knowing your throughputs of your different, your different, parts of your factory and things like that, it basically takes the book of the goal and it puts it into software development.

[00:53:55] It’s very interesting. Very interesting concept if you’ve heard of that book before, but I think I would just see habit the goal and just go to this book because it basically teaches all of those concepts inside of, this, inside of the, software development, job. and it it’s a little bit less, some things, a little bit more, straightforward in some ways, but, But yeah, I think we get, I think we, I think we hit on some great topics, that that will help people think so. Unfortunately, people were coming here and going, this is exactly the thing I needed to learn next. I don’t think without context, I don’t think you can give people really good. like you were able to give me some good, good advice and you’re able to give some good general advice, but it’s hard to give the exact advice that people need based on their context, unless you’re mentoring them directly.

[00:54:42] Right. And that’s, that is, that is actually a good point. I will say. I will say that first principles of your language of your chosen language is number one. Right. That that is kind of, to me would be the number one thing after you have your job and you’re trying to work in your environment and you’re doing, you know, you’re learning as you’re working in that environment.

[00:55:05] So that’s not like you haven’t turned all learning off, but if you’re looking for, what do I need to go spend some time on? If you don’t have the first principles of your language down, you don’t understand code that you’re copying and pasting fully, not necessarily what they’re doing underneath the covers, but why the language itself works.

[00:55:23] Why does this weird characters inside the parentheses actually run off another function? How does that work? What’s happening there? You know, that, that kind of, that kind of thing, then you might be lost in a lot of code. Cause if you know your first principles, you can interpret almost any, you can, your brain will fill in the details.

[00:55:41] Yeah, what’s going on. that’s number one, number two. Is there, like I said, there’s a language that people are going to speak, learn that language, right. And there’s two languages. One is the programmer’s language and two is the domain language of the company you work for. So learning the business a little bit enough to know when people are using this is terms or using software development terms and understand why people are making the decisions that they’re making about, about writing code.

[00:56:09] Why are they doing it? This is stuff I wish I could have told myself when I was in my early twenties. Like I just, I wanted to write code and I wanted to do it in the coolest way and not suck at writing code. I didn’t think about all these other business things. And I don’t think that that helped me. I don’t think that that actually helped me be a full well-rounded developer.

[00:56:28] If I could go back and change something about myself, it would be going back to that. And then. You know, what you’re going to run into is you’re going to run into people, talking about you’re going to hear dependency, inversion or dependency injection. You’re going to hear some terms that you don’t understand.

[00:56:43] And every time you hear a term, you don’t understand, write it down and consider it, especially here multiple times. If you hear it three times, that’s beyond a coincidence. So write it down and start figuring out is this the first principle of my language that I’m not getting? Is this part of a framework?

[00:57:01] Is there a concept to this? Is it a design pattern? Is it a method? Is it, you know, kind of go into to those kinds of things? I think if you just do that for now, okay. You’re going to push yourself. We could do another should, we could do lots of shows on where to go after, after that, like I could, we could make a whole series on.

[00:57:20] On where to go, because there’s all sorts of other things that you’ll think about later on, like when you’re writing code, is this code efficient or not? You know, that’s, that’s going to be another conversation we, we could have, you know, That’s that’s, that’s the thing. And I kind of want to close with that because we were looking for, and I hate doing it right at the end, but I think it is good to kind of try to tie everything together that we’ve talked about all throughout the show into, into a good little package that you can run off with with some actual advice that I think anyone could could take.

[00:57:51]because it really does kind of say, depending on where you are, do these things and that’s it for me. That’s awesome. So, thanks again, Douglas. And, we want to remind you again, to leave a review on either, Apple podcasts or on Stitcher, and we will go ahead and, read back your reviews. They lay for us, cause we’d love to, You know, toot our own horns.

[00:58:17] No, you want it, why don’t I give you some credit for, for taking that time to, to leave a review. So, yeah. so please do that for us, that will help us so much in, in getting the word out and also go ahead and go to junior, to senior dev.com for slash about and sign up for our newsletter. I want to start putting out some, information there for, You will get our latest releases as well as, we’re going to start putting out some surveys and stuff so we can get, some feedback on these episodes.

[00:58:43] So we’d love to hear from you on there. All right. Cool, man. Thank you again for joining us. Have a good one. We’ll see ya. Thanks.

Episode 6 – Overcoming a Mid-Level Crisis – Interview with Jeff Shek

Jeff Shek is a seasoned lead engineer with exceptional experience in building distributed, reliable and maintainable code for web and enterprise systems. He has personally built, grown or mentored software engineering teams. At his last startup, HistoWiz, Jeff’s primary focus was engineering an online platform for annotation, collaboration, machine learning algorithms and processing of digital histology. 

Prior to HistoWiz, Jeff has served as either a technical lead, senior engineer, and/or product manager of NYC’s well-known and fastest startups (Capsule Pharmacy, Artivest, YCharts). His open-source projects have been used by thousands of people.

Contact Info:




What we talked about:

  • Spaced Repetition
  • Anki
  • How to Create Anki Cards
  • The Power of Flow
  • Cognitive Science
  • Productivity Hacks
  • Effect of Exposure to Multiple Codebases
  • What is a Senior Dev?


Interview with Jeff Shek

 welcome to junior to senior dev I’m Tyler Lemke. I’m Douglas Hirsch. And today we’re here with Jeff Scheck. Now Jeff is a seasoned lead engineer with experience and building distributed, reliable and maintainable code for web and enterprise systems. Uh, he served a technical lead senior engineer and product manager for, uh, some New York city’s well known and fastest startups, such as capsule pharmacy.

[00:00:25] Artivest and why charts is open. Source projects have been used by thousands of people. And one of the main reasons we have him on today’s cause he has a super power using something called space repetition. So we’re going to find out a little bit more about Jeff. Jeff. Thanks for coming on. We’re really excited to talk to you.

[00:00:43] I’m really excited to be here. Um, so can you tell us a little bit about your background? It sounded like, um, I was going through your blog to try to. Um, that’s how I actually found out about you originally. And I was trying to go through those articles again. I noticed that you, you started coding, like you started learning code on the job.

[00:01:01] Can you tell me how, what was your background and how did you get into the field? For sure. So I graduated college, this like actually a finance and economics degree, so I didn’t have a coding background. Um, and I started working at like a tech company, like at a school. Um, I wasn’t doing any coding there.

[00:01:18] And then at some point I just kind of like, kind of hit that quarter-life life when I was like, Hey, this isn’t really what I want to be doing. I got really sick of finance, at least just the, my role in finance. Um, so I joined another startup in a clear the city in Chicago. Um, and there, it was basically learned on the fly.

[00:01:33]Um, so they gave me a book. It was, um, Like learn Python the hard way, but is that Shaw, which is a really good book. Um, and just essentially, it was like the responsibility to throw in a like, Hey, we want you to deliver this code. And like, they were pretty hard on pull requests. Like they would always do you everything.

[00:01:47] So you learned a lot there. Um, and that’s essentially where I kind of like got most of my knowledge the first three years. It was just really a blur, but I learned Python there. And then after that, essentially, you just kind of grow in knowledge as you have a basic foundation of software engineering. Um, I’ve been coding for about eight ish years now.

[00:02:05] So it’s, again, it’s a, it’s a long journey. I’ll probably coding for many more years and there’s just still so much to learn.

[00:02:14] Awesome. So, um, So you, it’s good to know some of that background, why you went into it. So you found yourself w if you go and read the blogs, we’re going to give some people linked to the blogs. They can read it for themselves, but, um, you found yourself, like, what was it? It seems like it was like, what four, was it four or five years ago?

[00:02:32] Or was it three or four years ago? Yeah, it was six years ago. So how long have you been doing, uh, uh, space repetition for it’s about five to six years, but five or six years. Okay. Right. Okay. Cause I got kind of my timeline mixed on the, on the blog articles. So six years ago. So you’re about three years in to your.

[00:02:55] To your career. Can you kind of tell us where, where you were at and kind of paint a picture for us, um, where you were mentally kind of like you did. And so the blog, so I was, I was coding. I was learning on the fly and like at some point you kind of hit this wall and it happens to everyone where. You’re learning a lot, but you’re also, you’re, you’re basically having a lot of trouble keeping up with all this knowledge.

[00:03:18]Um, I think it’s like the first couple years, there’s just so much fun and you’re like, first you’re learning Python and you have to want to do database work it’s to learn how servers work and each obstructions at different level. Um, and the difficulty that I had was. The startup was very hard. There was just so much work to do.

[00:03:32] And I was kind of comparing myself. There was a few of us that are all start at the same time, kind of similar backgrounds, where we were just learning on the job. Um, one of my colleagues and he’s just the certain people are just genetically gifted and he had just basically a photographic memory. I think we were all watching him as, as his progression was just so much faster than ours.

[00:03:50] And there’s always the hang of jealousy. Cause you, we all know we start at the same time and it’s just, his name is Ryan. It was just, just like watching Ryan grow leaps and bounds. And we were like still struggling with like command line stuff. And Ryan’s just had a photographic memory where he would like read some documentation and just do it fully like, and it’s just an amazing gift to have if you can do that.

[00:04:11]Uh, so. I recognize that memory for me was a huge issue of like, I couldn’t recall stuff as fast as he could. And I was always just Googling back, like, how do I do this and get up, or how do I do this? And, um, so we started using space repetition. So what space repetition is, is to describe it as, um, it’s basically like this way of this algorithm that kind of prevents, uh, sorry, that keeps on giving you certain types of.

[00:04:34] Flashcards that quiz you it’s these spaced intervals. So for instance, if it does, it gives quizzes you on like day one day, three day, five day 13, the 26 50, at that point, you actually remember the knowledge much better without having to kind of redo all the flashcards every day. Um, so I started using that and it was just super helpful for my career.

[00:04:55]Um, at some point I finally felt like I was. I was like moving up the mountain of like how much I was learning and the same time, like I wasn’t forgetting essentially like everything I learned 30 days ago. Um, so yeah, I think that’s my experience with space repetition. It did like break me out of the slump that I was in, where I kind of felt stuck where I felt like I was just stuck at this mid level software share.

[00:05:17] Like I was just forgetting 30 facts a day and learning 30 facts day. Um, and so it’s been super helpful. It is. It isn’t free though, I guess. So the best way to describe is it isn’t like timeframe. Like I do have to spend time at it every day. Like it’s like 15 to 30 minutes of like reviewing cards. Um, but then like the payoff to my career has been tremendous because it’s just, I can build stuff so much faster.

[00:05:39] Now I can stay in like a good rhythm and a flow. So I like to speak highly of it to everyone, but I know it’s a hard commitment to do, like just saying like, Hey, you got to do flashcards now. Right? Yeah, you mentioned, you mentioned a lot of stuff in there. So it’s funny. Cause like one of our previous episodes I talked about how memorizing syntax is actually a good thing.

[00:05:58] And part of that was from what your article said. And part of it was cause I learned that, um, This term, like cognitive overload, where you’re staring, you’re looking at a screen and it’s like, there’s so much, like if you’re looking at a code base and you don’t understand all the API APIs, like your brain kind of just shuts down and that’s what happens to me quite frequently.

[00:06:16] So, um, I thought of this interesting that had, did you notice that that helped you as well with as far as cognitively? Or was it just memorizing the API facts? Yeah. Right, because back to your point, right? Like if your brain gets tired of starts, it wants to go to some distracting, something easier. Um, that helped me a lot.

[00:06:33] We use a lot of, um, pandas Python library that we use. And there’s a lot of unique syntax with that. Um, and just like knowing that firsthand is much better, it’s like, well, we memorize it. It’s not like you’re not embracing chore API calls, but you are memorizing like the parameters that kind of go into it.

[00:06:49] And like some of the commonly used ones it’s, um, I don’t use occupant to memorize like esoteric, um, API, but it is like, Hey, if you’re constantly using this, um, it will ingrain in your mind much faster, um, versus slowly just using. So some people like will just slowly index over time, but if you’re going to aggressively figure it all out and like a month or so, it’s just so much faster to do stuff.

[00:07:10] Yeah, and I want to, I want to highlight how much, how much your productivity went up in a bit, but something you didn’t mention was that you mentioned in your article was that you spent about 70 hours a week coding. So you weren’t slacking off. Like you were like, you were like trying, at least at your they’re trying to code 70 hours a week.

[00:07:31] I had my ass in seat. I think that it’s terrible. It’s like, I was like sitting down frustratingly, trying to, and just like your brain is like giving up. Um, yeah, it was like a super hard experience where you’re just like trying to learn something and you just don’t feel like you’re making fast enough progress.

[00:07:45]Um, yeah. I mean, like I’ve worked at starved so many years and it’s, they’re always like real time commitments. Um, we were talking about earlier, but it’s just like the startups kind of trade your youth, but you do get a lot of experience out of it and it all becomes one big blur. Uh, but as a result, you do actually.

[00:08:00] Good startups. You can learn so much quicker than regular corporate roles. Interesting. Um, yeah, that, that does make sense. And I guess that’s a trade off. We were talking about cultures between startups and, uh, non startups as well before, and the, the differences there, but, uh, Go ahead. Oh, well I was going to say that I did have a question.

[00:08:22] And so we we’ve said, you know, it’d be good to put stuff in inky cards and, and whatnot, but maybe give us an example of one of your anchor cards. Cause some people may be sitting here going, well, what do I put in those cards? Okay. Yeah. So I think like some of the stuff I might put in is like, Um, how do you do a specific SQL query?

[00:08:41] Or like, if, like, if you’re just a beginner, it’s like, how do you commit a good message? And so over time, like you can learn that or you can just kind of put it on as like, Oh, you’re going to type in, get commit dash M and then you put in your message there and then you hit send. Or like, and you say that as an AKI card, the gold card isn’t supposed to be, it shouldn’t be super hard to do.

[00:09:01]Um, but it is something where if you need some members, some type of syntax, it’s super helpful. Lisa, when you’re beginning something to kind of put all that knowledge that you might Google, um, back into an AKI card. Um, and then, so I’ll put in like specific type of like pythons index of like, how do you do a turnkey operation or in JavaScript?

[00:09:18] Like, how do you, how does like slice work? Um, so these types of things where. You might reasonably remember it if you were working on JavaScript full time or like one of the languages full time. But if you’re working on like five or six different languages, you’d have to learn something it’s like, It’s just nice to kind of put that in there and to be able to like refer there without having to constantly expected to using one specific type of language.

[00:09:39]Um, so there’s like stuff in there that I had from like C-sharp, um, that, and I haven’t used C sharp from like years. Um, and then you’re like, okay, cool. Like it’s still kind of comes back as a refresher. Um, but I also kind of put that as a caveat of like, I will delete AKI cards a lot there too, when I’m like, okay.

[00:09:51] I’m not going to be using PHV. And so I don’t really care if I forget this type of knowledge or assume that I won’t be using pastry in years to come. Um, all right. Uh, so that’s what I kind of think of when I use, like on key. I also do a lot of like new types of knowledge. So I might do something like, um, these are the broader topics of like, Hey, what is, um, what does active record, or how does flash this, do something behind the scenes?

[00:10:15]Um, or how’s like, Password hash and done in Django. Um, these are the types of things that you might look up once or twice, but you won’t like you won’t, it won’t really stick, right? Like the amount of times that you Google something you like, Oh yeah, cool. And then you forgot about it. For me, that was quite prevalent.

[00:10:30]Um, and so if like putting into Anchia and then AKI reminds me of this knowledge, essentially like one, three, five, seven months or something like that, like it’s a great way for my brain to kind of come back to and just remember that knowledge, um, And then I do have a lot of like auntie cards now that kind of refresh in like three years.

[00:10:45] So it’s been really interesting. It’s like, honestly, remind you of something you’re like, Oh, I definitely know that. I’ll be like, okay, the next reminder that we’ll give you about this is like three to five years. So that’s crazy. Well, I was going to, uh, I was going to ask then, so, so in these, these, uh, honky cards, um, the way that you answer the questions, is there a way that you type the question out?

[00:11:05] Do you, um, Oh yeah. It is like a, when you answer it as basically, you’ve kind of answered it in your head and then you will give this interval of like, um, zero is like, Oh, I got it wrong. Or like one, two, three is like one, it was like kind of hard to was. Medium and three, it was like easy. Um, well I took zero one, two, three, but you can kind of change that also.

[00:11:24]Um, and so it basically, it’s asking you, was this, did you get it wrong or was it easy? Was it hard or super easy for you to remember? And then it will cut. The algorithm will shift from there. If you think it was super easy, then the algorithm lasts you much further along the road. If you thought it was kind of hard, you had to think about it.

[00:11:39] And the little kind of like, come back and ask that question again and like maybe one or two months, uh, Yeah, answering it’s like pretty easy. It’s the hard part is actually just putting in the flashcards and the commitment to doing so, like I knew about space repetition. For a while before I did spacer.

[00:11:57] Cause he’s like, Oh, I don’t want to flashcards. Right. Like, um, but then like when you’re kind of stuck in your career, you’re like, you’re like, feel like you’re spinning your wheels and you’re like, I have to change something. Like, then you kind of decide to make more of that commitment. But even then, like when I was doing it, it was still really hard in the beginning.

[00:12:11] Like sometimes just cause you add to honky doesn’t mean you’ll obviously understand all that knowledge. Like you kind of brought this up in one of your books. It was like the gang of four and you kind of like learn all the patterns from there. Just cause you put it in there doesn’t mean. It’s always immediately walkable.

[00:12:26] So like, even then it’s kind of, it’s not like an immediate, it doesn’t like control everything. I think that’s it. Sorry. It, it, it brings me to one of the thoughts that, you know, there’s two different types of knowledge, right? There’s declarative knowledge. And then there’s procedural knowledge. The declarative is where we could talk about it.

[00:12:43] Right. That’s what auntie is really testing for. Is this, is this. How do you commit a message? You’re like get commit to a sham of quote, you know, and that’s, that’s one thing, but to be at the keyboard when I type it out on the keyboard and commit it in and, and handle handle, get that’s procedural. I don’t also much like that example as much as I do, like, um, working with.

[00:13:07] Working with code, you know, where you’re actually really trying to like active record what is active record? Well, it’s good to be able to declare do you use the declarative explanation of it, but then to use active record, to know how to really, really use it? Is that, that part? And that’s where I always get a little.

[00:13:25] And in using space repetition. I want something that’s going to let me use it at a space repetition mode instead of, instead of just ask if I were a member and that’s kind of been where, where my brain, my brain sits, uh, there’s, there’s some prototype. There’s some stuff I prototyping of some I’ve shown Tyler.

[00:13:44]Um, kind of, uh, some stuff I’m working on to, to actually scan abstract, abstract syntax, trees of code to see how people are implementing things. If we, so it’s a whole different concept, but I love space you’re right. No, it doesn’t, it doesn’t help there that one’s just like straight practice, like AKI does doesn’t help with that at all.

[00:14:03] It’s basically going, Hey, if you had a really good memory, like how much faster could you do stuff? Um, but sometimes you might just do. The wrong thing faster. Right? So like, that’s like, but that’s like being honest about it. Like, you might just commit a bunch of crappy messages really quickly now. Um, so honky does not help there, but it does help with just generally it just lets you code faster and depending on where the direction you’re facing, like either that can help you or you can kind of like, just make you do more of the bad habits over and over.

[00:14:33] Right. Yeah. So I agree with you on that, but no, it’s just, it’s one of those things where I always, um, I always, you, if you’ve listened, like, I don’t know, you sound like you, you may have listened to some of the stuff we’ve talked about before. I’m always talking about, about getting the practice. And that’s what we tell my students when, when I have students, is that get your hands on the keyboard.

[00:14:54] Don’t worry so much. And that’s where being Tyler sometimes get into LA, you know, kind of lock horns together sometimes where I’m like. Well, just how much of the API do you have to remember? I think it’s like, remember enough where you’re not stuck, where you’re constantly having to like all tab, go to sack overflow and then get distracted by something else.

[00:15:14] Like I find that the internet is just hyper distracting now where you go on stack overflow and then the right hand column is like a community questions. And then the, like, down below that it’s like asking. What superhero would win in, blah, blah, blah. And it’s a completely the Twitter, right? Yeah. It was just like, you’re like, okay.

[00:15:30] I started with this question of like, how do I do something in API? And then you find yourself like reading some like Metta overflow of like some controversy. And it was like an hour later. You’re like, Oh shit. Like I haven’t done anything. And so having a lot of this knowledge is just, it just saves you a little bit from that.

[00:15:45] And just a little bit goes a long way. Cause your brain is also like when it keeps on having to Google stuff, it kind of gets a little lazy, gets a little tired. Um, I find that my flow States are so much better now. I was like, Hey, if I’m working on something that I don’t, I just don’t all tab a circle.

[00:16:00] And I think that I’ve seen other people, like if you have a good memory to begin with, then perhaps like auntie and space repetition, isn’t that useful? Um, like seeing someone with really amazing memory, it’s just like, okay, like, it wouldn’t make sense to recommend that. But I feel like for me, like I have like average or below average memory, so.

[00:16:19] Space repetition becomes super useful there. Um, and then like, I’m like easily distracted by the internet. I feel like everyone is, but like, I just, like, I’m super frustrated that like go on stack overflow and like, and I’m reading about some type of like superhero comic, right? Like on stack overflow.

[00:16:38] Yeah, no, man. I, I totally, uh, the distraction of going to the internet for things can, can torpedo a state of flow. Definitely cause that it turns into, and I think I really like it was that. No, no, no, go ahead, Jose. I love working on a train for that reason. Like you take an Amtrak train and it’s just like, the wifi is so bad.

[00:16:57]Um, but if you have a gig. If you don’t really need to use the internet, like you’re just like coding, you can get so much stuff. I’ve gotten so much work done on like airplanes and trains and it’s like weird. Right? Cause you’re like you imagine like with no internet, that would be harder, but. It’s weird.

[00:17:14] How much more productive I am there without the distracting internet. Yeah. So, so the thing is, and I want to tie it all together because you said something really important. And I think we kind of jumped on this a little bit. The example, I believe the example I gave in one of my other. Um, one of our other episodes is the idea of, I had students who, who, um, we took them on a field trip and they were asked, you know, they asked the people that we, that we went on the field trip with, or to the office we went to, Hey, what do I need to be a backend engineer here?

[00:17:43] And the, these guys that had eight weeks of experience in software development, and they’re like, you need to know solid. Right. And I’m like, And that’s the thing, right. We could put solid and inky carts. We could put all of it and they could go in and recite solid to the, uh, to the letter. But, but when it comes down right.

[00:18:03] But they don’t understand the, the, what all those words mean. And that’s, that’s where, um, I had this conversation with my dad a long time ago when I was young. And I said, man, I wish I had a photographic memory. I wish I could just flip through the book and have it all in my head. And he said that that would be absolutely useless to you.

[00:18:22] And I was like, what do you mean? I would love to have like, like he said, no, you have to actually, um, it, you wouldn’t know what that information meant. And part of that, knowing what it means is connecting it. But I really liked the fact that you brought out, it’s not just achy, it’s, it’s doing the things.

[00:18:40] And then also the Yankee is to help reduce the friction. That’s actually what I really like about what you, what you’re saying. I think there was like a lot of controversy there too. Uh, when I publish this, I kind of like, it went semi viral on hacker news and it was like, there’s a lot of visits there and people are talking about it.

[00:18:55] And like a lot of people were like, no, like memory doesn’t help, anything at all. It’s assumption, like no memory is super useful. And the answers like someone in the middle, like if you’re not actually applying it, like just cause you’ve memorized all of good syntax like that won’t help you anyway. But if you’re like, if you’re actively learning on the job and you’re just like looking for a way to go, how do I remember more than I forget?

[00:19:15]Um, and you think of it that way and how do I use it as a tool to make me a better engineer that’s super helpful, or like your, your IDE won’t make you a good programmer. Um, but it can be a tool to help you program faster and more program more effectively. But if you don’t put in that work, there’s, there’s no real answer there.

[00:19:32]Um, and like sometimes people want it, Oh, if I had to photograph memory, I could do anything. It’s like, that’s not true either. Yeah. Yeah. So that’s how I view on key and like space repetition. Um, So I think it’s interesting cause I, um, we’re both, uh, um, and you might be interested in this too, but, uh, Douglas and I are interested in cognitive science a lot.

[00:19:49] So we would like to talk a lot about learning and, and the science behind it. And they talk a lot about, um, the closer that you can get something when you do this space repetition or rather space practice, the closer that you can have be to the actual thing that you’re trying to, um, No. So like actually coding the better.

[00:20:07] So have you ever, have you ever done the, the opposite where, um, I noticed in wa um, on one of your blog posts, you actually have, like, how do you, um, how do you get like a use, like a re prototype slice or something and JavaScript, right. And you’re like, how do you, and I forgot the exact question, but have you ever actually typed out things.

[00:20:28] To your cards because you could do the procedural stuff and am by yourself view. Yeah. There’s like a few of, like, I do have like cards that are like recursion based. Cause it’s like they come up randomly in interviews, but not really in real life. Um, and it’s like, how do you like implement this type of algorithm?

[00:20:47] I’ve done that. But the tradeoff is like, when it becomes hard, when you have to like, think through really Hardy these cards, it kind of ends up being something that your brain starts to try to avoid. Um, so he’s on key is like, kind of like my brain is not at peak and I can just kind of go through these really quickly.

[00:21:04]Um, I also find that like, in regards to the memorization of it, there’s such a strong, like modality effect where like how you’re studying it, like kind of. Impacts it pretty hard where like, if I’m never using some type of like, how does a certain program work? Um, it’s not easy, easily applicable towards something else.

[00:21:21] So I, I feel like when you learn a different context, your brain like blends in much faster, right? Like if you have to input a program in go Python and Java script, like you’re going to learn that concept much better than if you only memorize, like, how do I implement it? Only in Python that’s like straight off and like have like really difficult cards within funky.

[00:21:37] Like I’m going to only memorize like that specific context and it won’t. He as procedural is kind of like Douglas pointed out. I’ve definitely tried though. Um, and I just found that it wasn’t sticking as well. And I was just like dread that specific card and I would kind of like, um, keep on like kind of getting it slightly off wrong.

[00:21:53] And at some point I was like, this is not. This is not how I really should be using honky. And I think like, um, there’s another one that love the developer, like another space infrastructure software. He kind of talks about that. Even one’s against that too, where like sometimes when people start arguing things like, Oh, this can give me like a super memory base and that doesn’t quite apply as well as people want, like an auction card should be built or specific shoes should be fast, easy for you to do, or you should be able to quickly go, Oh no, I don’t know it versus like having to spend like 15 minutes, trying to think through an algorithm.

[00:22:22]Um, Yeah. Interesting because there are, when they talk about space repetition and stuff, um, they actually say how, um, like make, uh, make it stick the book, make it stick. It talks about if, uh, if something’s the difficulty actually is counterintuitive when you do use space repetition, so people don’t do it.

[00:22:40] So it sounds like that’s exactly. And I think that’s exact thing I’ve fallen into. I’ve written hundreds of inky cards, but I’m really, really bad at. Following up on them. Like it’s, every card is a hard card. It’s like really hard to keep it up. That’s how I feel. A lot of the times I was kind of like, what?

[00:22:57] And I get, I also overanalyze I’m like, am I writing the right card? Right. Am I, am I doing this correctly? Am I do I even understand the concept correctly? And then I’m like, Analysis paralysis and just don’t make the cards or don’t reveal them

[00:23:14] though. I was going to say, I was going to add in there that, that this concept that we’re talking about is, is well known in psychology, which is that in also just in, in, um, evolutionary biology, which is things that cause us pain. We want to get away from. And so the more pain that it causes us, the, the, the, the more that we try to avoid it.

[00:23:35] And the thing that I was going to also point out is that all the research I’ve read is actually the harder it is to pull it back out and you successfully pull it out, the more ingrained it’s going to be going to the next test. So it’s actually the stuff I’ve read on space repetition. Is is that you want to get to that moment right before you forgotten it.

[00:24:00] And it you’re what you said is, right. Right. I think, I think that you don’t want it to be like, um, right. Ward piece in the box forest, please, to be sure that you’ve memorized it. Right. But it needs to be, um, it needs to be right at that point where you do kind of have to go and then it comes out where instead of it’s like, Yeah, easy.

[00:24:21] Right? I agree with you there. I think what I’m thinking is more or less how when your brain is lazy and like doesn’t want to do on key. And it remembers AKI is like this torturous task where you’re like, if every single card is like something where you have to think through and pull it out, there’s an argument that your brain is just going to like, not want to do it anymore.

[00:24:38] If you can believe that I’ll keep. So Derek Sivers kind of goes through this where he goes through his cards really quickly. And, um, his car, he feels like his cards are like reasonably. Good. Like they’re not too, too hard that way on keys, like more or less like a fun process. But if it feels like every day, you’re kind of going through a new textbook and it’s like, you have to pull these concepts out.

[00:24:58] Your brain just starts at four weeding doing Anchia don’t just go, go on Twitter, go on Facebook. And that’s what I’m avoiding of. Like, you’re white that if, if I had unlimited willpower, then that is the perfect scenario of like, just pull these like medium level onto cards and keep on like thinking through these concepts.

[00:25:16]Um, I also say this and that. I like, if you look at the medical students using on key, they are absolutely that context. Like medical students using honky is like a freak show where they all have like 4,000 cards. They all do AKI overload. They all spend like eight hours a day studying on keys. It’s like, how is that possible?

[00:25:32] Right. Like, um, so it’s like kind of crazy. I didn’t realize how crazy it was until like medical students started like emailing me from the blog posts. Cause they’re, they’re like, they’re like the real AKI space, repetition users. Those guys are heavy. Edit. And I didn’t even know as possible study eight off, stay on flashcards, but they do all the time.

[00:25:49] So it’s crazy kind of scary. Actually, they do, like you’re not supposed to do. And that like, basically everyone records don’t import other people’s decks, um, and like brute force it, but they will do that because that’s how hard medical school is. Um, so yeah. Yeah, I was, I was wondering about that as well.

[00:26:09] Cause I’ve, I’ve read that they’re not importing other people’s stacks. I don’t know if you mentioned it. I think I’ve read, um, I forgot the other guy’s name. Uh, Derek Sivers has an article and then there’s another guy, a British guy. I think, you know the YC guy. No, I don’t know if it’s bursting out.

[00:26:23] There’s there’s a few, there’s like a few prom programmers that also said like space repetition has like changed my life through actual famous burger, but not me, but like, they’re like, Hey, like they’re like space repetition is amazing. Wow. I think it’s like Michael something I’m trying to look up right now.

[00:26:46] Michael Nielson. Was it him or no, it was a, it was another guy, but that being said, going back to the principal cause, um, it’s cool to know that there’s other ones I’ve only ran across a few. Um, but I think people are going to go onto inky web. I think it’s as an inky web.net or something like that, it’s the website we’ll put, we’ll put a link to it in the show notes, but, um, they’re going to go on there and then try to pick up the JavaScript stuff.

[00:27:09] Cause I remember picking up some on Ruby before and I was like, you don’t have the con the problem is, so it’s interesting in your, in your article, I don’t disagree with you. You said inky is a learning program. And I was like, what is learning? Right. What’s the definition it’s like so large. It’s like, Oh my goodness.

[00:27:25] I don’t think. I know that you do this, but I don’t think like trying to understand programming concepts and inky is not a very good idea. You do not understand them before, like, and play with them and then write them down. It is harder that way. Right? Because otherwise that’s what you’re doing. If you’re, if you’re picking up other people’s decks, now you’re trying to parse the understanding behind.

[00:27:45] The remembering, which makes, which goes exactly to your point from before. Now this is a horrible process. Like I need to run you a textbook and like memorize this, right. So this is great. This is great. Cause this is exactly why I actually, I picked up hanky, cause someone said, Oh, go get inky. And I’m like, Oh, here’s all these decks.

[00:28:02] Can I, am I going to plug into the matrix and suddenly know Kung Fu? And then it’s like, I don’t understand it. You know, it, it doesn’t really help, but the, this, this discussion that we’re having around. No don’t use other people’s decks and make your own deck, because if you’re making your own deck, you’re trying to process that information yourself right then, and have built up the scaffolding around the information at the desk.

[00:28:27] So like when I have a lot of my action cards, it’s like, I remember why. I remember the issue that I was having and why didn’t know this answer. And then it’s much easier to kind of learn from that, the true context behind the scenes of just because you asked, like, fill like a fill in the blank type of question, won’t be helpful.

[00:28:44]Um, so like machine learning that’s happens a lot where like machine learning is so abstract and if you just fill it with abstract information occupies so hard to do, and I’ve done that like in the last couple of months where machine learning is just so much more knowledge there to now to learn, um, And when you just give it a really quick abstract, like if you just copy and paste on Wikipedia, I dread those cards so much.

[00:29:05] I keep them in there just because it is like my way of like also kind of thinking of someone throws me in a textbook and now I’m just like sitting and studying with it. Um, so I will put in concepts in there that I don’t fully understand. However, that’s not a recommended practice unless you’re like fully committed to like, Hey, I’m going to study multiple hours within on key and use textbooks.

[00:29:27] Just to learn a specific topic. So I use it like back then, so I don’t use it just as a note card system. I use it actually as like a like textbook plus no card system. Um, it’s not recommended. It’s really, it’s more like how medical students learn. Um, so that requires just an absurd time commitment at times.

[00:29:43] All right. Cause that’s sorry. Good. That’s that, that was just say that’s so interesting because what that would mean is that you’re trying to use again, that’s that’s back to what, like, if I had a photographic memory, then I could remember everything that I saw, but then that information coming into my head wouldn’t mean anything because I don’t have context around it.

[00:30:02] But the idea is, I think what you’re doing is adverting the idea of having, of having that, that knowledge come at you and then record what you want to remember later, as opposed to having concepts that you haven’t quite gotten down and you’re going to try to rope memorize it. Yeah. On the hope that later context is going to come in by the time that you kind of get there to the rope part with like memorization, you, you do reasonably learn the concept much better.

[00:30:33] Cause it’s like, you’ll just, um, like I, I won’t try to memorize something word for word I’ll like, I will kind of break down into like, Oh, foundationally, what does this mean? Right. Like what does back publication? You know what I mean? Was it trying to do, um, but those cards will take me like a few minutes and those are much harder by nature.

[00:30:48]Um, but the first time I put what is back propagation, I definitely didn’t understand that concept at all. And every single time I go back to these cars actually do learn a little bit more, especially if you’re like your day to day jobs, like working in a specific sector. Um, so like whenever you view visit a concept, if you’re visited after a few months, you do find that there’s like this other type of knowledge that you kind of connect with it.

[00:31:08]Um, so back to your intelligence basket, it’s like, how do your neurons kind of like tie in these different concepts together? Um, and it’s just a great way to kind of also remind you, like, Hey, think about the overall concept of like, what is that population? Should I like, I guess, like it’s programming.

[00:31:21] It’s like, what does encapsulation mean? Like, why is it useful? Um, and like, no one really asks you that more like dividends, like, Oh, I guess maybe for you less, but like, Because you were like a teacher, but like, for me, it’s like, yeah. Yeah. Knock interviews today where I was asking that specific question.

[00:31:38] Tell me about encapsulation of what it means to you. That’s like in interviews or like when you’re teaching someone the first time, but like some of that’s like been programming for like five to 10 years. You haven’t really asked them that you’re expected to like grow up. Then when that question kind of comes back, you’re like, Oh, like, what do I think about a calculation?

[00:31:54] Like, what are my expenses? It is like a great way to like tie into context of what you’ve learned. Well, you already thought you understood the concept, but now it’s like a different shade of it. Like when you revisit stuff, it’s just interesting how your brain will kind of bring in new concepts. Like whenever you visit a topic after six months later, there’s just a separate type of insight where you still remember the original point, but now there’s a separate insight for you to learn that concept even better.

[00:32:16] He does that for me too. That’s so interesting. You said that. Cause I just read something very similar to that. I have this book called understanding how we learn a visual guide and it’s basically a compendium of all the cognitive science. Um, that’s got like hundreds of references to all the. Articles out there, but they said the same thing they said, um, do using space repetition actually helps you to learn something more deeply.

[00:32:38] So that those that do space repetition versus just wrote, wrote repetition of, of facts. Actually, they’re actually able to apply the concepts in different scenarios versus just repeating the concept back. So it’s like, I just thought that was interesting. Cause I was like, at that backs it up with like, Cognitive science.

[00:32:57] So I thought that’s cool. I do agree. I think like people have this huge frustration against I’m keen because they think it’s only rope memorization, and it’s somehow believes that if you’re doing hockey, you will turn off your brain. You’re thinking part of your brain altogether. And you just like roll back and give these answers.

[00:33:11] And I think some of that comes from like, you can argue like, um, low lot of like, I guess like Chinese people were really known for like memorizing wrote mathematical formulas and it wasn’t helpful for them to think about the overall. Concept of it, but if you’re like in your twenties or thirties now doing it, like you’re smart enough to like, think about things, right?

[00:33:31] Like you’re not rope memorizing anymore. Like you were in high school. And so a lot of people have like frustrations against like when they think, Oh, I’ll keep just a memory trick. It’s like, no, it will make you relook at a concept. And like re think through it and like, it will help you there. Um, so yeah.

[00:33:50] Like they say neurons that, uh, neurons that fire together wire together. Right. So you’re right. If, if, um, if, if a car does kind of like start kicking off other things that’s attached to, then those, those connections become stronger as it happens. That’s really, that’s actually a really great, and one of my fears of inky myself, so you’ve actually come in here and, and, um, you know, that’s actually one of my, my arguments that, that.

[00:34:15] Not argument cause I’d never get, I’ve never gotten into a debate. I don’t use achy,

[00:34:22] but. The thing was, is that, is that it’s always about like rope memorization. Is it going to help me in programming? Um, but maybe, maybe I’m kind of wrong about that. And maybe there would be connections put together. So I’m kind of my brain’s changing a little bit right now as we’re going through this, why would I memorize something when I can Google it in two seconds?

[00:34:44] That’s a very fair point. Um, but now it’s like, okay, how often do you use, how often do you, when you Google something, if you don’t have all that off. So like, so when you think of like, when you’re first starting to program a new language and you don’t know all the syntax, you’re kind of Googling left and right.

[00:34:58] And, um, Versus if you put that somewhere in the back of your brain, like, what is the speed advantage you get from that? For me, it’s minimizing distractions. Um, when I’m in flow, it’s pretty, pretty strong now, um, where I can, like, I can reasonably program out something completely without having to like.

[00:35:14] Google that much, that much. Um, they’re not saying that I was like bragging. It’s just like, it was just many years of brute forcing and memorizing a lot of AKI shit. Right. Like, um, but it is like super helpful. I can get stuff done much. Like it is multiple times faster. Now when I don’t, I can’t actually understand why or like, just cause you’re you’re radically.

[00:35:33] Okay. Let’s say you Google 50 dates. So like before we can get a reasonable flush program out and now you only have to Google five. Reasonably like, okay, fine. That’s 45 queries for saving 45 multiplied by five seconds maximum. They should be saving less than 250 seconds. Well, that’s not true when you’re actually programming.

[00:35:52] Like I get some done in like hours less time than it should take. It’s a weird, it’s like something like there’s like this more fund programming. I don’t it’s like when you’re in that flow stage keeps you there. Um, Yeah, it’s sort of like if you program something by yourself, versus if you inherited a program that someone else wrote.

[00:36:12] And if you structurally know all the limitations of your, your own code, cause you wrote it versus like inheriting someone else’s, even if you memorize the other person’s limitations of that code or wherever they wrote, you’re never as fast with it. It’s just, it’s just impossible. I have Paul Graham talks about this too.

[00:36:25] He’s like if you had to pick between like two programmers or just one program that knows the tar, Kobe’s always pick that one program. Right. Like you, you get the speed advantage of having it all in your head. Um, and that is like just how received when you’re working on something complex. Um, yeah, assuming that I know I’m speaking very true.

[00:36:42] Right, right. Cause it’s spaghetti all over the place. What you just, yeah. What just popped in my head when you were saying that is the concept of the difference between a fast, hard drive. So maybe a fast SSD and Ram. You know, so in our head, without having to reach out to some external resource, maybe, maybe you think of the analogy of like, we’re, we’re kind of doing some access to Ram.

[00:37:08] And I want to say that I think the kind of the way our memory works, it kind of is close to that because you don’t use it. It’s kind of like shut the computer down. It goes away eventually. So that’s what achy comes at. It does with space repetition. It keeps it in your, it keeps it hot, you know, I’m ready to go.

[00:37:23] And, um, Google is, Oh yeah, go ahead. Yeah. Barbara locally is like, she has this Coursera classical learning how to learn. She kind of talks about that. It’s like you can reasonably fit, fit like four to eight things in your prefrontal cortex before. At some point it’s kind of sort of slipping and the more concepts you can kind of keep in there, like.

[00:37:41] The faster, you can do things and yeah, granted, you can always search and query from one things, but just slows you down in a weird way. Um, and she kind of talks about that, how to learn a concept. And like, if you understand, like, Hey, you can only keep this funny things in Ram essentially before to actually learn it, then.

[00:37:59] Then you understand that limitation? I don’t think I’m doing justice describing, I think Barbara Oakley’s class. Yeah, I know. So you’re talking about the ch the concept of chunking where, because I’ve taken the course as well, uh, several years ago, but this concept of chunking is you can only hold so many bits of information in your, in your, uh, in your Ram at once, right?

[00:38:21] If like, and your active memory at once, and what you have to do is take complex. Concepts and basically, um, compressed it’s basically it actually compresses, I think it actually literally compresses in your brain. It takes up less neurons. I think that’s how it works inside your brain. But chunking is literally you’re, you’re saying you’re taking this complex thing, like solid, for example, and.

[00:38:43] Eventually solid just becomes a thing that you instantly know because it’s compressed. Now. You don’t have to think about all the, all these little details. It’s kind of like if you learn, um, I don’t know if this is a great analogy, but if you learn a new language, right, like you have to think about the, um, if you know, another language do you have to think about, do you know when you first learned that the language you have to translate into it and you don’t have to do that anymore?

[00:39:05] Once you become fluent because, um, Because you actually have now integrated language in the same way. Um, this chunking just allows you to, to know, to, to not have to it, like I was talking about before it reduces cognitive load. Right? Yeah. And I was, uh, so the, the, the term for that is consolidation, right?

[00:39:24] Our brains are really good at that consolidation. Step in learning. That’s where we’ve got all this information. It gets consolidated or chunking is another, is another. Uh, where you can call it, but maybe no migraine is to be honest. So you say that you say that, and this is what I, I have to prove it to my students all the time, which is that there’s so many things that you’ll just do.

[00:39:49] You’re not going through every, every step and a really good analogy or a really good, like, just look at something that’s common to everybody. Not just programming is driving a car. This is where I explained consolidation really well. Remember the first time you ever gotten to a car? You watched people drive cars for over a decade?

[00:40:09] Probably very conscious of the fact that people were driving a car for over a decade. You get in the car and it’s the scariest thing ever. When you first get in a car and you start hitting the gas pedal and, and all this stuff. But what happens is, is that over time, As you do this, you’re consolidating down the, the thought processes of driving to the point where now you can almost drive.

[00:40:35] Actually you do. Unfortunately, most people do drive without thinking about it and they think, Oh, I’m not even thinking about it. Let’s get this, uh, All right. I’m going to do some texting while I’m, while I’m driving. Uh, you know, so, so that is, that’s actually a real way to look at consolidation. Is that go, like everyone goes through this when they get the cart, every single thing.

[00:40:54] Like I remember when I was driving around with my grandfather, I would, I would say everything I was getting ready to do almost for approval. Like, like, like tell me if I’m picking something wrong here. Yeah, I’m about to hit the left turn signal and I’m going to get over into the lane to the left and I’m checking my mirror.

[00:41:11] You know, I would actually say this stuff. And now that process has just, you know, it’s already done before I think about it. So all of that was consolidated into almost one step, one thought of get over to the left lane. And we didn’t even think through the steps anymore of doing that. That’s that skill consolidation.

[00:41:29] And you have lots of it. So that’s what that’s, what I’m saying is that, that you, you, even with the achy skill, the achy cards that you’ve got, there’s a lot of context. When you look at that achy card, there’s a lot of fakes consolidate it. That you’re. But you’ve got to be able to answer those cards. Yeah.

[00:41:47] I think it’s handled similarly, uh, Dave Ruby on rails, David Hameister is like, he kind of talks about like when you were driving, like, he basically is an interesting career, but he was, he started professional racing cars for a little bit. And it’s like, you kind of think of that knowledge. Like the first couple of times you’re driving in like.

[00:42:03] Something that goes like 150 miles per hour. Like that’s scary. Right? Like, you’re just like, what am I doing? And then, but when it gets set to instinctive moment, would you know how to like, Drive a fast car really quickly. Um, that was really fun. Like he talks about the flow state. It’s like once he gets in that car, it’s like an instant flow state.

[00:42:20] You forget about all, everything else. You forget about all your other problems or stresses and just driving, essentially a missile track. Um, yeah, so we talked a lot about flow, um, and flow flow is basically, um, Yeah, well, there’s a, I can’t even say the guy’s name. Um, yeah. Yeah. The guy who wrote, wrote checks, Messiah, I can’t remember what his name is.

[00:42:48] Yeah. Uh, anyway, he, he explains that flow is basically the state where you are. You are Joe going just beyond your, your capacity for understanding or doing something like maybe 5% you’re in this like perfect ideal area where it’s not too hard and it’s not too easy. And you kind of get lost in what you stated before, where you’re like, um, you know, do you, do you lose track of time?

[00:43:12] Right. And that’s what every, every developer. Who’s coded for a while has been there at some point. Hopefully if you haven’t, I’m sorry for you, but, um, did you notice that those flow States went up for you? Like yeah. They’re, they’re much more pronounced now. I don’t, but I also don’t know how much of that is on key versus how much of that all to his Douglas point is like procedural.

[00:43:31] Like it is in my head somewhat of like, okay, I’m gonna do this. Like now do X, Y, and Z. Mmm. I like they’re correlated, but I don’t know how much. One is doing the causation. Um, so like it’s also much more pronounced as I’ve been programmed before. Like it’s really hard when you’re first beginning and you have to like, stop Google everything, and then go back and like, um, versus if you can kind of program something from scratch without having to like Google much.

[00:43:59]Um, so yes, flow is much more pronounced now. They also have much better habits notes here. Um, so they’re quarterly, but I don’t know what. If it’s how much I can actually attribute a honky. I think it is a lot, but I do know fats. They’re like, there’s not, it’s interesting. It’s not academic programmers that I know they’re using on kids.

[00:44:16] It’s such a hard commitment to do. It’s like people that go to the gym every day, you’re like, everyone seems to talk about it, but then like, Yeah, look at it. It’s like, yeah, that’s not really true. It’s like Instagram, like people at the gym. That’s how I am. I’m like, Oh, I love honky, but I don’t really do it during the day.

[00:44:30] So I’m trying to change that. Right.

[00:44:39] so, so that’s one of the benefits. Another one that I, um, I would like to get to is to your productivity. So you mentioned something really interesting. You said. Let me see if I have it here. You said that you went from a roughly 1700 commits to 40 to 4,800 commits over a three year period. Um, it’s kind of intense.

[00:45:03] Yeah. Was that because of more time or is that because you were, do you, what do you mean. Having like the lower bound of that. It’s like my ass isn’t net Cedars. Right. Uh, I also feel like I, my particular personality is just easily distracted. Like I, you know, I’m like not really joking when I was like, I want to stack overflow and like, I’m like, why am I reading something on like some other metal overflow right now?

[00:45:30]Um, so I think that was a huge deal behind it though. Um, like just not having to glue everything in and get distracted by internet. So I think like the insurance. It’s really made to distract. Like, everything we’re talking about is like, you know, I’ve worked on this too. It’s like, how do you get engagement?

[00:45:43] Like, what is the right amount of like clicks or controversy that you can get piped into something. And then that loser user will just kinda like be on your cipher. Longer page times a minute. You’re going to rallies that like every website seeing the same thing of like, how do they distract you longer?

[00:45:59]Um, so that was like having specifics and helps you there. I also got a loaded moment. Sure. There too. Like, as you get older, you’re kind of like, okay. I don’t have unlimited time. Like when you’re, when you’re like 23 years and I’m like segment years and we’re like 25. Okay. Shit. I gotta get my act together.

[00:46:15] And then like, Um, well, as you’re getting closer to 30, you’re like, okay, I’m not going to make like Forbes 30 under 30. Like, what do I do now? Like how do I mature more? Um, so I think that’s like additional context to it too. Like maturity does help, um, for you to be more productive. Um, that’s do have like way more hacks.

[00:46:30] Like I think we’re like, we kind of definitely do read a lot of the similar. Like learning intelligence and that kind of stuff. And like a lot of it is like how to be more productive as how do you minimize distractions? Like how do you hide your phone? What are Pomodoro timers? Um, I do a lot of that stuff now.

[00:46:45] I care a lot about that actually. It’s like you segment your day. Um, I wrote a lot about also like how. Um, it was like kind of those maturing point of like, if you kind of think of yourself as like, Hey, like how do creatives work? How do like writers and song writers and musicians work? And you find that they have this like very separate team.

[00:47:01] And if you can kind of mimic that for program, you can actually get into a rhythm much faster. Um, I can’t remember the author right now, but he kind of talks a lot about like, Hey, like we’ve, um, a sentence half written. So the next day you kind of like get into that finished next day, you finish that sentence and then you were like in a good rhythm.

[00:47:18]Um, other writers just are even more. So I think there’s a lot to be said of like noticing how other writers write. Um, and that way you can kind of like use that for programming to like get better, faster, but other writers are like notorious for like those lock themselves in a hotel room. I would just keep on writing until I class, uh, the prolific ones, at least.

[00:47:34]Um, so I think there’s like something to be said that, so do you, you, do you do, do you consider this one? This one hack or super power, uh, doing space repetition, your, the, the Mo the one that’s contributed the most to suit your success, or , I think that’s probably one a of like, on like the top, like next to, for me, it was like a lot of coworking spaces, like, just like growing up and like, so like when you work from home, I just find that working home is just.

[00:48:06] For me, at least it’s like, I’m easily distracted. So like paying for a coworking space, which is not cheap. I mean, like that’s like $400 a month we’re paying for that. Just like help my career out there too. Um, whereas when I found that, like if I was going home and then trying to work from home, It just doesn’t have that same seriousness to it.

[00:48:24]Uh, and I also think there’s like another, I can’t remember his name right now. Um, there’s a book called daily rituals and she talks a lot about how creatives work is. Like, there’s this one writer who like notorious notoriously would like wake up, put on like business pads. You just hit the elevator button.

[00:48:36] And he’s like, rented out like a basement at that building. And then he just worked there. It was just like that process of like, Hey, I’m going to grow up, put on big boy pants, go to the basement and then work from there, like, like meet him productive. Um, and so for me, I guess like perhaps on Keaton space or tissue, but one D is probably like a coworking space, like have a serious place to actually just work on the side if you’re not actually at work.

[00:49:00] So, yeah. That’s great. Yeah. I definitely agree with that. That’s awesome. Jeff. I had a question that is. You know that you may, may or not have a answer to, but

[00:49:14] that’s okay. That’s okay. So we’ve talked about inky is really good at, at this idea of, of declarative knowledge, but sometimes it can help you remember some of the procedural stuff that you do. It can actually, you know, I, I realize this more now, but do you have anything that you do. Uh, is there anything intentional that you do to practice procedural knowledge?

[00:49:38] You know, so is there, do you, do you take that, do you write code for that, that, that, you know, around kind of like, I want to remember things I’m going to write some code, it’d be cure. I just curious to know. So I could a lot though, so that, like, it’s just almost the enforcement of that, but I don’t do it.

[00:50:04]Uh, I don’t think I have a good answer there outside of like, just pure coding. So like kind of hammering something procedural. Um, I don’t have anything outside of that, that isn’t just like straight up coding where like coding on a piece of paper, you know, like I’ll do that, but like not, but their whole like coding related, it’s not, nothing is like, Oh, um, Like an alternative way to practice coding without coding I’ve yet to find something like that.

[00:50:29] Well, like, like code katas, right. People actually do code katas is just to kind of like go through a procedure of maybe like a lot of code katas I’ve seen her for like the concept of TDD or something like that, where AGCO basis. That’s that’s my Kolkatta like, like, if you like, so I’ve joined a lot of startups and like every single startup has like some type of like, This is the code that will not be touched.

[00:50:52] Like this is the worst code in, like, it runs in like, leave the fuck alone. I will jump you. That guy. That’ll be like, I’m going to refactor this. I’m gonna like, put all the tests in and then like we’ll rip out piece by piece. Or if I’m feeling outrageous, I’ll just try to rip it off all at once. Depends on how tangled it is, which is always a bad idea, but I’ve done.

[00:51:08] So I think that’s like my example, like I don’t do Kolkatta is because like, Day to day. It feels like when you work in a bed, Kobe’s everything has a coat cut up by itself. Like you can generally tell, like, it’s pretty a bad Kobe’s versus like something that’s reasonably well-written. I’m not saying like, I’m a great programmer.

[00:51:25] I’d like to be, but it’s like, you can quickly tell if you eliminate 1500 lines of code and like other people can actually read the poor question, like, okay, this is probably better. Um, So, yeah, I joined a lot of, I think I learned a lot from like just separate code bases. It’s just really interesting because startups, I work with, it’s like, Oh, this code is really good.

[00:51:42] And then you see, and then you see other code bases and the Kobe’s so bad. You’re like, Oh, this is great. I just didn’t even know it. Um, I have experienced some really bad code bases and like that’s where, that’s where you learn. Unfortunately a lot from like, if you see someone put 50 hacks in, it’s just really interesting to see, like, and it makes you really think of the foundations of like, okay, what was this person trying to do?

[00:52:04] Like, what was the intention of this before you had the  and there, um, that stuff is like, I guess that’s, I don’t do coconuts, but like, that’s why I feel, that’s why I don’t do Cokato because. I was like your code a lot every day. That’s, that’s kind of the, uh, the thought behind that. I guess I could, I could definitely, I could definitely see now talking about, I do want to bring attention to something you just said.

[00:52:28] So this is, this is to all of our listeners. You said something pretty profound in that, in that, um, You’ve looked at a lot of code bases and that has taught you a lot about code. And I know this isn’t, this isn’t particularly what our, what our show’s about, but I just kind of an aside that you said something that, that, that all the code basis I’ve seen, I’ve read a lot of code.

[00:52:49] And I even had like this great code. I didn’t realize it was great code until I went to this other code. So one of the things that I encourage people to do is. Look at code and try to figure out what it’s doing. Like you can go into any open source project or, you know, there’s a ton of source code sitting out there that you don’t have to, um, you don’t have to a B you know, you can just bring up the code.

[00:53:09] How does this thing work and try to follow it? Reading code is one of the things like when I’ve, when I’ve tutored not tutored, um, I’m thinking education here when I’ve mentored juniors. It’s one of the things I see that they struggle the most at when they first come out is this idea of, of reading existing code, it kind of, and figuring out the entire code base and building that tree in their head.

[00:53:33] You said something, I’m sorry. You said something that, that kind of triggered that whole. I want, I want people to hear that you said that, that, that, that you, you know, like, About, I’ve seen all these code bases and that has taught me so much is what is basically what, what I caught from what you said.

[00:53:51] Cause you have these patterns. Um, so the first code base I learned from it was like very well done. And you have these patterns of how something is done. Um, and you’ve recently hold in high regard there too, because it’s like learning from like the first textbook you ever had. And you’d always think that first textbook is probably amazing.

[00:54:06]Um, and then you’ll see how someone else has kind of thought of similar patterns. Cause most of the web what’s most important. What you’re doing is probably web-related. Um, most of it’s probably in breast. Um, and then you can kind of see like how one is structured one way and how another person kind of a tackle this similar problem.

[00:54:21] Like most of the problems in web engineering are card related. They’re not like rocket science. Um, but even within that, like even within those constraints, there’s a lot of creativity. Um, and you can see how different people approach it and you can see what people are well. So there’s definitely stuff that I thought like, When I first made it, I was like very proud of it.

[00:54:38] Right? Like it’s almost like every coach two years ago, it was like, Oh, I was proud of it when I made it. And I looked back in two years, I’m just horrified. Um, but that same thing applies to code basis. When you, as you progress, you learn how there’s separate ways of tackling the same problem. And then you can kind of figure out a more elegant solution.

[00:54:53]Uh, and yeah, I think it’s just the reading open source stuff is like interesting. It’s harder to apply for me, it was almost like every time I switched jobs, I learned so much more because of the separate code base and the responsibility that comes with maintaining that, um, reading separate code bases, you do get like glimpses here and there of like, Oh, this is how they tackle certain problems, but you also need that seriousness to like really read it through because it’s really easy to like the easiest person to fool is yourself.

[00:55:18] You can read it, you’ll read some coding, like, Oh, I know what’s going on. Um, and then. It’s in practice and you’re like, wait, dysfunction is like maintaining States somewhere else. Completely horrified. Um, which has happened to me too. Uh, yeah, but different languages. Yeah. Oh God. Um, I didn’t know, like, people actually did that until I found a certain code base and I was like, wait, like, you know, like, it’s like almost like the de facto rule of never do this.

[00:55:39] And you just see all the things that people say never do. And it’s like all in like, A hundred lives like Jesus. Uh, but you do a lot of debug there, there too. So every single type of Kobe’s like, there’s just so much learning that you can learn from luck, just like unraveling it and like the attributing stuff there too.

[00:55:56]Um, yeah, I do a lot of tests now for that reason, it’s just when you were factored those types of like, spaghetti’s, you just need tests, test cases like through and through a reason. Um, so do you write, do you write test? Are you running the manually or what are you doing? Yeah, I read a lot of tests and I do have like some reasonable automation, but it keeps on running them repeatedly.

[00:56:15]Um, and like we do, I like we’ll set up like full circle CIS and like, um, just automatic deployments, just because I think like, everything you try to do is like minimize. I’m trying to minimize my lazy days. So like I’m a lazy day. I’m like, yo, this is too hard to deploy. I don’t want to do this. Right. So if you can automate all those on like reasonably good days, then on your lazy day, you’re still like, okay, you’re willing to do like some productive out of it.

[00:56:41] So I do think a lot about that. It’s like, okay, how do I automate this? So when I am lazy, which is inevitable, it won’t be too hard for me to like cross that catalyst to actually get something done. Um, Yeah. There’s like so many amazing vendors now there too. Like I remember like when I first started programming, like, um, automated testing, wasn’t that big yet and web programs, right?

[00:57:00] Like if we’re totally Google level, yet they, they were doing that years ago, but like most web startups, like. The testing was the customers. Right. Customers complain like, there we go. That’s broken. I mean, honestly, that’s probably still like most of the startups now, but, um, but now like you have like really good, like SAS providers that do this for you.

[00:57:16] Like, you can like set up in a config file and they’ll just like start running tests. Um, and it just. Then they’ll alert you when your test fails. And I think that’s super helpful. Um, that’s not something like when you’re a software engineer you really think about, but that’s something that’s super useful for the team productivity, but like, cause it’s not, everything’s in the context of just yourself.

[00:57:34] Like how do you accelerate the team from like dealing with the same problems? Cause we had a problem where a lot of engineers were like break tests and they would just never run tests and you never know they failed, but then it’s just like, well, what is the point of doing all of this stuff? It’s you’re failing.

[00:57:46]Um, and yeah, so I think, like I just talked about like infrastructure that’s like always super helpful there too. I don’t know. Even know if I answered your question there, to be honest. No. Yeah, you did. I think, uh, I don’t know if you answered the, um, I guess I was kind of more, are you doing an integration test or unit test or it’s like you didn’t and integration ones are harder, like full to full integration.

[00:58:10] Wants to just, if, especially if you’re doing a lot of like, like if you have to get the front end testing in there, most of my tests are probably more unit based. Um, we will do like some certain ones where it’s just like more unit testing, the whole thing, but like, those always like fail when you just like.

[00:58:24] Somehow for one way or the front end, doesn’t talk to the backend correctly. Um, so it’s like trying to maintain that. It’s like building out these silos where you’re like, okay, where are the areas where it’s going to break? Um, but because most of the stuff we do is like, well, most of the stuff I do is like via an API.

[00:58:37] Now it does minimize, um, it does help that your unit test is much more comprehensive as result. Like when everything’s in API, you don’t have to worry about the front end as much. Um, and the front end stuff. Is easy to break because people changing stuff all the time, front end front has just like a little bit more fickle by nature.

[00:58:53] At least from my experience. Um, I’m trying to not piss off any front engineers here. Like I know like pythons with a little bit more like, okay, like everyone uses these types of testing methods and that’s it. Whereas like front end frameworks still kind of changing a bit. It’s not as rapid as like three years ago, but still.

[00:59:11] Changing quite frequently. And so like, you’ll spend all this time integrating some test suite and then you’re like, okay, we’re, everyone’s using something else now. Right. You’re like, Jesus. And if you’ve changed the framework, then like all those things are worthless again. Um, I have no good answer as to how do you maintain strong front end testing?

[00:59:28] Yeah. Um, I’ve tried Cyprus. That, that seems pretty cool, but there’s always nothing. There’s no silver bullets out there, so yeah. Yeah. Well, it just breaks through recent recently it might work today and then tomorrow MPM changes something and just the test fail and you’re like, is it MPM? Is it some packaged dependency?

[00:59:45] It’s so much harder for on the front end side. Yeah. I don’t really write as many tests on the front end. I mean, I go shamed in that, but it also. Like I don’t, I don’t, I should, but every single time I try to block something. It’s always been like independency health JavaScript again. I’m just like, ah, fuck.

[01:00:06] Yeah. So, yeah. Right. So one question we’d like to ask everyone is what’s a question we should have asked you that we, we haven’t so far, I thought you guys are gonna ask, like what makes someone a senior dev. I was like, kind of worried about that question. Cause I was like, I don’t really know. Like I think the podcast is like junior to senior and I was like, I was like, okay.

[01:00:33] It’s like hard because if someone says they’re senior at like programming, it’s like, I’m like, are they really like, cause I feel like I’m good, but I don’t know what senior actually means. Right. Like, okay. Cause the sport, the title is thrown around so quickly. It’s like if you’ve worked X amount of years, like people just give you that title, but.

[01:00:53] Like, I mean, like when I think of senior, it’s like, it’s like, the person is pretty good, but I still can’t actually definitively say like, what is the benchmark of like, Oh, you can do this. And now you’re quote, quote unquote senior. Mmm. Yeah. So, okay. I was thinking about it. I was like the best answer I could think of.

[01:01:09] It was like someone that manages technical resources the most effectively. Or it’s just really effective. Cause like I was like, do you call CTO a senior senior engineer because they don’t code anymore, but they are technically managing technical resources. I think it was like just also hard to decide between.

[01:01:34] When does someone go from like mid level to like, quote unquote senior? And that’s not like three years at a startup jelly, the criteria it’s like three years of startup, boom. You’re given a title, right. Engineers. Like you just like, eh, I don’t feel like that person knows whatever they’re talking about.

[01:01:51] It’s also like the realm of what they’re talking about. They don’t feel like that person knows that concept that well, like I’ve met a lot of senior Python engineers and I’m just like, Not really certain that I would describe that I’m so comfortable that person implementing some type of program from scratch.

[01:02:06]Um, and it’s also hard because like, I’m like, I feel like I’m reasonably good at certain programming things, but I’m like, I would never call myself a senior front end engineer. Like, I’m just like, I’m not right. So, uh, I think that was like what I was like, kind of thinking through my head. I had no good answer there either.

[01:02:21] Like, I guess what do you guys, what do you guys call it? Like senior engineer? Like how do you differentiate someone from. Essentially mid-level to senior. So I can, I can, uh, start and, and kind of, we can throw this around a little bit, but the, the idea of a senior developer. So the idea of a senior, like, I like to think of the journey, right?

[01:02:42] The journeymen, uh, You know, you start off as an apprentice and then you get a little bit better and suddenly at some point you become really good because you’ve done this thing over and over and over again, and you’re really good at it. Um, or you just like doing it. And, and so there are things that we know.

[01:02:58] Right. And I, I still think even, like you said, eight years, you’ve been, you’ve been ready to code for eight years now that I, that I. Okay, good. I’m I remembered had it. It’s like my Nike card. Uh, um, so, so eight years, I firmly believe that you have a lot of things you don’t realize you have, like, you might respond to something.

[01:03:19] And this is what I found out with myself too. Someone will come to you and they’ll say three words about we’re going to do this thing and you’re going to go. Um, okay. Yes. We’re going to do this thing, but have you thought about this, this, this, this, this, and this and this other thing too, because these are the other things you have to think of because I’ve been through this so many times that if you don’t know, right.

[01:03:41] Well don’t Oh man, I just, uh, I have a story about that, but I will stories about microservices. Yes. So. We’ll call it the 146 repo company. So I took over a company and they had 146 get repose in there. The organization, it was 10 customers, right? When you have more reposting customers, generally a bad sign.

[01:04:09] That’s great. I love that as a measure measure, but, but that’s, that’s the thing though, is that we could sit here as, as people that have done this. And for me, it’s actually really scary sometimes when someone says. They have the one sentence of, I want to do this thing and they say it in one sentence and I can look at them and go, okay, I’ve already designed the tables I’ve already, you know, and it’s all in my head.

[01:04:32] But have you thought about this, this and this, this yet? No, what are you gonna do about these things? And I’m like, I don’t know. And then sometimes I can get people to stop telling me about their idea because of the fact that I’m like, have you thought about all these things about your idea yet? And would you do come back to me and let’s talk, you know, that’s, that’s, that’s senior, that’s coming in and going, there’s all these, I been kicked in the teeth so many times through my career over, over wrong decisions.

[01:04:57] They’re all in there. So it says something in all those wrong paths. I went down all come out at once and you start asking questions based on that. That’s that to me is, is the senior developer. When you could kind of, um, when the project itself kind of Cubs comes out in your head, when someone says something and I’ve had.

[01:05:17] So very light times where that has happened to me, where I sit there and someone gives me the one sentence and I’m like, Oh, I just thought about the 15 systems that you’re going to have to connect to, to make that work. And are you sure you want, you know, I’m happy, you know, I like money, so I will take your money and do all this.

[01:05:35] But have you thought about all these things before we go down the path and, uh, uh, That to me is when you start becoming more senior, but of course I have held that CTO position that you’re talking about. So that’s, I do have a little bit more, I’ve looked at things that way and, but I really like coding, right.

[01:05:58] Like seniors held our high regard, but I would never compare myself against like, it’s my thing is actually really good. If I was coming up with solutions like John Carmack, I’d be like, I’m a junior developer at him. Cause it’s like, seniors, just like this broad term that like, what does that mean? Um, I guess that applies in almost every area of expertise though, right?

[01:06:16] Like, because there’s plenty of people that like, Oh, you’re a senior financial analyst. It’s like, what does that mean? Like, it’s just like the title that the job is given to you. Um, or the corporate company gives you. Right. I feel like junior is hard. I feel like junior is always such a mean term though.

[01:06:31] Like junior in my head. It’s like, no, I was like, Oh, you’re you suck? Right. Like intern. And it’s like, well, I feel like that titles sort of tarnish to it. Um, I dunno. I mean, like maybe we’ll call them the apprentice, the apprentice developer. I mean, I really liked, I actually really liked that system. Right.

[01:06:46] So you, you come in under your mentor and you’re the apprentice. And then, and then, you know, I kinda, I kinda liked that a little bit, um, instead of calling them a junior or, you know, um, I guess at other level, you, what, what you could call, call someone who was a junior entry level. Like, they just came into the field that says what they are without using the term junior.

[01:07:08] Hey junior, you know, I actually, my, I am a junior. I also might feel like that’s like a way that corporate just underpays them. Well under pasty, relative, but I guess like underpaid some relative to other developers. Cause if you give the junior title, it’s like, Oh, here’s your title. Now we can like, keep you there for two years.

[01:07:27] There’s like, if you join another place, they’ll just call you.

[01:07:32] I’ve been, I’ve been a developer too before all of us, right? Yeah. I think it’s great. What were you thinking, Tyler? I think it’s hard because I’m like, I’ve heard it said before. You could be a, you could be like. Some, I feel like some jobs, you could be just a developer and an, and those, the roles you’re expected to keep it at that job might be an architect, like an architect, the implements at another job.

[01:08:06] Right. So it’s like, um, But I think it’s a really good question. I think it depends on, I think it goes back to what you were saying. Like a lot of, a lot of enterprise companies might look at as a seniority thing. Like you’ve been here so long, so it’s like you move through senior and then, you know, you eventually move up to, you know, principal or whatever, if you’re a big enough company like Microsoft, but I tend to agree with the, like, you can implement most things.

[01:08:32] I think. In my mind developers full stack developer. Cause that’s what I am. Right. So that’s what I consider myself to be. But that’s a loaded term in and of itself. I don’t feel like, yeah. I feel like full threes. I don’t feel like full stack is true. Mostly it’s too hard. It’s like now it’s like the stuff is levels of distractions to know all of it.

[01:08:50] It’s like. Right, but, but you can, you can, you can implement an entire system, right? If you can implement entire website, I think you’re a full stack developer. You’re not an expert at everything, but it’s more of a Jack of all trades. You might be heavier on the back end. You might get over on the front end.

[01:09:07] Is it really kind of, you have like. Like I’m ashamed of my front end. I can implement it, but like, I’m shame full-stack ever, it’s like, Oh, well I can do it. But I’m just like, Oh, I made that. It’s like an embarrassment just imposter sin. Because you said that once before, you’re like, Hey, don’t compare yourself to other people.

[01:09:29] Right, because you have to really just keep on improving. I think that’s kind of what imposter syndrome can be, is like, you’re comparing yourself to the people who are a lot better than you, but when you’re not, and it’s funny, cause we do this, um, we’ll, we’ll compare ourselves, our weaknesses to other people’s strengths and then we’ll do vice versa sometimes as well.

[01:09:47] Our shrinks, other regions, other people’s weaknesses when we want to try not to, but it’s still hard because you have this idea of like what it should look like. You have this idea of like. How fast the API should respond. And inevitably it’s like expectations, like almost too high. And you’re like kind of strive for tardy until it gets here.

[01:10:06] It’s like always feels like an embarrassment. Um, and then in two years you hit the code, no matter what. So yeah, I think so. I mean, I think like software engineer is like, great. If you, if you do enjoy it, but if you don’t enjoy it, it can definitely be hell. Cause there’s just like the learning really doesn’t stop.

[01:10:25] There’s always stuff changing. Um, like when you look at front end style, like thankfully friends, like kind of stabilized a couple of years ago, there was just like, you gotta pick between 16 frameworks. They’re all kind of going for it. Now it’s down probably between two. So it’s like easier to make a decision.

[01:10:39] But like, I remember like when I was trying to decide what to use rap react and something else, it was just like, there’s so many of the options.

[01:10:48] It just never ends now. Thankfully everything’s like, Closer to react and view like between most people make new decisions, but it’s like weird because most of the web is actually still angular. Like most enterprise like went on angular one and like, they’re not gonna do it for you right. At that point.

[01:11:03] And so it was like, it really interesting if like, when I think of all the technology, I think of everything I’m reading on hacker news, but like, that’s like a small pigeon of like what most the web is doing. Most of the web is not doing this like complex stuff. Right. Um, and like when they picked it, they picked on that, that Kobe’s, it’s gone to shit and that’s what it, yeah.

[01:11:23] So I was, I was just thinking that, like, it was interesting about our, our, you know, the, the comparison, right. I don’t compare myself to John Carmack because he does have projects. He did that, that make him really good at the projects that John Carmack does. But, you know, I don’t know how I can do anything.

[01:11:44] Doris does it, he doesn’t write code code, writes him. It’s. I mean, I kind of put John Carmack in that circle, right? Like, like if you read his bio, it’s just insane. How productive, um, it’s like, he’s working with like 50 engineers and he still wrote to do some of that code base by himself. It’s like, Holy shit.

[01:12:02] Like, I think sometimes it’s like, there’s this huge controversy, if will say like there’s 10 X engineers exist and people go, no, I’m like, I’m like John Carmack is a living example of like that a hundred percent exist. Like he’s probably one of like single digits, but like. There’s this mythical unicorn and it is him.

[01:12:19]Um, so no man, that’s good stuff. And so the way I was gonna say is that I like what you said, don’t compare yourself to others. And, and so, you know, the interesting thing about that, that, you know, we talking about senior level developers here. Right. I really think it does come down to, um, Being able to look at projects.

[01:12:37] I mean, to me, it does right. Being able to look at projects, have you seen projects like this? Have you implemented projects like this? Have you, do you know what could go wrong before you get started on those projects so that you can not go down those same, same paths that when I I’ve had, I’ve had so many times where I have this friend that he basically calls me Douglas, I’ve done that before Hirsch.

[01:13:00] Because almost everything he’s come to me. I’m like, I did something like that. Well, this is, these are things you need to think about, right? That, that piece of that, like, I’m not telling him what to do. I’m just saying like, Like I’ve seen what you’re trying to do in concept. I’ve tried to do these things.

[01:13:15] Here are the things that you need to think about. Let me know how it goes, you know, but usually he’ll come back and go, man. You know, that was, that was really cool that you, you know, so it’s, it’s kinda stuff like that. I think that you start getting that, that when you can start telling the future. On on projects because you’ve seen so many of them, but here’s, here’s the thing I don’t want to, I don’t want to take up too much more of your time.

[01:13:39] I realize it’s getting, it’s getting late. So this is great. I love this conversation. I could do it for another two hours, but my wife might actually start kicking might actually bring the kids in here to start yelling in the background while we’re. Yeah. Yeah. Well, you’re the first person who’s ever told me that.

[01:13:55] So I’m wondering if everyone else is.  I just heard it, right. That was the first time that glassware serendipitous. But if, um, uh, how else? So, so basically, uh, tell us how people who listened to the show. If you can get, could get to your content where you find you at. Yeah, I do have a blog. Um, I haven’t written anything for the last six months, but that’s just because I’ve been working on like, I’m doing these really large blog posts, um, which I’m about to publish, but my site is centered in, um, dot IO.

[01:14:26] And then you can just X the blog by, um, sounded good, not.io, backslash blog. Um, uh, aside from that, you can find me on Twitter. My Twitter handles at chicory S H E K K U R Y. And then I’m also available via email by Jeff shack@gmail.com. Um, but yeah, this has been great. Thanks guys. Really appreciate this.

[01:14:43] Thank you so much for coming on here and, uh, maybe some point in the future. We’ll talk again. Thank you so much, Jeff. Thanks, Jeff. That was great. Thanks guys. Bye.

Junior To Senior Dev: Episode 5 – The Number One Reason We are Hired As Developers

What We Discuss:

– Creating Software the Business Doesn’t Want

– How to Focus on What Your Boss Cares About

– Technical Debt

– What is a Business Domain?

– Company Culture

– Conway’s Law

– Question the Interviewers






Hi, and welcome to another episode of the junior to senior developer podcast. I’m Douglas Hirsch, and I’m Tyler Lemke. And let’s get this show on the road. So Doug, what’s up, man. This is, uh, you know, we’ve had a, kind of a. Rocky start to, to a recording, but we’re getting, I think we’re getting the flow of things.

[00:00:23] I think we’re, we’ve had some great episodes out so far. So I think that we picked a topic today, I think is very pertinent to understand. Um, I’ve worded it in a different way than you have. Um, my, my, my take on it is like, what’s the most, what’s your, what’s your highest responsibility as a software developer, right?

[00:00:41] Or what is, um, what’s the thing you should be most concerned about? Um, but you put it in a different way. What was your, what was the way that you put up? Well, I tried to put it in a way that that really conveys it, but in a, in a kind of tongue and cheek kind of way, a little bit, but the business is your business.

[00:01:01] Is the way I put it, maybe the inflection was wrong, but what I’m trying to say is the business that you work for, how they’re doing, how the code you’re writing, uh, affects them is your business. And that’s a very real important principle. I think, to keep in mind when you’re writing code or you go to work as a developer, that something you’re doing.

[00:01:29] Has the ability to affect the company that you work for? That reminds me of the agile manifesto, right? What’s the,

[00:01:42] what’s the site it’s like from 2001 or whatever. Um, working software over comprehensive documentation. Um, individuals and interactions over processes and tools that kind of, that kind of reminds me of that same, um, in that same, uh, thing that if you don’t have software that actually, um, customer collaboration over contract negotiation, right.

[00:02:03] And I think it might fit there inside there is where if you don’t have software that actually fits the user’s needs, then you don’t have a job anymore. Right. Like if you don’t have a software that fits the user’s needs and this, we see this with startups, right? What’s the most important thing in the startup world.

[00:02:22] It might be pivoting if you can’t actually fit to a user’s needs, you’re going, unless you have a huge bunch of UVA, unless you have a ton of VC money you’re going to disappear. Right. You have to have a, you have to have an idea that, um, or you have to be trying to solve a problem that a lot of people are having a problem with.

[00:02:41] In order for your startup to work, there has to be like a, a problem and a value add that your pitcher, you know, you’re, you’re kind of helping someone through this problem that they’re, that they’re having. And, um, you know, I’ve worked at a couple of startups myself, and I kind of get the idea. And even if you have this really great product, um, If you have this really great product, the idea that people are just going to see that get the fact that you’re really helping them fix the problem.

[00:03:10] Is it a hundred percent guaranteed? I’ve seen some really cool startups that I thought really helped solve problems, but no one cared.

[00:03:22] right. So that’s proving, that’s kind of proving the, um, The, the, the proving the market, right? Kind of a, the fail fast mentality, or, um, lean startup where you’re proving that there’s three proving. There’s actually a need out there. I think that’s really interesting. Cause I think it’s so easy as a developer to go look, I got this really cool idea.

[00:03:41] I’m going to go build this little thing. Right. And the company, the business might not need it or want it. Right. But you’re like, you guys need this. And I think I’ve had that problem before, where I focused my optically on something that’s very minuscule of a problem versus solving, um, you know, a macro problem that exists within the business and that can really hurt, um, how you’re perceived as a developer.

[00:04:06] If you’re, if you’re focusing on the wrong solving the wrong problems with software. And I, I actually I’ve thought about this a little bit. I’ve had a couple of incidents happen to me in my career. And one that I really remember very vividly. Yeah. About, about the idea of wanting to create software, but the business not wanting that software is actually at one of my, one of my biggest enterprise jobs that I ever had.

[00:04:38] One of the largest companies I worked for, they, they, their portal infrastructure was running on classic ASP. And I’m like, no one wants to work on classic ASP. I mean, why would, why, why are we still on this? Microsoft’s been threatening to end support for this and, and why are we, why are we actually doing this?

[00:05:04] Why don’t we cut a push this portal infrastructure into the 21st century? You know, cause classic ASP, I seem to remember, I might be a little wrong. I seem to remember that came around in, in like maybe the late nineties as you know, so like 96 or something like that, you know, something like that. And cause I mean, asp.net was.

[00:05:31] 2001, 2002 timeframe, somewhere around there. So, you know, let’s bring it into this century. I kind of was my, was my thought and I had meetings with, with other developers and people higher up try to pitch this and they’re all like, but this other thing works and I’m like, yeah, but it sucks. It’s terrible to work on.

[00:05:58] Like I, you know, and they’re like, well, you just need to learn how it works. I’m like, okay. But that’s so there’s, there’s this balancing act. And this is something that I really had to deal with.

[00:06:14] Yeah. Something I don’t really think I’ve talked a lot about on the show, but my father was a software developer and part of his exit from the field was that he kind of went into obsolescence a little bit. And so there’s a lot, there was a lot of, if I saw things going in a certain direction and I could not get, you know, I needed to get experience with it in a company, because I learned that that was how you convinced other people that you had experienced was that you actually used it in your job.

[00:06:43] And, um, You know, that was kind of maybe my own limited, a limited perspective at the time. There’s other ways to do that. But I mean the best way to convince someone that you have experienced to say, I use this, or I spearheaded even implementing this thing. And, um, and so that was kind of, maybe my motivator was that I didn’t want to put on my resume that I had classic ASP experience.

[00:07:06] I wanted to put on my resume that, that. I brought this company out of using classic ASP into using all.net in their portal infrastructure. And I spearheaded and led that, that, um, that project. And so there was a little bit of self serving, uh, self-serving motivation in that, but. The thing is, is that what I didn’t think about in the reason why I lost that battle was that it didn’t actually help the business at all.

[00:07:38] Like there were a bunch of developers there. People, they, the company I worked for had no problem getting new developers to come in the door. It wasn’t like they were fighting to get people to come in. If you got with that company, uh, it was pretty good to have it on your resume. And, and so having classic ASP on there was just an annoyance for me, but it didn’t hurt the business.

[00:08:03] In fact, In my maturity being as far down the road as I am from that, that was probably about, Oh, I’m trying to think about the timeframe here. It’s 2020 and that timeframe would have been actually that timeframe would have been around the 2010, 2011 timeframe that I was having this debate. And so there’s been a lot of years.

[00:08:26] I’ve had to sit and think about that. I’ve gotten to sit and think about this. And when I look back on it, the right decision. Was probably just to stay with the technology that we had because it wasn’t going anywhere. I mean, they had just released a new version. I think what we were having this conversation, a new version of the operating system had just been released and they put the DLL in there to support ASP classic ASP.

[00:08:52] And that meant that it had at least 10 more years of life to it. Like if it was, if it was part of the operating system, it was going to be supported for at least 10 more years. So purely the, the conversation was where I was thinking about my personal, um, my personal status as someone who writes code, I was not thinking about the business and the business kindly came in and said, yo, wait a minute.

[00:09:16] This is. I had some developers on board with me that thought it was a good idea to get us off of classic ASP. But when it all came down to it, the business itself, the people who had been around longer had said, no, it really isn’t a good idea to do this. And I could not get, I couldn’t get past a certain level of support and it never went anywhere.

[00:09:36] But like I said before, the reason why I was talking about this is that I was trying to push something that clearly didn’t help anyone. I was just trying to push it for the sake of getting us away from what I considered an old, outdated technology that we needed to get away from. And that was, that was probably not the best thing that I ever did.

[00:09:59] And I look back on that and I kind of, I wish that I had been a little bit more mature when I was 10 years younger than I am now. But you learn things as you get older and you learn how to do, you know, you learn that there are reasons why things are the way that they are. Mmm. It’s not the only time I’ve ever seen something like, like what I’m trying to talk about, come up.

[00:10:18] But the, the main, that that’s my main experience. I tried to push something and it just wasn’t the business didn’t agree with me that it was needed.

[00:10:30] I think that’s an interesting, interesting proposition because there’s something to be said for being on the next wave of technology. Um, at the right time, but were you, was the portal something that was going to live for, like, you know, you could really unpack this right. From a business perspective, how long was the portal going to live for?

[00:10:52] Was it like a security concern? Um, You know, I know ASP had, it’s had its problems with security. Um, at least in its, when it was first, that was like the wild West. Um, I heard from someone. Yeah. So, you know, you could. So there’s, there’s definitely concerns. You probably could have brought up, but you’re saying, you’re saying you didn’t even approach it that way, um, from like a technical debt aspect or anything like that, you were just saying, I don’t want to work with this old technology, so you weren’t able to get buy in from the business.

[00:11:26] And that’s not how I sold it though. I did try to actually sell it as, Hey, it’s a data technology. Microsoft could say they’re going to drop support for it at any time. Of course the argument was, well, it just got packed into the last operating system. We have at least 10 years, you know, that, that was the first thing that came back from that.

[00:11:43] And the other part of it too, was that it doesn’t really support. Um, You know, it doesn’t really have good, supported it for good, for good programming techniques in PA you know, patterns and how we do things and stuff like that. It’s a, at that point and, you know, I tried to make all those points, but my motivations, that was the problem I wasn’t thinking about.

[00:12:06] I wasn’t actually thinking about how to save the company money or, you know, is this going to actually save them money? And the way that a company thinks about things is if we, and this is what this is the most, this may be the most important thing. When a company says, let’s go do a project, they’re assigning a budget.

[00:12:25] You cost money every day, you work on something they’re assigning that money that they’re spending on you to this one project and not another project. And so there’s an investment from the company that you are working for. That they’re hoping that when they have you work on this project, that there will be some sort of return.

[00:12:46] Now, if that’s a more stable system, if there’s problems with the system and it goes down a lot and they’re like, Hey Tyler, the system’s crashing a lot. Go fix it. And you know, they were having like, like a hundred crashes a day and Tyler gets in there and he’s a superstar and fixes it. And there’s like maybe one or two crashes a day.

[00:13:06] And. You know, or none even better, right. Let’s just say, it’s the perfect, like Tyler’s a rockstar and he fixes everything and there’s no crashes at all. And that means that there’s no slowdowns and the company can produce, um, you know, the company they’ll can process orders for, you know, a thousand more widgets a day, because then they, they could before, because there’s no friction anymore.

[00:13:30] That is. That’s a way of saying that, that, that endeavor brought us something. There was a good reason. Tyler took off from his other project that he was working on to stop what he was doing to go fix this. And that’s the kind of thing that I, I really wish I learned earlier on, but I didn’t really even realize I just went to work everyday because I liked to code and I wanted to make things and people ask me to make things that I really never even thought about.

[00:13:57] Am I making something that is going to help the business or am I just on a fool’s errand and I’m just making stuff to make stuff. And I wish I had thought more about the business earlier in my career. That’s why we’re talking about this right now. Right? So I think actually, sorry, go ahead. I was gonna say that I had something come up recently that I saw on the internet that made me think about this concept, but Tyler, go ahead.

[00:14:26] So there’s a sheath if different things there. I think, I think one, one of the, one of the paths we can go down as the importance of understanding the domain, as well as eliciting good requirements from the users. Um, another one is, um, Something that I’ve struggled with is getting so myopic on the, the problems I have as a developer and focusing on.

[00:14:48] Okay. Like, Oh, I don’t like, like, for example, I, I really dislike when, um, something doesn’t build correctly, right. When there’s, when there’s, when you repeat the same mistakes over and over again, like I’m prone to do. I want to fix that with automation in some way. Right. So automating a builder or putting in good documentation and things like that.

[00:15:10] Those things can tend, um, you know, documentation is not typically a strong suit of most developers. Um, and I tend to lean more into documentation because my personality, I like for things to be consistent. I like for things to be understood and to look at old mistakes, not repeat them. Uh, so my question is, um, before we get into the, maybe the domain stuff or whatever, Sorry, do you want it to go off on too?

[00:15:33]Um, how, how can I, as the developer, um, kind of think at a high, higher level and not get so myopic on the day to day struggles of being a developer, but focusing more on my, on my. My company’s needs, because if you don’t, if you don’t focus on what your boss cares about or what their boss cares about, um, you might not last long at a company.

[00:16:01] And so how did you, how do you do that Douglas?

[00:16:08] So the question that you’re asking is, is how do we know what our boss really cares about? Is that, is that kind of the idea? Um, well assuming that your boss cares about. Right. Assuming that your boss is competent and cares about the business and cares about, um, making, making a profit. Right. Because if we don’t make a profit, we don’t have jobs anymore.

[00:16:29]Um, unless we’re, you know, in the government or something, right. It’s like where you don’t need it worried as much go there. You don’t want to go down, but I’m saying, um, Assuming that you’re, you’re a normal business and you need to make a profit, right? You’re not a nonprofit who’s funded by someone else.

[00:16:43] So your outcomes aren’t weighing on that. Um, and your, and your boss has to, uh, Your boss is worried about that. How can you, how can you pivot to where you are producing what your boss wants versus being so getting so into, into the day to day of your own job and trying to make your own job easier? Does that make sense at all?

[00:17:06] Cause I, I, I tend to do that. I’ll be like, okay, I want to focus, fix the stuff that I care about, and that might not be the same thing my boss cares about. And, um, And that can put you in a precarious situation if you’re not producing what your boss wants. Right. So most of the time, you know, and I I’ve.

[00:17:26] I’ve been in and out of development a little bit. This is an odd thing to think about, right. I, I went and taught for about eight months, a couple of years ago, and now I’ve been teaching now for about six months. So I’ve had a couple of breaks in development and I’ve had a different, I’ve had some different things come up where my concerns kind of transcend it development a little bit.

[00:17:47] That’s a, that’s probably a topic, an interesting topic for a show. It may even be where this topics coming from. Um, But how to know. Well, there’s a really good way to know, which is typically in most groups that I’ve worked in. Um, we, we have. You know, there’s some sort of planning going on. There’s some sort of project that you’re on.

[00:18:11] Now, let me say this. Those are good ways. Those are good signposts. If, if you are, if you’ve been pulled in a project, you know, most of the time, we’re not just sitting around doing nothing, either we’re sitting on a project or there’s a queue of bugs that we need to go fix. So if you’re doing some maintenance, some, you know that there’s always something that is going on.

[00:18:32] The questions are different depending on where you are. If you’re working on a project, then again, that is where some people have said that we think that if we can make our program, do X, Y, Z, that is going to be better for the business. Can we get a group of developers to go do this? So that’s important if you’re on a project, that’s probably the most important thing.

[00:18:57] The, uh, the other piece to this. Is that if now if you’re fixing bugs, if you’re a, you’re doing like a break fix kind of thing, or you’re the NC, this is where it gets a little, a little trickier. And this is kind of where I think the topic came up that, that alluded to this show in the first place. Is that if you do have something that comes up and you find, Oh, there’s this weird bug that occurs.

[00:19:21]Um, I think the example that I had seen in this big, a little too close to the, to the incident, I don’t want to call it out directly, but you know, if you happen to have a system that requires an image, uh, Mike, let’s say you have an eCommerce system. And somehow it’s an interesting state where unless that, unless the image of the product is available, orders are not processed.

[00:19:45] That sounds very strange to me. Right? I’ve I’ve worked with a lot of e-commerce usually you get an order, ed, you want to get that thing shipped and get it out the door. Cause someone has given you money. There’s a possibility that people take their money back. If you don’t get their product shipped, that’s the thing, right?

[00:20:01] This is the business case, right. You’re sitting here and it’s not just, what do I do about this error? Do I log the error or do you know, don’t think about just that, think about the whole ramification to the company that you’re working for, um, as to, as to whether or not, um, as to whether or not you are, um, A change that you see a bug that you see something that’s going on.

[00:20:26] Is there something else that this causes not like, Oh, I need to figure out how to log the error. It’s maybe I need to ask. I just noticed that the system is not going to send a product. If an image is missing. I would actually, at this point in my career, I would stop everything I was doing for the moment, because I was asked to go fix like this locking problem, but I would like, wait a minute.

[00:20:49]Um, why did we not ship something? If there’s no image? Why do we not process orders for something? If there’s no image, that would be my first question. And then, you know, maybe there’s a reason, so I don’t go, I wouldn’t go in there. Guns blazing. Like this is the stupidest thing I ever heard. Why are we doing this?

[00:21:07] This is not the way it should ever be. This is e-commerce. People are gonna think we’re crazy. Um, there may be a reason there may actually be a business reason, but then based on that business reason, if there is one and it has to stay that way then yeah. If you want your goal as a developer is to help the business keep moving as fast as possible, especially if you’re doing some kind of, um, you see some kind of bug or something going on or something weird going on.

[00:21:35]Um, the, the whole point of the business is to get the product. Out the door as fast as possible to the customer. And if something is causing friction to that, that’s the question, right? And this is, does come down to understanding the domain that you’re in. Right. But if something is causing a slow down in order fulfillment and you work for an eCommerce business, Then there needs to be a conversation about that.

[00:22:03] Not a long one, no guns blazing. Just I noticed this and why and all right, here’s a proposed solution to get the problem fixed the fastest. We’ll send an email to the person, responsible for the product to get an image in there and try to come up with some way that as soon as an image is placed, that we reprocessed the, we try to kick the order process off.

[00:22:22] As soon as it image, you know, there’s, there’s this, there’s these questions and there’s these proposed solutions you can come up with to fix problems. And the, the kind of outcome that, that I saw from this was, was, you know, I just need to figure out how to log the problem. And I’m doing a favor. If I send an email, I’m like my thought was I’m I’m.

[00:22:48] I get it. I was there. I understand that, that line of thinking. I remember a time where I may have thought that way, but being in the different sides of the business that I’ve Ben Allen has given me some insight into what my code is actually supposed to do. And if I see something wrong, it may not be, it may not be weird intentionally if it just a conversation we’re had with people about, about the process and why this is occurring.

[00:23:15] It may have just been some weird mistaken code made years ago. That was not really noticed until you went through and decided to look at, um, to look at whether or not, you know, to look at whether or not you should log this air or not. No one may have known about it, which actually brings up other arguments too.

[00:23:32] But that’s, that’s kind of the thing is that there’s, there’s the two sides, right? One is one is this holistic, um, Is is the project I’m trying to get into going to help the business. And the other side of it is I’m actually seeing this really weird behavior in the system. Should I log the air? Uh, probably probably you should, should go and have a discussion about it with, with your manager and team and figure out if that’s really what the system should be doing.

[00:24:01] You may have just found a bug that no one that no one really understood that was occurring until you found it. Yeah, I’ve, I’ve struggled this with this one, myself. I’ve even brought up things to supervisors before, um, or whoever’s over me and be like, Hey, do we need to worry about this? Cause I I’m, I’m constantly looking for, you know, as developer, uh, looking for different things that show up, but I’ve also been in a camp of ignoring, uh, issues that I see because I see so many of them, right.

[00:24:31] If you’re in a certain type of code base and you see so many different types of errors, Um, now that’s where I think it gets into a few different things is company culture, as well as, um, just not knowing, uh, I guess company culture would be the biggest thing that would come down to is, is, is your company, is your company one that wants to know about all the issues that occur?

[00:24:53] Are they in? Are they. Open to discussing that. And do they have proper channels for communicating the issues that you find? Right. So, um, because it’s hard, it’s a hard thing to prioritize. Cause I, um, like I mentioned before, sometimes I, I don’t have the best, uh, prioritization meter because I get so. Myopic on the specific issue where it might not be that big of a problem in the grand scheme of what you’re trying to create is, you know, making a, you know, what’s the saying, making a Nat, uh, making a mountain out of molehill, right?

[00:25:27] So if like, if your whole company is going to, you know, Your whole company is going to go down. If you don’t fix this one bug, but you’re focused over here on this, the small technical debt. Well, you you’ve got a miss prioritization issue that could cost you your job, right. Just because of the nature, like it could cost everyone their jobs, right?

[00:25:47] Like it’s a very extreme example, but I think that’s definitely a culture thing. And I’m a communications thing which comes back to culture. Well, technical debt is a different story than what I’m talking about. So the one thing that I, that I said that, that we were, that we were talking about is actually someone getting their product that they ordered is affected.

[00:26:10] The business process is affected by a bug. Um, technical debt has to do with. You know, if you happen to have and like, and, and let’s be really clear here what we say, technical debt. It’s like, well, if we did it this way in this pattern with this architecture, then it would be so much easier for us to maintain.

[00:26:31] And we have an in our industry, we do have accepted patterns and practices that we, that we typically try to use. But sometimes we come into some really strange code bases where people did crazy stuff and, and, you know, people decided to do the crazy stuff. And when they decided to do crazy stuff, to get something out the door fast, That’s a debt that’s built up.

[00:26:50] That’s going to have to be handled later saying that I’m getting, getting zeroed in and, and do you and I, um, I know that we were probably pretty similar at the, at the points in our career that, you know, like when I was mid level, um, or even some somewhat senior in my career, I thought that there was the one true way.

[00:27:11] And if everything had to be done the one true way and you know, I don’t care if it takes. Takes an extra a hundred years to get it done. Right. Let’s do it right. And the answer, the dogmatic programmer, right? The talk automatic programmer. Yeah. It’s so, so the thing is, is that that with maturity comes, you know, again, our code, the number one reason we get paid to write code is because some people think that if we write this code money will be made.

[00:27:44] That’s the number one reason why. And so the biggest thing that I want to, to impart here is that our number one priority should our prioritization should always be, if anything is stopping money from flowing, we should fix money flowing problems. If we now have time and there’s some technical debt to go solve.

[00:28:06] Let’s see if we can get people to agree to that because we did such a bang up job on the money flow problems, uh, that we can come back and work on the technical debt. Now, I will tell you something from having a lot of years of experience that time rarely ever comes. So the flip side of this is that if you know the processes that you should use, when writing the software, initially you should use good practices.

[00:28:33] The better practices of the day when you are writing software. Now I agree with you and that’s, that’s one of the things this might come back to bite me in the bud, but like, that’s one of the reasons why I don’t like startups as much as, because startups are so focused, rightly so, so focused on pivoting.

[00:28:54] So focused on getting code out the door as quickly as possible, um, that they don’t necessarily focus on. Um, the quality of the code and there is a, um, there’s a startup. I know that uses the extreme programming. So they’re doing TDD, paired programming, uh, practices, you know, test driven development, uh, which is TDD what’s TDD stands for, which is kind of a way to, um, it’s a loaded subject.

[00:29:20] We can go into it at another time, but, um, It seems like they don’t have to be in mutually exclusive necessarily, but most companies I don’t think. Yeah. Um, I think it’s very hard to, it’s very hard to, um, get buy in from most, uh, managers to use good practices at a, at a startup. I think it’d be really hard to, or the best practices, right.

[00:29:48] And bad, best practices being that’s a loaded term as well, but you want to call it her better. Yeah. Um, what are, what are some of the better practices that you can follow? And we know that, you know, automated testing can help, help you with, uh, discovering, uh, what’s wrong with your code, potentially theirs and theirs.

[00:30:09] There’s no silver bullets out there. And that’s something I’m realizing more and more, but you can have a lot, but most of, most of the arguments that I’ve seen against stuff like TDD are straw man arguments where they’re like, well, yeah, if you write bad code, right. If you write bad tests, you’re going to have bad tests.

[00:30:27] That doesn’t mean you shouldn’t. It shouldn’t do test driven development. You’re just putting, building a straw, a straw man argument that you can’t write good tests. And so maybe if your strength isn’t in writing tests, then don’t go to a company that focuses on those things. But I think that, um, I think that it’s, it’s definitely, uh, it’s definitely something to consider in your career is what, what type of culture do you want to be at?

[00:30:50] And you have to understand that the type of business, um, depending on the type of business that you work at will depend on the processes that you use. Right. Cause there, because there’s that Conway’s law where, you know, kind of the, the, have you heard of that one before? Yeah. I mean, I’ve, I’ve read about it.

[00:31:09] So if you want to go through it, no, it’s just, uh, Conway’s lie, I think is, let me, let me pull it up really quick. So I don’t, um, Conway’s law is an adage that stating that organizations design systems that mirror their own communication structure. Mmm. I don’t know if that goes down to the actual architecture itself, but I think it definitely, um, uh, Okay.

[00:31:30]Um, it’s, it’s an interesting premise, right? That your culture, you know, what you care about, do you care about really clean code? Well, that’s going to show within the culture of the company that that’s what the developers there think about. Whereas if you’re more of a startup culture, you’re going to worry about getting code out the door, you know, and you think more of the, uh, the Tenex developer thing is like, Hey, I’m going to get all the code.

[00:31:50] I can out the door. Right? No matter. Um, what, what cost it might be? Not that there’s, that’s a whole load of thing right there, but, um, uh, go check out to next developer. That’s a whole other, that’s a whole nother show. We could do a whole show on, on the concept of the, the, uh, let me put it out there. The myth of the Tenex developer.

[00:32:13] Did I just let my, let my position out. Maybe I did. Maybe I didn’t, you’ll have to tune into that show when we finally do it, I gotta go drop in the spreadsheet. Um, but I don’t, well, that’s, that’s real let’s will it back in, I don’t know, uh, what thread we were just on. Cause I kinda kind of went off into a dead end there where it just could, the thread kind of terminated for me.

[00:32:35]Um, but I’d like to talk about domain at some point. Sure. And I want to, I want to really emphasize the, the main thing about the other story that I heard. They’re still baby thinks. I don’t understand when you read things on the internet. So this is what I want to really emphasize. It sounded really strange to me because someone posted something on the internet and, and the conversation got a little, a little strange, but the thing is, is that.

[00:33:00] Again, there may be reasons, and I may not even understand the situation. So I want everyone to be really careful about that. Um, I don’t want to take too far from, from the topic, but I did just talk about something that, that maybe I have no clue about what’s really going on with that. But I’m just saying, from what I heard on the outside, It really triggered this, this discussion in my first of all in my head.

[00:33:23] And then I really, I sent you a text message really quick after this happened. I’m like idea for show you both. This, this really happened very quickly, which is that, that, uh, we need to talk about the fact that, that when we do work as a developer, that the reason why we’re being paid to work as it, and that’s the, this is the number one thing.

[00:33:43] This is the number one consideration that you need to make. As, as a software developer is that someone needed to get some software written to make it so money can flow from point a to point B somehow. And that’s, if you’re writing a product, that’s providing some kind of service. Well, that, that means that money is flowing to your company because of that service you’re helping to provide or quite literally.

[00:34:11] You’re writing e-commerce code that is taking money from people and processing orders and sending them product based on those orders. So somebody accompany is decided that by firing you and paying you very well to write software that you are going to. Make them more money than they’re paying you because they’re paying you to write software.

[00:34:34] That’s the number one consideration as a software developer that you need to make is that they’re paying you because they’re thinking you’re going to make more money off the fact that they’re paying you to write software. It’s not a charity, right? So that means that you have a responsibility to try to do your best, to understand, um, To try to help the business not hurt itself as well.

[00:34:59] Right. So to try to think through the use cases and go, I don’t think, you know, based on what I know about the domain, right. And the domain being, let’s kind of define what domain is, domain being. The, um, the, the business and its terminology and the complexities of that business. So for, for example, I work at an insurance company that could be one domain, um, and that can get, that can be broken down into sub, uh, different types of insurance and things like that.

[00:35:25]Um, uh, what’s some other domains e-commerce is another one. What’s some that you have with that domain. We’ve touched on that. Um, I’ve worked in manufacturing. So that’s a domain that I actually worked on software that, that, well, I worked for a company and I actually worked on different pieces of this software, but they actually had a computer aided engineering product that created files that were, uh, that were then fed into like all this code was internal that were then fed into, uh, manufacturing, uh, systems.

[00:35:57] And then actually manufacturers picked up that those. Those Rose out of the database, after those files were dropped in and made parts, like actually made the parts and shipped them out. So I worked in manufacturing and actually got to work in some of the, the, the nitty gritty. I got to write code that that was printing out, uh, putting out plans and all sorts of stuff.

[00:36:21] It’s really cool. It’s actually, it’s actually computer. It was software engineering to help engineers. It was great, awesome structural engineering stuff. And then, um, I worked in logistics for a few years, so that’s a whole different domain, right? How do we get products from point a to point B? So I learned a lot about logistics and, um, then, then also I worked in retail fuel, so not just retail, but actually a sub domain of retail, which was retail fuel.

[00:36:50] I worked for a gas station. It’s funny when I say that, but I actually worked for their home office then, uh, you’re selling, you’re selling the cigarettes and the, uh, Yeah, all the convenience feeds, you know, the interesting part was that I didn’t work on software that sold cigarettes. I know that person who, that guy made a lot of money for the company, because they would see a change in the contracts for the rebates for the cigarettes.

[00:37:18] And he would be the one that go in and make the changes in the software. And he’s like, I just paid the company another million dollars by making this change, you know, he’s, you know, he was really proud of that, but then I’m like, well, how much are they paying you then? Wasn’t it. So that was that’s a, that was a, that’s another interesting conversation right there.

[00:37:38] The, um, I did get to write the software. I actually wrote a payment system. I wrote the inner workings of a payment system while I was at this company and got to help with the code that that would lock down. You know, you could actually give your kid a sub account on this payment method and. Not let them buy cigarettes.

[00:38:01] You can limit what they could buy. Yeah. So that kind of made me feel a little bit better, even though, even though I worked for, like, I think they were like the number two retailer of cigarettes in the country, um, I actually got to work on software that kind of helped limit that a little bit. Right. And so something we didn’t yeah, lots of domains.

[00:38:20] And we’re talking about business, like a better definition is this, these are what business domains are. Um, I think is kind of the more specific term, uh, cause domain is like a loaded term inside of, uh, uh, you know, with networking and, uh, IP and stuff like that. Um, Oh yeah. So business domains, um, Uh, there’s a lot of complexity going down inside of there.

[00:38:40] And it’s, I think this comes down to company culture as well as how much is the company investing in you at? Like how much do they want to give to you as a, um, developer? Right. So in large enterprises, they might insulate you a lot from. All the different, the entire business domain, right? You’re not going to see the, you might not see the overall overarching picture for your company.

[00:39:06]Um, and you’ve worked at large enterprises before, um, What have you seen? What have you seen before? What’s the difference between that and a, uh, a mid to smaller company where, you know, mid-level being, uh, or, uh, uh, small to mid sized business, you know, midsize being, you know, 50 developers or 20 to 50 and small being like one to 20.

[00:39:24] What have you seen the difference between, um, between those, uh, those different atmospheres and how much you have to understand about the business domains? So the interesting thing about this is that I actually worked one of the companies when I worked in logistics, we had seven developers. Right. But there were like, there was over a hundred employees.

[00:39:47] So we, there were very few developers supporting this product that made the company a lot of money. As far as, uh, from the website of things. There was another development group inside there that headed up the ASMR four hundreds and stuff like that. So there was another, a little bit of other development going on, but the front end of it.

[00:40:06] Which is funny, I say front end because I did all the ends, you know, I just didn’t do the part. I did all the ends. That’s, that’s a quote, that’s the quote of the day on this one that I did quote of the day did all the kids, that’s what they do by full stack. I just didn’t know it at the time or that they were, they were in the first place.

[00:40:25]Um, that’s, that’s another topic for another day, but no, the thing is, is that, um, That company was considered a mid sized company, but we had a very small group of developers that handled a lot. I think that that’s actually a little bit more common than you think it is. So that was the first thing. The second thing is.

[00:40:50] And well, let me, let me think about that for a minute. So in manufacturing, we had lots of employees in the manufacturing side of things, but as far as developers were concerned under 10, under 10 developers. So the size of the business does not correlate the size of the development group. That’s an, that’s a interesting thing I had not thought of until you just brought that out.

[00:41:12] Like, what was it like working for a midsize company? Now I have worked for a major bank before. A large bank, probably one of the largest banks in country, maybe. Yeah, I think so. And I’m up there at least in the fortune 50, right? So that one was you’re right, totally isolated. You didn’t sit in, you had no chance to sit with executives at all.

[00:41:40] You were within your own group. Um, There really, wasn’t a way for you to affect everything going on in a company like that, unless you were really like, Oh, one of those projects right there, there are, there is a such thing as, as a project that everyone will use, like maybe you’re working on the, the website for the bank.

[00:42:01] Everyone who will touch this. And if something goes wrong, the CEO will probably hear about it. So depending on how badly it goes wrong, but in that situation on right in that situation, you have. You have lots of different teams. You have lots of, I mean, you had, we had an architecture group, right. That all the decisions about architecture would go through and it had to be vetted and versions had to be vetted and audited for security.

[00:42:33] And it was, everything moves so slowly and in that realm, but rightly so, like you want to hear, like, I’m telling a story you’d want to hear at the bank. It’s really hard to move to a new version of anything. Because everything has to go through security audit architecture has to, the architecture group has to see how to assemble it.

[00:42:53] And then it gets passed down to the engineering group to go put it together. And it’s a, it’s a way different, it’s a way different process than what I was used to ever. And I didn’t stay there that long. And then, and then, and then we had, and then I’ve worked for ’em. You know, I’ve worked for companies that would be considered large companies.

[00:43:16] So I’ve worked at the, you know, the 170, like the, um, what is it that I’m trying to say? The, the, uh, uh, A fortune, a fortune one 70 company, which was a little bit different than a fortune 30 company or 50. And at that level, we had lots of people in technology, lots of departments, but really one development group that did a lot of the work.

[00:43:38] And a lot of the like, like web development work, all web development with one group. And I was in that group and. That one was a little bit different. They wanted to be sure everyone knew what was going on. So we’d have company-wide meetings where at the home office, this the. CEO would talk or the vice president would talk about, about what’s going on, what the vision is, and just kind of give you an idea of what was going to happen.

[00:44:07] So I see it’s way different. And even at that company where, where I was like one of seven developers, I never sat in an executive meeting. I never sat with people above a certain level and heard what the vision for the company was. But when I worked at that huge company, You know, when I worked at not the biggest, the biggest, but when I worked at the, you know, when I worked for the retail fuel company, um, yeah, they, it was a very close knit home office and they wanted everyone to know what the vision was.

[00:44:34] So we could all walk in lock step together. So it just you’re right. Culture is a hundred percent even, no matter what size the company is. I guess the moral of the story here is that you can, um, you can keep your employees up to date with what your ideas are. And I would even say that that even if you didn’t have that vision from, from your executives, You still kind of know, you’ll learn the domain itself.

[00:45:03] If you’re city can retail fuel and you’re sitting in the, in the fuel department and your job is to write code that that records fuel being put into pipelines. Cause that’s how we move fuel around. In the U S as they go into these big pipes and you take the fuel out in the location that it’s supposed to go into.

[00:45:21] So you start off at this one location, you push a bunch of fuel in, and then your truck at the receiving end can pull up to the terminal and pull that much fuel off. And it’s kind of one day, we can have a talk about that, how that works, but I don’t want to do all of that here, but if you’re writing code that maintains that you see something weird about Paul, if, if this keeps going like this, something weird can happen, right?

[00:45:43] And maybe we don’t record something that needs to be recorded or something more gets recorded that can cause us compliance issues. Maybe it’s time to start, you know, you start going up, but see that takes learning about the domain that you’re in. Not necessarily about the vision of the company, but what are the rules about what I’m writing code for?

[00:46:02] What, what is it? What am I actually doing? I’m not just writing code to write code, which is what I did for a long time. And I was actually, look, I never had trouble keeping a job. Every time I left a job, it was because I left the job and I had another one to go to. And people, usually I had one manager scream at me when I turned in my resignation.

[00:46:23] I got screamed at for returning, for turning my resignation in. So it’s. Um, like I’m guessing of way. And while screamed at, as in like, like, you know, what have you done to us Douglas? And then, and then like someone else walked in and talked to him and said, Hey, you know, you’re gonna, you know, we could probably try to keep this guy.

[00:46:40] If you didn’t scream at him. It was hilarious. That was the guy above my manager that was yelling at me. And then my manager walks in there and has a conversation that he brings me back and says, is there any way that we can convince you to stay. That’s what I’m saying is that, is that even with the understanding that I was writing code to try to keep money flowing easily and with less friction, I still was worried about, about writing high enough quality code, that when I did try to leave a place that people usually argued with me about it, it was an argument they wanted me not to leave and to stay.

[00:47:17] And so, um, But I will say that the one thing that I think that would have caused me a lot less losing a lot less sleep or a lot less brain cycles over things was that if I just remembered that I was writing code to try to keep things, keep the business going and not so much about, well, they’re not letting me use MVC.

[00:47:37] Cause there was a time before asp.net MVC. Uh, and there were people that were against that pattern when it first came out and it’s, it’s crazy, but there’s, there’s people that were against every new pattern that came out. But if it was, if it was more about what am I doing to help the business, and then I wrote resumes, this is the other thing to writing the resume to.

[00:47:59] How did you help the business? Well, these are, this is the code I wrote, and this is how it helped the business. Do you know what that would do to a manager that saw that resume? Like this guy is writing code and thinking about helping the business by writing the code, like he’s actually stating how the code actually helped the business.

[00:48:17] That’s going to give you a leg up even before you walk in the door. And they talked to you about how you code that may even change your technical interview a little bit. I think that could, I think it’s interesting. Everything that you’ve, you’ve touched on. And, um, I agree with you in large terms, but I also, I also think that.

[00:48:40] We’ve talked about this before in that in software development, everything comes down to like, it depends, right? I think that this, this question what’s your most important responsibility comes down to it depends. And I think that you can decide it depending on. What company you pick and the culture that predominates of that company or within the team that you’re going to join.

[00:49:02] So what do you think about asking, you know, asking potential employers? You know, what’s the, what’s, what’s my main responsibility. Right. Not my actual technical responsibilities, but what are, what’s my overarching responsibility? Like, what are you, what are you on me to say, see day in and day out. When I come at this job, how do you think approaching, um, finding a job in that way would, would set you up, um, differently versus not asking that question.

[00:49:31] How I’m trying to put myself in the position of advantage, or that’s just been asked that question. What do you expect of me every day? And the thing is that question is so open though, that I may not understand the true reason why you’re asking me that question. So yeah. You’d have to give him some examples.

[00:49:53] So you go, okay. Um, Because this all comes down. So the culture things have been big for me because I’ve realized like being in the right culture can help you succeed in your strengths. Right. So you’re your biggest strength? So some developer’s biggest rate might be writing code. Some might be communicating, right.

[00:50:10] And being the mesh between between teams or. Eliciting requirements, right? If you, if there’s no B, if there’s no BA, if there’s no business analyst and you are really good at getting requirements from end users and turning that into code, you might not need to be the desk developer, but you might have better communication skills.

[00:50:28] So I think. I don’t have the exact wording, but you could give different examples and go, okay. Um, you know, what, what are you hiring me for, for my skillset? Is it just like, is it just coding or are you wanting some, like, here’s my strengths. Right. Do you see these strengths as being valuable to you as a, as a organization?

[00:50:48] And you’d have to pitch that in the right way so that it’s not used against you, right? Or just, um, or. Not used as, um, uh, you know, that they’re just going to hire you without actually using your strengths. Cause I’m a big proponent of using your strengths at the companies you work at.

[00:51:07] So I still think that the, the question in an interview might be, might be taken. You know what, it’s a fair question. So the actual question itself, and I’ve actually even seen just coming into mind right now, I’ve seen it listed as one of those questions that you should ask. What do you see my day to day responsibilities?

[00:51:28] Looking like, you know, what is it that you would have if you were to hire me? What is it that you would have be doing every day now? And it depends. And I hate saying it depends. Cause it seems to be such a cliche thing to say, but here’s what it depends on. If you’re a junior. At the point where you’re a junior, it may, your job responsibilities really may be to work with a senior level developer to accomplish tasks.

[00:51:55] Senior level developer gives you, it may not even be to have that much of a, um, That much of a say in, in certain things like, like, well, why would you do this or that? Cause you probably don’t know why would you do this or that yet you’re a junior developer. And, and so in that, that position, it really would be like talk to your lead and let’s, let’s get some stuff done and you may not know to question things.

[00:52:23] As you move up through your career, though, what you hope to hear is something along the lines of, we were looking for someone who is going to be a member of this team that will help, you know, that will not only write highly maintainable code, that that accomplishes the goal of, of the project. But also we’ll be on the lookout for things that we can do to do things better.

[00:52:51] And if you hear something like that, then, then you know that you’re working for a company that is looking for feedback from the people that work for them. If someone actually calls that out, then you know, now implicitly, I wouldn’t have known, I wouldn’t have even thought about trying to deliver that message.

[00:53:10] But implicitly, I expect that if I were to hire a developer, I need them looking at whatever they’re looking at and come at me with, I found this really weird thing. Can you kind of go like either one, tell me what this is. Like I may have just found it. Maybe I may have just found a bug, something kind of doesn’t intuitively work right here and let’s have a discussion about this and then you kind of look at it and go, Oh, right.

[00:53:34] You’re you’re totally right. That. I, we didn’t even know that it was doing that. Thank you so much for finding that code. And, and let’s, let’s put that in the tracking system and let’s get it prioritized and we’ll put it on the list to get fixed or to here’s the business case for why this happens. Let’s figure out a way to make it to where that problem gets fixed faster.

[00:53:57] You know, the problem that, that causes that weirdness to occur, you know, let’s, let’s figure that out and. No, I would expect that, like, if I were hiring a mid level to senior level developer, I would want someone that’s going to come in and tell me if they see something that’s a little off from their intuition, you know, intuitively this does not work the way I would expect.

[00:54:20] Like you’re going to work for an eCommerce site in orders. Don’t get processed. If this thing that happens doesn’t have that doesn’t even have to do with whether a product is available in our, in our warehouse or not is stopping orders from being. Process because some digital asset doesn’t exist. Then talk to me, let me know that that’s a problem and let’s, or let me know that potentially could be a problem.

[00:54:43] And that shows me that you’re looking at stuff, right. I w as a, as a person that potentially could hire developers, I would love to see that I would, I would love to see that. I think, I think it just came to me as to how to pose us. And this might be kind of, um, uh, we did that interview with Eric recently and he, he had some really good golden gyms in there of, of how, how to approach interviews and different things like that.

[00:55:11] But. I’m wondering if you, you know, how you know, how employers love to give you the, um, and maybe you’ve done this before, but they’d love to give you the, the hypotheticals of like, imagine you have a difficult, you know, you have this scenario of a, of a, uh, difficult, um, coworker that you’re working with or whatever scenario, how do you respond to it?

[00:55:33] I think if you did the same thing to them, But instead gave them how you like to work. And you say, look, if you’ve ever worked with someone that, you know, constantly ask questions and constantly questions, the status quo, like that’s more of like me, right? So like I’m constantly questioning like, okay, why are we doing what we’re doing?

[00:55:54]Um, how do you respond to that? Cause if you can get, if you, if they become hostile to that way of thinking, right. If you have more of a, you know, Uh, sit down and shut up attitude. You’re going to know once you’re going to know that you don’t want to work at that location because that doesn’t mesh with your skillset.

[00:56:10] Okay. And so I think taking your, taking your strengths and posing them in the right way, it’s going to allow you to actually use your skills in conjunction with how your boss wants you to perform the job.

[00:56:37] I was gonna say, I like that a lot. So the main thing is that, um, what I want to say is, As far as listing your strengths, this is something that what’s your super power, right? I’ve been asked that a couple of different times. And if you come in and say, my super power is that if I see something that is, that doesn’t look right to me, I will say something about it.

[00:57:04] Right. That’s that’s a superpower. I question I’ll question. What is going on? Not from a critical lie, but from a curiosity and, and from a, you know, maybe this is a potential issue, but not from a, like, this is the worst thing I’ve ever seen, you know, kind of perspective. That’s going to show a lot. If, if you kind of say that or let me give you a scenario, like, I kinda liked that where you turn the scenario, we, in our mock interviews that we have for our students, we have the question about, um, if, uh, what was the last conflict that you, you know, the last major conflict you had at work and how did you, how did you wind up handling it?

[00:57:41] You know, that’s a, that’s, that’s one of those questions, right? I, uh, that everyone, you know, it’s usually like that falls into, what’s your greatest strength, what’s your greatest weakness. And, you know, then you just go my greatest strike this, that I’ll I’ll work until my fingers. I’ll I’ll type until my fingers turn to bone.

[00:57:58] And then what’s your weakness. I type until my fingers turned to bone, that’s my weakness. You know, that’s, that’s how you handle that question. You know, I’ll, I’ll keep coding until I die. That’s that’s a weakness. In a string, but exactly I’ve almost coded myself to death before. It didn’t quite, quite good all the way there, but I’ll tell you, when you go for like weeks of slew with, with about two hours of sleep a night, I know what that feels like 18 hours a day.

[00:58:29] Luckily I was paid hourly.

[00:58:34] You have the right incentives there. I I produced, yeah. I produced the work like they’re like, can you have this ready for rest by the morning? And I’m like, it’ll be ready. And then someone actually actually, uh, kept, kept, uh, woke, be up. Like I went to bed for two hours and they woke me up and I started coding again while they slept.

[00:58:50] And then, and then, yeah, it was I dude, I don’t, I’ll never do that again, but it was an extreme to have a, uh, you know, uh, uh, um, battlefield stories, episode, you know, the. Of all this stuff you’ve been through. So I think so I would work myself. So that’s the thing. Let me, let me get back and wrap and kind of put a pen in this.

[00:59:11] Yeah, the question is that. You know, what would you the, the interview, right? How would you be if, if that would be an acceptable thing for you to do? I think that it also depends on the level that you’re at. If you were a senior level developer, I expect, I expect senior level developers to. To have that critical eye to always be thinking, is this code working the best way possible?

[00:59:44] Are there weird things happening when they come across them? And will they get that message to the right people? If there are the strange things going on, um, as a mid level, I would love to see that like, just, just as someone who, who, um, Just just as me as someone who might, you know, at some point, be in a position to start hiring again.

[01:00:05] And, uh, you know, looking at that, uh, Mid-levels I would, I would love for them to be trying to do that. Now. It never criticize someone to come. They came to me with, this is kind of strange. What’s up with this. Like, tell me about it. What’s the story behind this. That’s really the way that I try to handle things.

[01:00:21]Um, what I don’t want is someone to come in with guns, blazing going, this is the worst crap I’ve ever seen. What’s wrong with you all, you know, and they’re like a junior. Right. It would be a real, Hey, I’ve actually seen this. Like I had one, I had one junior developer that I dealt with. Everything needed to be rewritten because it was the garbage and I’m like, no.

[01:00:45] Or the not written here, problem where if you don’t use other libraries, cause you have to write them yourself. You don’t well, it wasn’t a not written here. Problem. I think it really was that he was so junior that, that he couldn’t read code well enough to understand, like he was having a hard time understanding what the code was doing.

[01:01:04] It was not written in the exact way that he needed to see the code. Therefore, everything was just like, whatever you wanted to do. If you need to touch the code, it needed to be completely rewritten. That was, that was his initial response to everything. Cause it was so bad, it needed to be rewritten and I’m like, that’s not necessarily true.

[01:01:23] So there’s, there’s definitely a side to this. There’s some nuance to it. This kind of goes into one of my, I don’t like the name of this, which is soft skills, which is you see something you think is wrong, but you need to collect data on it. And the only way to collect data on it is to nicely talk to people about it and see what they have to say, get reconnaissance on why this weird thing is there.

[01:01:48] And then once you can build a case up and put it together. Then you come out and go, Hey, I think I found something that’s wrong. Can we, can we talk about it as a team? And, um, and I don’t know if we’ve, I don’t know if that’s buttoned it up or not, but I mean, as far as I think the question was, was going to be one of those nights, it’s late.

[01:02:09]Uh, we, we went on a different, a few different streams. Like it was like, you know, the. The way that I word it was like, what’s your most important responsibility? Or, you know, we’ve, we’ve said what’s, what’s one of the number one reason why you get paid as a developer or, you know, that the business is your business as a software developer.

[01:02:27] Right. There’s a few different threads that are very similar. Yeah. And I mean, I think, I, I think I kind of nailed down. The thing that you were talking about, which is there, which is that maybe how do you find out if the culture is going to support that or not? I mean, I’ve said it from my side. I would want to hear someone say that they do that kind of thing, but I also want to hear someone know or be humble enough to know that they’re not.

[01:02:51] You know, if they’re a junior coming in that they’re going to ask a lot more questions. And that’s the thing that you’ve asked about, like, do you, that junior that asks a lot of questions. There’s different questions that you can ask. One question is I want to know more about the domain, the business domain that I’m in and you start asking questions.

[01:03:10] Well, okay. So they make an order and, and, you know, kind of, we have warehouses. Yeah. How does, how does the orders get to the warehouse? You know, that, that those are. Those are kind of, kind of domain questions and technical questions about how, how, how the business flows. But then there’s another kind of question that I think maybe, maybe you’re more, maybe you’re more thinking about which is, which is I’m trying to do this thing and I can’t get it to work.

[01:03:36] That’s a different kind of question. That’s a, that’s a, um, Here’s here’s the thing about those questions. I did have a junior that I worked with and I got these kinds of questions over and over and over again. And every time I’d get one, it would kill my, my, my train of thought for an hour. I would lose about an hour of time.

[01:03:55] Every time I got a question that would take me off of my project and. I really, I was the good guy. I wanted to go answer the question. I was the selfless, the selfless developer. If someone asks me a question, I was just elated that someone asked me a question. So I try to go answer it. And, uh, um, you know, the, it got to a point though, this is the one developer also that I would, I would give an answer to.

[01:04:18] And this developer would pretty much challenged me a junior level developer. I had like seven or eight years of experience and he would challenge me on it. And intuitively I knew why I was saying what I was saying. I’d been through his problem and I’m like, dude, I don’t have time to really go into in depth right now on this.

[01:04:36] This was a problem I had dealt with. You’re going down a path that might cause you problems because the path that didn’t, this is the path I learned from, uh, when I did it. As far as what didn’t cause me trouble. Cause I did it your way and it did cause me trouble. Well, I don’t believe you. And then you go do it the way that I basically said that caused me the most trouble.

[01:04:55] And so, um, That’s the kind, that’s what you don’t want to run into. You don’t want to beat that person. If you’re going to ask for advice, even if you’re not going to do it, don’t tell someone you’re not going to do it. And then they just spend all that time trying to help you. And, and, uh, you know, you’re, you know, then they’re not, she’s not gonna want to help you, but here’s the most powerful thing though.

[01:05:16] If you ask for advice, take the advice. And if it’s, you know, what, if it’s not stupid, like, like, like yes, murders, murders, perfect. Like just, if you have someone you’re competing with kill them, you know, that’s that kind of thing. If it’s not something really illegal, crazy, and you try what they told you and, and you come back and go, Hey, I tried the pattern, you talked about this way.

[01:05:40] And, and I noticed this and this and this, but you’re right. It actually did work. That is a really good conversation to have. Like that means you’re trying to learn something as a junior, from your, from a senior level developer. And you had a conversation about the aftermath of you attempting to use that pattern.

[01:06:02] You know, like I said, if it’s not something really dumb, like, like, you know, shave, shave, uh, what is it, uh, uh, a thousandth of every penny off the system going through the, going through the, uh, of money going through the system and put it into a checking account for yourself, even if it’s not that kind of advice.

[01:06:17] Try the pattern that the senior level developers telling you that it might be good for you to use, see what it does. And if you have an issue with it, have a discussion like, Hey, I tried this and I noticed this and this, or are you in better come up and say, I did try this. And it worked because that’s going to get you more help.

[01:06:35] And you’re not going to be considered, even if you are annoying. Like even if, if I’m. What I’m trying to convey the message I’m trying to convey here is that if you ask for advice and come back and say, I used your advice, and this is what happened, you’re going to get a lot more advice from someone who who’s been doing it a lot longer.

[01:06:55] You’ll become there without even asking about being them, being your mentor, anything you’re going to develop a mentor, mentee relationship without even asking for it. If. You get what I’m saying? No. Yeah, I totally get it. I think I was like, wait, what?

[01:07:18] No. Yeah, I totally get it. I think that’s a, that’s a, that’s probably a good place to, uh, To lead the conversation. I think we went, we, uh, we definitely had a lot of, a lot of different points. There was some there’s some great stuff. Anyway, guys, we have some great episodes coming up. Uh, we’ve got some more interesting people that we will, we will be interviewing as well as some great topics.

[01:07:38] To focus on, please send us your topic, ideas, um, go and sign up for the, uh, the newsletter. And you can reply to that with any ideas that you have, um, and also get notified about the podcast and when it’s coming out, um, Yeah. So thanks for, thanks for, uh, thanks for doing this again. This is, this is always fun.

[01:07:58] Remember that, uh, that website of ours, that’s a www.juniortoseniordev.com and that is where you can sign up for that, that email list and see our latest episodes and whatnot in the show notes. Thanks so much. Yeah. Thank you. Have a good one. You too.

Junior to Senior Dev: Episode 4 – Interview with Eric Weber – What is Data Science

What We Discuss:

  • What is Data Science?
  • Data Scientist vs Data Analyst
  • How To Improve In Interviews?
  • Can you switch from Dev to Data Science?
  • Do you have to be Good at Math?


what does that everyone welcome back to junior to senior developer. I’m Tyler Lemke.

[00:00:06] I’m Douglas Hirsch. And here, here, we’re here today with Eric Webber. I’ve got it right this time. Um, Um, he’s he’s currently the head of data science and insights at list reports. He started his career in academia where he spent five years, both teaching and researching, and he has been doing data sciency things since 2008 and has worked at other companies such as LinkedIn.

[00:00:28] And CoreLogic Eric. Thanks so much for taking some time tonight to meet with us. We’re really excited to talk to you. Well, thanks guys for the invite. Um, I’m excited for a couple of reasons. One is to just, I’m used to being on in conversations where I’m talking to data scientists and one, I think that gets all.

[00:00:47] Don’t tell them. I don’t tell him. I said that, but to, um, I think the important part is this field is hard to define and when other people hear it, when they hear the term data science it’s sometimes. Unclear what it is, what the job entails. Um, and I’m looking forward to getting to have that conversation along with other topics.

[00:01:07] I think that’s a, that’s probably a really good place to start at. So you’ve um, and one of, uh, one of an insert in a recent interview, you kind of mentioned a few of these different things. You said how, um, I don’t know if it was what the exact context was, but how companies want to like define what data science is to start off with.

[00:01:26] And, and they, um, uh, part of it is knowing the aspect of. What you’re going to teach within data science. So can you kind of break down the different categories of data science, because we all hear this word and it’s kind of a nebulous thing. We all have nebulous terms inside of the text. So it might be good to kind of separate out what you think are the main categories or aspects of data science.

[00:01:48] So I think I could answer that. I’m going to answer the question in a way that fits in a few minutes, but really this merits like many, many discussions because companies have these discussions all the time. Cause they don’t know how to define that. What it is, I’m at a high level. I, this is my definition.

[00:02:07] Right. And reasonable people disagree. I tend to think data science is all about the practice of getting value out of your data. Whatever that is real business value out of your data. And that is a pretty broad definition. And I think that’s okay to have that broad definition. Um, because often when you hear people define data science, they think like, Oh, they do machine learning or they build algorithms or they’re shipping something into production.

[00:02:35]Um, or they are working on what they don’t have a concept of is like how much basic scripting. And a SQL and Excel and things like this are involved in getting value out of data. Um, data science to me is more of an ecosystem, right? There are different roles that are a part of that ecosystem. Um, in some cases it’s people that make sure that they are getting the data prepared and ready in such a way that.

[00:03:06] People can actually use it. They can look at it. Right. Um, data engineering is a foundational, even more so than data science roles. Data engineering is probably growing faster and will continue to grow faster. As people need to have data to use, need to have it in some structured reasonable format in a timely manner.

[00:03:26]Um, Is it an analysis component of data, right? People that are doing this is where people tend to think about statistics. They tend to think about running tests on data. They run experiments to try to determine whether something is true, right? If you’re shipping a feature into a product, if you want someone to decide if that feature has meaningful impact on user engagement.

[00:03:50] That is an experiment or something that a data scientist might create. They might do the subsequent analysis after that as well. Um, there there’s another component to data science, which is, which I think tends to be what people envision is that we’re sitting here building novel algorithms and then putting those things into use and the product that’s actually relatively small part.

[00:04:13] I think of what a day is data sciences does. It’s. Well, when you start talking about novel development of algorithms, shipping those things into production, you’re talking much more about like in machine learning engineer type space, where. It’s not just the development of the algorithm, but it’s making sure that it runs in production in a timely manner, that it doesn’t negatively affect the user experience.

[00:04:39]Um, and so when it comes to like this whole different family of making, of getting value out of data, there’s a whole bunch of different job titles. And I think what you tend to see. As companies say data science, because they just don’t want to spend time giving you five different titles. Um, so this, you can imagine the confusion that is out there for people who are not working in this space on a daily basis is they’re like, well, I thought data science was this.

[00:05:08] Well, I thought it was this and there’s all this disagreement. And it produces these like. In my opinion, some fruitless arguments about what data science is. It’s more about like, are you, are you helping to get value out of data? Sure. What role you play that’s for you and the company to define. You know, I really like the way that you put that.

[00:05:29] Cause it felt like for a long time, even in just playing software development, we were just like this one, like software engineer was the job. Like no one, no one even differentiated us. Um, front end backend. In fact, it was only when I got to Texas that I actually learned when I told someone what I did.

[00:05:47] They’re like, Oh, you’re a full stack developer. That’s awesome. But apparently at some point I didn’t know about this. Um, what we did finally got split out into like front end, back end design and you know, and database development and all this stuff. And the way that I was raised up in the industry, Uh, basically we just did everything.

[00:06:08] You had to learn how databases work. We had to write our queries and get value from that data, but then also know how to store the value in a way that we could get value from that data. Just like we were talking about, um, all the way through making our front ends with a, you know, HTML, CSS and Java script and back ends with whatever we were going to use.

[00:06:26] And, and, um, Yeah, it was all over the place. Cause no one knew how to separate that out. So I think from what you’re telling me is that at some point they’re going to get smarter about this. They’re not going to call it data science. It be more adult they’ll have the different aspects. Cause it’s a much younger, it’s a much younger designation, I think, you know, software development.

[00:06:48] So this makes a lot of sense. I think they’re gonna, I would hope they get smarter about it. Right? That’s the best case scenario. The more likely scenario is. That just takes a long time for these differentiations to really take hold. Um, you’re starting to see these differentiations happen much more at larger companies.

[00:07:08]Um, ones who have been trying to work in this space for quite some time. You’ll see a lot of major reorg. Sort of happened at Google and Facebook and LinkedIn and those types of companies, precisely because they’ve come across the same issue, they’ve built large data science departments, and then they figure out that, well, actually we’re doing like six different things and we all shouldn’t be part of the same organization.

[00:07:33] Some of us should be part of marketing and sales. Some of us should be part of engineering. Some of us should be part of a full fledged data organization and. What I’m seeing is until a, company’s have a reason to not call it data science. They tend to just do it out of ease of use, like smaller companies, especially there’s like, yeah, you work with data.

[00:07:57] We’ll just call you a data scientist. But it produces this, um, where it does produce a lot of issues in companies as they’re trying to hire people because. If you go off titles titles, in my opinion, in this space are really hard to assign value to, but if you have a recruiter looking at a bunch of resumes and they look and see, like someone was a data scientist somewhere else that leads them to believe they have relevant experience and it’s going to be right for this role.

[00:08:29] And that’s not necessarily true also because data science, in my opinion, when you think about getting value out of data, It’s very dependent on being an advanced to expert in the context of the company’s operating. And it takes you awhile to learn if you’re doing data in real estate or you’re doing data in healthcare, or you’re working for this particular company.

[00:08:55] A lot of the skills might seem translatable, but they’re often very context dependent and that takes a long time to ramp somebody up. Like, to me, you’re not really effective until you’re like six to nine months into your job probably. That makes sense. I mean the domain, right. Domain, whatever domain you’re in.

[00:09:13] Right. It’s it’s um, it happens. I’ve been in, uh, several different domains through, through my career. And I’ve noticed that, that you really can’t have business conversations with people and know how to translate what they’re saying into code until you actually understand the business side of what’s what’s happening.

[00:09:30] It’s extremely important. So I. I know where you’re coming from on that. It takes a while to get someone up and they have to want to get up to speed on that. But I think on, I think in the data science world, if you, if you’re trying to get a job in that realm, and that is your job, you’re going to want to get up to speed as quick as possible.

[00:09:48] And the domains that you can have, those domain specific conversations. Absolutely. So you, so I think this is a good, a good segue into, I think something that you talked about before, um, is with the domain knowledge, um, another interview you had a couple of years ago, uh, there was a question that came up about mastering the data.

[00:10:10] Does that sound like a familiar term to you at all? Yeah. I’m always like people, it’s sometimes funny people, like you said this a couple of years ago. I’m like, I hope my previous version of myself said something so many intelligent. And if he didn’t then Nope, I don’t remember at all. But yes, mastering the data.

[00:10:27] It’s it’s, it’s something I would have described cause I continue to believe it’s important. So, what does that, so you talked about how, where the data lives, how to access the data. Can you talk a little bit more about this and how can a junior or mid level data scientist kind of get up to speed faster with mastering the data and whatever role they’re in or where they’re at?

[00:10:52] I think to me, You don’t learn about you don’t master data in the abstract. Like no one very few companies is someone going to present you with a data model. And from what you’re going to be able to infer how to, um, join different data sets together, how you’re going to be able to leverage them and affect and, and, you know, to create effective insights, you really have to be tossed into the deep end with a problem.

[00:11:22] And so to me, like when people talk about onboarding a data scientist and that you kind of make or break somebody within the first six months, if they’re going to stay with you for awhile, um, you have to give them the right problem to dive into when you start. And that problem should be broad enough that it forces them to.

[00:11:41] Look at more than one single database or one single table within a database. Um, it should require them to particularly in like a setting where you have customers and user behavior looking at user behavior across different contexts, time periods, stuff like that. Because what we, the reason that I think it’s so valuable is until you learn, um, The ins and outs of the data that you have.

[00:12:09] It’s hard for you to know what the limits of the questions you can ask are, right? Like if, if a business partner comes to you and they’re like, Hey, like I’m wondering about this. I’m not sure how to figure it out. Like this is confusing for me. It’s really important that you’re able to. Now, if it’s possible to answer that question, because.

[00:12:29] It definitely is dangerous if you’re like, yep. I’ll work on it. And then you’re like, Oh, sorry, I couldn’t do it. Like we don’t have the data. Um, or if you don’t have the data and you need to, to be able to call that out, right? Like we’re, we need to be collecting this. We have no insight into what the user is doing.

[00:12:46] Right. There’s a lot of companies I’ve joined where they’re like, we’re trying to map the user experience from like, from the moment of sign up until 30 minutes after sign up. And then I tell them that, well, you don’t have any actual events that you’re tracking between those points in time. So your ability to decide, describe anything is not going to be good.

[00:13:09]Um, And so it’s that onboarding experience it’s like really feeling like what are your tools? Because people like to talk about their tools like it’s R or Python or SQL or whatever it might be, but your tool usually is knowing the data super well. Um, that to me is. More important than whatever code you are writing is you have to start from somewhere like, and I think as you see more in the, we’ll get into this topic later, but you see more senior people, more senior people tend to really, when they come into a new company, that’s what they push.

[00:13:45] Hard-on right away. I’m like, where’s the data. How do I get to it? Can I use it? Can I bring it together? Um, and so that’s one of the major differentiators that I see just in terms of maturity in the space. Okay. So it sounds like if it’s really, it’s something that’s really difficult to do without some mentorship from your peer or from your, uh, you know, higher ups or peer like peers being like more senior or your team lead or whoever it is.

[00:14:14] I don’t know how it works with data science, but if you guys have team leads typically, or how does that work? I think it depends on the thing that’s most frustrating about this space is. The answer. It depends seems to be the most common answer, right? It’s like depends on the size of the company and the maturity of the company.

[00:14:33]Um, in an, I I’ll talk from like an ideal scenario and an ideal scenario, you have a pretty intense onboarding experience that lasts a couple of weeks with someone who is not just a business partner or a business expert, but who is a technical lead. Who can teach you how to get to things and why you need to get to things at a certain time, um, why it’s important that you access this database and this way they can, they can often help you overcome many hurdles that you don’t even know are there by, and, and they can do it really fast.

[00:15:13]Um, what I often see though in the onboarding experience is like, Okay. You have, you know, here’s your computer. We give you your log in info. Godspeed. That learning experience is not pleasant for anybody. Um, and so I think about that a lot. And part of that is like,

[00:15:39] The field is new enough that like what mentoring means, and that is still like, I think being defined a bit, it’s hard to actually find really good mentors because many of us are still figuring it out. And I think that’s a massive challenge, honestly, for not only starting a company with a couple of data scientists, but if you want to scale a team, you have to have people to mentor that team.

[00:16:03] Not everybody’s a good mentor in order. They want to be one.

[00:16:09] let’s just say that, that, that kind of rings true. What you just said in the software field too, because depending on the size of the company, you may or may not. And this is what we tell. I actually, uh, I’m an instructor at a coding boot camp right now, and I’ve been in field for a long time, as far as being a software developer and.

[00:16:27] What I tell my students is that we really want you to go into a company that has a structure around mentorship and getting you up to speed, because I’ve actually had developers that outside of coding, boot camps, that I’ve mentored where they got a job and there’s no way they should have been put in that position.

[00:16:45] They were put in. There were no other developers and yeah. They were told Godspeed at junior level is, did not end with a success story. It never does. I actually had to go and I talk them off the ledge basically. I’m like, dude, you’re fine. This was their fault. You, you look, this is not how I would have done this.

[00:17:02] And I’m sorry I introduced this vintage of this company. So I thought that it was, they were at a different place. And then he told me what happened. I’m like, no, man, I’m really sorry, but you. You’re fine. The company the company did to you was not. So we see this, we see this in the software development field too, and I wish to say that it gets better.

[00:17:22] But I think that, that we have a lot of organizations run by run by humans and they don’t necessarily always, they’re not always the way that we want them, but optimally speaking, you would always want that, that pipeline and effect right. Where you have your senior people and then more junior people come in and there’s that mentorship.

[00:17:41] There’s always a pipeline of people coming in because unfortunately in our field and I got a feeling it’s the way in data science, too. There’s always people leaving as well as coming in. Always, you always want to have a good, you always want to have a good pipeline and you have to be a certain size company before you can actually have a pipeline of people coming in.

[00:18:00] Yeah, it’s a, I mean, it’s a huge problem. One is you have people leaving on a regular interval, right? In any, in any space like this, where. Companies are, you know, like right at this moment where certain companies are being super aggressive about going out and hiring top talent, you’re having people leave.

[00:18:28] And I think whether times are good or times are bad, it’s still going to be true. Um, and so if all of the onboarding or all of the mentoring was the responsibility of this one person who was done suddenly gone. Like, and the people that were at that person’s level are not interested in mentoring, like your mentoring program dies and the onboarding experience dies like, okay.

[00:18:56] I think to me and I actually, you know, in a perfect world, perfect world actually existed. Mmm. I would think seriously about science. Like if there’s somebody that you expect to be a mentor, And a manager. I literally try to sign them to some form of an incentivized contract to keep them around longer with escalators, with like, because what I see happen so often is okay, an individual contributor, the loss hurts, but if they were solely doing technical work, You have at least a shot at replacing them.

[00:19:34] That’s not a guarantee. You have a shop that you might replace them. If you lose a good leader who is also like, it’s so hard to get that team back in shape, it kind of throws things into disarray. Um, particularly in this space, like it puts the junior people at risk. And like, if you, like, I just I’ve seen it happen many times.

[00:19:58] Where suddenly the junior people came in with the expectation, they would be mentored by this person, that person leaves. And then the company has a whole mess on their hands because that team essentially dissolves. And if I were running a company, I’d really think carefully, like I understand competitive competitiveness that people are always going to have opportunities to leave, but I would think really hard about building a combination of culture and incentives that are going to keep people.

[00:20:27] In place for at least a period of time. Right. So they’re not bouncing out after six months. I think you make, I think you make a great point there and to bring it back to people that are listening. Cause that’s, I think that’s a great thing for ’em. Any any, uh, uh, employers that are taught, uh, might be listening.

[00:20:46] So I had a follow up question to that though. How can you, how can you as an interview E write a, um, uh, how can you identify? Mmm. If someone on your team is going to be a good mentor, when you step into that role so that you can set yourself up for success as much as possible. Yeah. That’s a good question.

[00:21:07]Um, As an interviewee, I tend to look specifically at, have they done it before? Have they done it before? Will they allow me to chat with someone who’s actually been mentored by this person before? Like I realized that sounds like an idealistic scenario, but I think from an interviewee’s standpoint, like it’s worth the investment of time to.

[00:21:35] Ask us person, right? If you interview with them, you have the five to 10 minutes of the interview, your interview, ask them how they think about mentoring, right? Like most people are gonna, you’ll be able to tell if they’ve at least thought about the question, right? If I give you some answer, that’s like, aha, that’s not accurate at all.

[00:21:58] It doesn’t work for me. It’s good. It tells you something, um, Most likely interview loop. You’re also going to probably be interviewing with someone who has been mentored by that person, right? Whether it’s a manager, if you’re talking to the tech lead of the manager, there’s very likely someone else in your interview loop that works on that team for that person.

[00:22:20] And if there’s not, then it’s also reasonable. I think particularly if you get to a final stage where they’re trying to close on you. Ask to speak with somebody that has been mentored or has experience with that person. Of course, there’s a lot of gray area and the information you’re going to get, but ask people to speak to their experience.

[00:22:45]Um, I find that it’s really illuminating. It’s often, like it’s illuminating in what people tell you. And then also what they don’t tell you, if you ask, like, what’s the best experience you’ve had working with this person and they tell you about something that doesn’t sound fun at all, that tells you a whole lot about what it’s like to work at that person.

[00:23:05] Right? I’ve often found that people, mentors who are amazing people will just go to bat for them. People can not say enough, good, positive things about somebody. If they really enjoy being mentored by that person, you just got to ask questions. Um, it’s hard, but it’s hard. It’s hard. And it’s also kind of scary, right.

[00:23:25] Particularly at a junior level. Like I’m just trying to find a job, but I, I tend to, when I work with people who are coming into this field, I tend to have them think and like, okay, I think about the potential, like we’re really bad as humans at evaluating risks. You know, COVID is a good example. Like we’re really bad at evaluating risk.

[00:23:47] When we go into thinking about a job we’re also bad at evaluating risk. Like what’s the risk. If I get into this position and it’s not good, and something goes off the rails, how does that negatively affect me later? The amount of work it takes to turn that around the amount of drain on your mental health, like.

[00:24:08] All of that is present, but I think people are not usually thinking about the risks of a role when they’re looking to join. They’re thinking like, alright, I need to get a job. So I find that to be a tough balance. Um, yeah. Oh, that was an amazing answer. I hope everyone just like goes back and like plays back a couple of last couple of minutes and like takes a bunch of notes.

[00:24:28] Cause that was awesome. What do they say? Sometimes I the same things. And I’m like, what was that again? Yeah. I don’t remember, but my thinking, my thought stream during all that was like, this is amazing. Okay. That’s funny. You’re like asking me, like, sometimes I’ll be giving presentations and then someone will ask me a question about something I said, and I’m like, What was that said by me, I’m not sure where I was going with that.

[00:24:58] What word? Okay. Hold on. Let me figure out an answer, man. So, so no, it’s a, I think it’s really cool that you talk about asking questions. Cause I think people don’t ask enough questions and that’s, that’s where, um, I mean, even down to, and I don’t know if any of my students will ever listen to this or not, but if they do, you should ask a lot more questions of us.

[00:25:21] That’s one of the things you’ve taught too. So you, you kind of know. You kind of notice, it’s like, Hey, I can almost answer anything you throw at me. And if I can’t, I can find the answer. So throw stuff at me. And then you say, Hey, see when you need help with this. And they’re like, no, we’re good. But she does not.

[00:25:40]Um, yeah, usually it’s like the person that’s brave enough to ask the questions tends to be a good signal about what kind of. What it’s like to work with them, like in an interview setting. Like there’s nothing that I’m more than I enjoy them when someone’s asking me questions where I’m just not the one firing questions directly at them.

[00:26:00] Like if someone has the confidence and the belief in themselves to interrupt me and ask a question and say like, Hey, I’m not sure. Like, what do you mean by this? Like, and the last 10 minutes of the interview, contrary to popular belief, it’s not just a formality that they give you time to ask questions.

[00:26:17] Right? It’s a. Literal chance to show that you’ve done your homework on a company, on a person, um, that you are looking out for yourself as much as they are trying to look out for themselves. It’s such a valuable five or 10 minutes that you have, but when people think about interview prep, it all goes into like how many questions that I prep for?

[00:26:41] How many, like it’s very rarely about, do I have a good list of questions? At least that’s been my own experience. So, I mean, that’s, that’s kind of where it is for a long time. I think as you get more and more senior and you know that you’re okay with the technical questions that you start getting into, um, How, how has your business run?

[00:27:01] Exactly. You know, how, how do you handle this? And that, like the last time, my last interview, I actually asked more questions and they asked of me, it actually turned into, it, turned into that as a kind of I’d had experience at another coding bootcamp. And so I actually knew all the things could go wrong.

[00:27:18] And so I started asking them, how are you handling this? How are you emailing that? And that Sergeant tool way different interview experience than having people throw. Questions at me and try to me trying to convince them that I know where they were trying to convince me that they, they were a good place for me to come work at it.

[00:27:34] And that’s, we always try to, we always try to tell our students that, that the interview is bi-directional. You need to ask questions. So you feel comfortable. It’s not about just getting your first job, although, and that’s how, tell me what you think about that. Cause right now we’re in a very different situation where competitiveness has changed a lot.

[00:27:55] So the asking questions thing and getting. Maybe what someone might consider a little more aggressive about asking questions. There may be a little fear there about letting him, I really need this job. So I want to stay quiet and just answer their questions so I can, you know, so I can get a job. But what are your thoughts on that?

[00:28:14] I think I mentioned preparing for questions for an interview that doesn’t just mean, uh, Creating a list of questions. It actually means to me asking the questions that somebody else and having them give you feedback on the tone of your question, how you asked it. How you followed up on those questions is typically, like, if you think about most of communication, it’s very rarely also you want someone who’s going to call you out and be like, that question is not something you should ask a prospective employer.

[00:28:51] Like I think I posted the other day, I’m like someone asked me, they’re like, Hey, I saw on your Facebook that you have a brother and a sister, like, don’t ask that it’s a bad idea. Like, I was like, really? Like, what else have you been watching me? Um, but in general, You should really make sure it like dry run your questions and think about the tone that you used to ask them, make sure that the wording is right.

[00:29:14] Make sure that it is relevant for the company. Um, so much of it is in the body language that you use to ask the question, right? People like hate this clinical communication, blah, blah, blah. But I can, it matters a lot. How you ask the question, how you present yourself during it, like practice sitting there, practice being confident like that.

[00:29:38] Like people feel like they’re in speech class again, and I’m like, I can tell you like the difference in impact versus where you were like, have. Thought through the question ahead of time. And you’re confident in what you’re asking versus someone who is like slouched in their seat, kind of talking near the floor total it’s day, night and day.

[00:29:56] And it’s this weird thing, but I think so many people in all of our fields, like engineering, data, science, whatever it may be. Thinking a lot about how you’re communicating and people think about that verbally, but like your nonverbal communication is super important during an interview. Um, particularly for junior levels.

[00:30:18] So the, uh, the other thing, we, we actually talk about this a lot, cause, um, we, we produced a good number of junior developers and, uh, interestingly enough, you might find this a bit interesting. We do have a data science program and you’re like, Oh man. But no, we, we do have a, we actually do have a data science program and we have some really good people in our data science program and some very good hiring that are ready to take on.

[00:30:41] For students. And, um, um, and so the thing that we always talk about is how to ask a good question. Cause you don’t want to be that that asks, uh, it asks us to be the stupidest questions. I, I hate to use that term because we always say there’s no such thing as a stupid, the only stupid question is the question not asked.

[00:31:00] Right. But there, there are times where you have, uh, You’re overstepping or you’re really, you know, that senior is trying to get something done and you could have answered that question yourself. What do you think is a, uh, uh, you have like a good set of how to ask good questions. So instead of, you know, it’s really funny, like my literal last, uh, Last LinkedIn, LinkedIn posts that I made like an hour ago, it was like ever gotten to the end of interview.

[00:31:29] And like, here’s some questions that I like to ask. Like, ironically, this is literally what I posted one hour ago. Um, so when I think about these questions, right, like what they are, why, how I, how I assess whether they’re going to be considered valuable by the employer. It’s it’s hard, but like when someone’s being inquisitive, like you want to show curiosity, you want to show curiosity in that you’re curious about what the company is doing, where they’re headed next.

[00:32:00] Like, how do you fit in to their overall vision? Because what people want when they’re deciding whether to hire you beyond technical skills and they want to feel like they can come and work with you day to day. So asking questions about how you work in a team, right? Like how do we get things done together?

[00:32:22] If there’s a big project, like how do we share responsibilities on it? If someone is sick, how do we cover for that person to make sure that things continue to go out the door at a reasonable pace? Like. I often think when you show that your questions are about you wanting to contribute and be a part of a team, anything within that domain communicates one that you are excited about the opportunity to that you think of yourself as part of a team.

[00:32:54] And almost any question within that domain is fair game. Right. It’s like, okay. So how do we work best? What has been your experience? And like, you know, mentorship falls into that, um, working as a team, how do you think about code reviews with each other? Like, how does that work? How do you make sure that when like that we make, so let’s say when a director does a review of a team, how do you make sure that.

[00:33:22] The team has done collective work that makes the manager and the team look good. Like, you know, that they’ve met their goals for that quarter. I often find that resonates with people because the communicates that you think of yourself as not just an individual, um, and that’s what they want. They want to, and also like, It’s it’s so hard to quantify.

[00:33:45] I think this is the interesting part of our interview is we want to quantify so many things, but like people just want to know that they would have a good partner to work alongside someone who could do their job. It could also be fun to work around. And that seems so basic, but it’s actually pretty complex.

[00:34:03] So ask questions that show interest that show something about your personality, right? Of course. Keep a gate on that. Don’t go to like often to left field about what questions you’re asking, but, and this again is like, if you, before you ever go interview, try these questions out in somebody else. Like if that’s the one piece of advice that you give people, ask someone else’s question and get, get their feedback.

[00:34:31] If you happen to know a hiring manager, not necessarily like a friend of yours, it’s a hiring manager. It might be really good to run that set of questions past them, just to be sure that it doesn’t, uh, it doesn’t rub them the wrong way, because that might actually be a good, I love this. I bet you just did it again.

[00:34:48] I know the past couple of minutes, we, they, people need to listen to it a couple of times, because what you just said is we’ve got some gold in here. Yeah, I’m putting that in the show notes. Actually it comes from experience. Like, I think where people, I mean, this is also something that when you’re trying to enter into this area, whatever it might be like, you should use each experience to try to learn something from like, if you had a bad interview, don’t just like block it out, figure out like what went wrong.

[00:35:22]Um, Sometimes the recruiter will give you feedback sometimes not, but like after I interview, I usually go out to my car and I like do a voice recording of what I thought about the interview, um, for like 10 minutes, mostly because that’s the only time I’m ever going to remember what actually happened that day, because then you get tired.

[00:35:41]Um, but it’s actually interesting to go back and listen to like the recording I did after my interview at LinkedIn. Versus after my interview at some other places that just didn’t go as well. I pretty much knew what happened at that, like right after, but I think what’s different is like a day removed.

[00:36:05] Be like, okay, that went well or that didn’t. But if you do it immediately after you often know exactly the details about what went well and what didn’t, if they later, you’re not going to remember what, what happened. I love that idea of doing like a postmortem and trying to figure out what, what, what went well or what went wrong and recording out.

[00:36:24] It’s really great. And cool thing about it. Well, Oh, I was gonna say the cool thing about that. And I didn’t mean to, I didn’t mean to interrupt you, Tyler, but. I wanted to throw this in there. The really cool thing about doing that, that post-mortem right then is that you can use that as like a hypothesis as to the result of your interview and have recorded that and then get the results later, which is really cool and learning, uh, how you know, learning about even your ability to estimate.

[00:36:55] How, you know, to hypothesize about how well something went. Um, I, that’s amazing. I never really thought about doing it right then. There’s all these memories I’ve got over the years of interviews in my head and I don’t, you know, I know how we, I, you know, we rewrite memories as we bring them out. So it’s a think about them.

[00:37:15] And so I look back down, it’s been so cool. If I’d had just a five minute. Five minute video or recording about these interviews that I remember that went so terribly wrong. I know, just because I say record doesn’t mean it’s a positive thing sometimes it’s like, you can tell that you were traumatized.

[00:37:37] Like I didn’t. I remember the first time that I, I went into this was with, with Amazon years ago and it was. At the time where they were still figuring out their fields of data scientist, applied scientists, research, scientists, differentiated the job title. Well applied scientists. How elite code hards are like a norm and I was not ready in any way, shape or form.

[00:38:02] Right. So I walked in and they’re like, we’re doing like these things that I now recognize as like weak code, hard questions at the moment. I just wanted to cry my interview tape after that was like, this is the worst day ever. I don’t know anything, but at the same time, there’s really positive experiences too.

[00:38:20] And like, it can be really informative. Just from like a, you know, I’ve probably done. I think probably in my life, I’ve been probably like 40 to 45 onsite interviews now. And I have recordings for at least like 35 of them. And it’s weird. And like, but you learn from it. Um, I just hope I don’t lose my phone I’m I started in the cloud now, so I’ll have them forever.

[00:38:46] They got him. I got to make sure to back them up. Um, so I think, uh, I think I want to say to another, another really important question, and I think it’s one I’ve kind of had before, or at least I’ve thought about is how can you transition as a, as a junior or mid level software developer into. Data science or data analytics or whatever one of these titles is.

[00:39:06] Right. How do you, um, so how can you do that? And, and what are the, what are the, um, character, character traits that might make someone, um, uh, a good, uh, candidate for transitioning over from software web development, into data science or data analytics? I think that’s a good question. Um,

[00:39:23]I’m just going to go off of experiences that I’ve actually seen. Like there’s what I think. And there’s what I’ve actually seen. I think they’re a little bit different. Um, I’ve found, I’ve seen it be very challenging for people to go entirely from like software dev into like an analytics role. Um, and by that, I mean, where they’re literally just running, they’re doing basically deep data investigations.

[00:39:47] From coming from a software dev side. I don’t know why. Maybe it’s just like my own bias and who I’ve interacted with, but I’ve seen far fewer people be interested and successful in that specific transition. What I typically see is software devs are thinking. About issues of scalability, they’re thinking about issues of user experience.

[00:40:12] And so when you think about one of the most common transitions right now, is people going into, um, ML engineer roles, because what’s what that is all about. It’s less about the analytics. It’s less about the data analysis. It’s more about figuring out how you deploy a complex Oliver algorithm at scale.

[00:40:35] Without having a bring down the user experience, right? How do you ship something at scale? How do you put it in? Um, how do you serve it up? How do you create recommendations in a way that is going to not disrupt the user experience? And so, because the most successful ML engineers, if you look at most roles that I’ve seen, they come from software engineering, that’s much more rare.

[00:41:00] At least from what I’ve observed again, this is my own bias. I play as much rare for a data scientist to go into an ML engineer role than it is for a software dev to go into an ML engineer role. Mostly because I think the way that software engineers tend to think yeah. Is really well suited to that type of transition.

[00:41:23] Okay. If you’re thinking about going wholesale, like I want to get into data science, like to me, The thing that defines someone, making that transition is really like, do you understand statistics and data visualization? Like those two things are paramount when it comes to that transition. Um, if you don’t enjoy statistics and data visualization and like a typical data science role is probably not going to be something that.

[00:41:55] You’re going to enjoy, um, if you still want to focus on our lives and deployments, like a more heavy engineering side can more heavy engineering role can be really valuable. That’s another thing I was going to ask because, um, today you don’t have to really be great at math to be a software developer software engineer, depending on where you’re working.

[00:42:15] Right. Or web developer. Um, like I’m not very good at math. So would you say like, would you have to be really good at math? Or could you just be like math being like, you have a really. Like, you know, you’ve gone into like discrete math and all this other different stuff. Or do you just have to give, be good at statistics and individualization?

[00:42:33] Can you just be good at a subsection of math? Cause you’re, you’re an expert. Like that’s my buddy. I mean, my expertise is in like theory and probability and stats, right? Like, and the mathematics behind it, but you don’t need that. Like, you don’t need that to be successful in these roles. You need to be able.

[00:42:53] Like quantitative reasoning. Like you need to be able to think creatively about problems. You need to like, if you were like a tenacious problem solver, math is a one component of that, but it’s rarely the only thing it’s like, I would say that math doesn’t differentiate. Good from great or great from good math is just something like, you’re probably not going to use math.

[00:43:19] That’s extraordinarily complex, almost ever. Um, when it gets into more advanced role, like statistics, like statistics, people think it’s like all about numbers. Statistics is more about how you interpret the numbers, how you create an experiment and then interpret the results in a way that’s meaningful.

[00:43:38] The math is typically abstracted away and the software at this point, like the actual calculations, the number of times I’ve done like a hand calculation or some mathematical thing by hand is almost zero. Like you start to think, like you offload a lot of the deep mathematics too. Um, statistical programs.

[00:44:02] And so that’s why, where I see a lot of value in things like learning how to do an R or in Python, um, because you can offload a lot of the heavier mathematics to focus on the interpretation and it’s that interpretation and understanding of the context that you’re in, that typically makes or break someone’s success in this field.

[00:44:23] So is this true with both machine learning and with just data science in general and, okay, so this is another good conversation, I think, to be excellent. And like, if you’re really going to be focusing on machine learning, um, there are two camps here. There are a lot of people who just apply machine learning algorithms and look at the results of applying those algorithms.

[00:44:51] That to me is how do I describe it? It’s not an ideal situation because what’s happening is that, I mean, if you think about it, they’re effectively just picking 10 tools up and they’re hitting the same problem with this tool 10 different times. And they’re like, which one of these produces the most positive result?

[00:45:13] When most of the interesting stuff is actually in why it produces. The result that it does, right? Like why did this technique perform better than this one? Why like, and over time you hone your skills so that, you know what technique is probably most apt for that problem. That’s where you start to get into more in mathematics where you start to really think about, um, Like were actual calculus and actual like rates of change and how you search for optimal solutions actually comes into play.

[00:45:45] But to be quite honest, with most data science roles right now come, and this is something that I actually considered to be a negative. The algorithms are more or less as something people. Click run on rather than something they think about carefully designing. And that actually produces a lot of P a lot of algorithms being built and a lot less understanding of why they’re doing what they’re doing.

[00:46:12] So think about what could happen if like, so a good example right now is. With, um, basically with COVID happening a lot of productional production machine learning algorithms that basically look at recency of user behavior to generate recommendations and predictions. They all just broke because people’s behavior completely changed.

[00:46:37] And so they were, the models were more longer term tuned on user behavior. That made sense. In this time or in this moment, but for someone who’s just building an algorithm and just applying the algorithm, like the mathematics of why that happened, wouldn’t make sense. And so to me, like this field is so deep, there’s so much here.

[00:47:02] That it’s more about figuring out where you’re going to dip your toe in the water, then like trying to do everything at once. Like you’re not going to be good at everything you need to start somewhere. And like that is, I think there’s different entry points into that. I think that’s, I think he touched on it and I might be speaking over, uh, Doug.

[00:47:21] Cause I know he has something he wants to touch on, but I think what you just touched on is really interesting. Cause I think that that is probably one of the keys of moving into setting up your career is, is going deep. And how, how do these things work versus, you know, can I use them. Right. Like understanding the algorithms behind them.

[00:47:39] If you want to go into machine learning and stuff like that. If I’m using the right terminology, I’m probably looking like getting idiot right now. Um, I’ll, uh, I’ll defer to, uh, uh, Doug as we wrap up here. Cool. So, no, I was gonna, I was gonna say that to our developer audience, uh, Eric, what you just said makes a lot of sense, even in our field too, because what happens is, as we’re learning things sometimes, and I’ve watched junior developers come in and they’ll poppy some, uh, some code off of stack overflow and paste it into their program.

[00:48:10] And then, then they’ll come get me and say, Hey. And this is not even a student. This is actually, this happened to me at a company that I believe it, it just kind of comes to kids and says, Hey, this Coast’s not working. Why is it not working? Stack overflow says it’s supposed to work. And I’m like, um, okay.

[00:48:27] So first of all, let’s take a look at the code and scan it line by line. So. Uh, you know, it, it, it turned out it like, like he took this wholesale copy and pasted it and expected it to even with the variables and everything that they had in there. And it’s like, Oh, this is supposed to give you an idea of how to solve the problem.

[00:48:44] This isn’t the actual coach who used to solve the problem. And it kind of reminded me when you said, when she said about, about people just using the algorithms without understanding it. Stack overflow could be its own discussion of a show, man. That is a, but yeah, it’s a, go ahead. We’ll just say we’re going to have one, one day.

[00:49:06] I don’t know. I mean, it’s tough because in a lot of ways that’s how people, like there’s a lot of informal learning routes into this field and there’s no like. There’s very few people that are like, these are best practices. Like people are kind of hacking and figuring out how to get there. And like this seems to work for this person.

[00:49:28] So I’m going to fork this person’s repo and get hub and like, I’m going to use their code and look, and then suddenly you permeate all of these really bad practices and they’ve spread across and, and it gets into, and so I really take seriously, like, The idea of accrediting, um, bootcamps and places that are training people, because I think there’s a lot of, um, it’s tough.

[00:49:59] We’re turning out people in some cases with the right skills. In some cases they’re being promised something. That’s not going to get them to the right spot. That’s frustrating from a personal level because they’ve invested a lot of time and money and then they like, Oh wait, I’m not actually ready. I know exactly where you’re coming from.

[00:50:16] The, uh, the one thing I will say about where I went to go work is that they really had, uh, I was on the fence about going back into working at a coding boot camp. And, uh, they really had to convince me they had a good program and I still firmly believe that they do, um, where I went to go work. So, uh, we, we even take, uh, we’re able to take VA money in there.

[00:50:35] They’re in the process of accreditation. Even now they’re working on trying to get to that point of actually being able to have an EDU domain and stuff like that. So they really take it seriously. It’s a really good program, but you’re right. It’s it is so much all over the place that, that as far as coding boot camps are concerned, we can, we could do a show on coding boot camps.

[00:50:57] Yes. Oh, that’s a whole conversation in itself.

[00:51:03] Yeah. So Eric, it’s been a, a word. Uh, I know we’re short on time here. It’s been a pleasure to talk to you so far was, uh, we got a few minutes left. Is there anything else that we should have asked you that we haven’t asked you yet? I’d like to ask that. I think it’s a, I think what I’ve learned in this space is anyone who says anything definitive about what data science is or isn’t.

[00:51:29] Is just trying to, like, they’re just making a statement in the moment. I actually don’t think it’s super helpful to try to make those determinations right now because companies are still learning. They’re trying to figure out what’s going on. They’re trying to figure out what the lines are like as data science and engineering practice.

[00:51:47] Is it its own practice. I don’t necessarily know. And so I think people want this want to accelerate its development when it’s actually okay. It’s okay. That it’s developing and weird ways that don’t make sense. And the titling is messed up because companies aren’t going to change unless they see something that’s not working for them.

[00:52:11] And that takes time. Like, but you know, we’re not very good at patients in general. I’m not going to patients. I’m like, we needed to find this needs to be perfect, but realistically it’s not necessarily a bad thing. It’s just like, it’s the development of any field. It takes time. And what data sciences 10 years from now is going to look a lot different than what it is now.

[00:52:33] And that’s okay. We just have to wait and be actively thinking about those things. Or we’re all having, we’re all having growing pains. Right. All men is only about seven years old and you know, other fields are a lot, a lot older, you know? So, uh, it’s, it’s interesting to see, and it’s been really cool to get your perspective on this stuff, cause I’m definitely, I know know very little about data science.

[00:52:57] So been really neat to, to hear about that. What’s the best way people can connect with you. Eric, I’d have to say like LinkedIn is my centralized place. Find me there. Um, send me a message. I can’t promise that I return it that same day. Um, but I try to be really active, um, in responding and making sure that we take care of, um, That I, you know, get back to you as much as I can provide what insight I can.

[00:53:22]Um, I tend to post pretty frequently, especially during lockdown because I find my mind is just like spinning and I have all these ideas. So interact with interactively there. Also, if you see me posting like. Post questions or responses. Like you’d be amazed at how many people in this community want to talk about things and they just want to have good discussions, um, jump in and you’ll see a lot of really interesting feedback.

[00:53:48] You got some off the hook posts of like thousands and thousands of a response every now and then it’s really weird. I’m like sometimes I wake up and I’m like, Oh, I shouldn’t have said that because I literally try to respond to every comment. And sometimes I wake up and realize that. My morning is going to be shot to like, try to respond.

[00:54:09] But it’s fun. It’s also this really good experience. Cause I think it’s a two way street, right? You’re going to have engage people when you show that you’re engaged and are willing to learn from them. Awesome. Well, thanks so much again, Eric and we’ll we’ll uh, we’ll be connecting with you and commenting on LinkedIn too.

[00:54:27] All sounds good. And thanks guys.

Junior to Senior Dev: Episode 3 – Code Katas and Memorizing Syntax as a Developer

  • Code Katas Useful?
  • Declarative vs Procedural Knowledge
  • Should We Memorize Syntax and APIs?
  • Are Certifications Any Good?
  • Being A Well Rounded Developer
  • Assessing a Developer’s Ability
  • Jobs Without Whiteboard Interviews

Make It Stick – https://amzn.to/3hm9d2C

Anki – https://apps.ankiweb.net/

How to Teach like a champion 2.0 l – https://amzn.to/37qN3Yr







Recent Posts