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

Links:

https://timeflip.io/

toggl.com

https://www.rescuetime.com

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.