From the ExperiencedDevs subreddit, this topic was focused on how our values change as programmers over time. I thought this would be a fun one to talk through, and I'd love to hear from you on it too!
📄 Auto-Generated Transcript ▾
Transcript is auto-generated and may contain errors.
Hey folks, it is Friday. I'm headed to the office. It's pretty late. I started work from home, but I also did a podcast this morning that went a little bit over, so I'm a little behind. We have a morale event today. Um, so we're going axe throwing, so I'm pumped for that. And, uh, I went to experience devs for this topic. I thought this would be a really fun one. And this person, Could they go any slower? probably not. They're all they're on their phone. That's good. Good stuff. Um I think this is one of those kind of topics that like would love to hear from you in the comments your thoughts because I think everyone will have a different sort of take on this, but the topic is what are things that you care about cared about as a junior developer that um maybe now as a more senior developer that you don't care about?
like how has it changed? What have you the things you cared about? How do they has that prioritization changed? And I would say too if you are a junior developer right now and you can't do the the inverse, right? Like how has that changed for later? Maybe like if you're still worth or still willing to comment, I think it'd be worth sharing like what are things that you value right now as a junior developer? And I I don't know. I didn't read through the thread. I kind of got too excited and started driving. Um, I don't know if they mean like in your career or if they mean like I'm assuming it's more about like the the software you're building. Maybe not. So, maybe we can look at it from a few different angles. So, I might talk about things in this drive that are like what I value in my career.
Maybe things that like what I value when I'm writing code or building software in general. Maybe to kick things off, I'll talk about uh career because I've done a bunch of videos like this and it's a little bit more fresh. So, um with that said, if you are interested in having your questions answered, please leave them below in the comments or send them into Devleer on social media. That is my main YouTube channel as well, but I go by Devleer on every platform. LinkedIn, it's just Nick Causantino. the code.com website will be taking questions soon. I should probably do that over this weekend. Cool stuff. Okay, so career-wise, I think I think what I valued was I I liked the idea of like I wanted to be an investment for my future financially. I think is probably the thing that I cared about the most. Right?
So, I didn't like the idea of big tech companies. So, maybe there's something built in there where I like I wanted to feel like I wanted to feel like my work could be more significant or felt more broadly within the company. So that feeling of impact, but I think that I was really thinking like, hey, look, if I if I invest myself now and like that delayed gratification, maybe this could be like way bigger later, right? And I I think probably in my mind, I knew that I had classmates and stuff from university that were going to Silicon Valley, working at these bigger companies, and I'm like, I know they're going to be getting paid more than me, without a doubt. But I think my thought process was probably like it's probably a bigger paycheck, but I'm hoping that I can get like a bit of a home run.
And I think again I'm I'm kind of doing this reflection for the first time. So um I don't think that I was ready. I'm still not ready to like to build my own company. I I would love to, but I don't think that I'm like ready for that kind of risk. I probably would have been able to take on much more risk then uh versus now I I do have a wife and you know like that is a sort of a responsibility that I have and I I think that it was a fortunate circumstance for me where I joined a startup that was very early stage and I was like it's not It's not my company, but I am in early and if this does really well, that could be that could be the thing. But I think this is like a big focus for me.
And I think that that probably I don't want to say that went away. Like I would still love to to have like a home run where I could make a ton of money and then be able to kind of build and work on whatever I want to work on because I love to build software. It's never going to go away. I don't know if I'll ever actually retire, right? So, I don't I think the part of that that's changed though is that um like right now being able to work in big tech like the pay is is good and the people you know have different opinions on this but sort of that that risk factor I feel like is different. I don't have to go guess I better find a startup and try to hit a home run. I can say like like let me focus on on something that's a little bit more steady.
Now I I understand with layoffs and things like that. Um so I I don't mean to make a claim that like it's uh it's bulletproof, but the odds of me joining a startup and then hoping that it becomes a unicorn or like it's not it's not realistic. Now I did screw up because the place that I was at uh they did IPO after I left. They did get bought back to private for$2 billion dollars. Um, so that was a bit of a Canadian unicorn and I absolutely missed out on that which is quite unfortunate. But younger Nick, younger Nick I think made a good decision in terms of like that was uh probably, you know, one of the best opportunities that I I could have ever done uh for that that point in my life.
So, I think that was something I valued though was wanting to have this deferred gratification if I can, you know, put a lot of time and energy while I'm younger and then maybe when my like my early adult early mid adult life, I don't know, my early older years, I don't know, my 40s, I don't know what what age range really, but then I could be like, hey, like I have this kind of financial freedom to go focus on what I want. So, I think career-wise that's changed. Uh, and now it's more stability is really important for me. Stability. Um, like the the I'll be transparent like the money thing is not going away. I'm not ever unless I have enough money that I don't have to work. I'm never going to say like, you know, more money is not helpful. It absolutely is at this point in my life.
and for how much sort of wealth I have. So I'm not not ashamed to say that that is a important part for me. Now what else is important though like right now given that I work in big tech I don't know like I'm not super proud of this I guess but like career progression and moving up is like is really important because if I want to continue to work in big tech that is the only way that like progress is measured unfortunately. So, if I want to be given more responsibilities and have more impact in a company, I literally need to keep doing that. I need to be able to get promoted. So, I've talked about this in other videos, but like I have been a middle manager for almost 13 years now, almost my entire professional career, excluding my internships. And uh I have never got to a point where I've managed managers.
That's sort of like the next progression. And I have managed other people that are directors now. They get to manage other people. So I I have hit like this what feels like a wall in my career, especially coming into big tech. And um I'm like the the only the only way that I understand in big tech how to get past that is like I need to be promoted and I need to be given that opportunity because I'm not going to be hired externally there. I don't know of any company that's hiring externally where they're going to take a manager and put them into like a a senior manager position to manage other managers unless they've done it. So I like inevitably have no choice but to focus on sort of like that kind of career progression if I want those types of responsibilities and I do I do want that in my sort of like uh traditional career path.
So that is a thing right now I prioritize and I think again when I was uh you know junior early in my career wouldn't have given two shits about that right I'm just I'm here to build awesome stuff and uh hopefully hopefully we kick ass in the future right and we can all retire early or have the financial freedom to do so. Um, from a maybe from like a project perspective, I I'm not sure what I really cared about when I was more junior to be honest. Like I think Okay, maybe outside of work. Again, I'm doing this thought experiment for the first time. Buddy, come on. Get out of here. Um, I think I really liked kind of like reinventing the wheel. Like I loved building things that already existed so I could experiment and I could learn about it. And I say that like my intention was never, oh, I'm going to build my own and it will be better.
It was literally like I want to I want to build my own because I'm curious. So like I had built like messaging libraries, so using sockets directly and like being able to set up different messaging protocols, like basically building what would be like Protobuff, but like a really crappy version of that, of course. Um, so had a lot of fun doing that. I did a lot of Windforms development. So when I was trying to make my own little games, I actually I was like, I'm going to build my own UI framework. I've worked a lot with windforms. I know about how a lot of this stuff has been designed in Windforms. I could I could make my own. So, I spent a lot of time doing that, right? Like there's a lot of things that there's probably offtheshelf things that existed or they exist now for sure.
And I just wanted to kind of build build my own because it was fun and um got to learn a lot. So, I think I really valued that. Um, you know, there I It's weird. I'm trying to think about this kind of thing cuz I used to spend I've always loved to program. Um, like once I learned how it was like I love doing it and I'm trying to think there were must have been times where like you know building like a UI framework like I would just like wake up and like be building a UI framework and then go to bed still working on it and I'd have like a bit of a like a little notebook where I'm like oh these are the new features I want to add or like I I finally figured out how to solve this problem. So, I'd make a note on it and then like go back to tackling it and it would be like I don't know like borderline obsessive.
I think my I'm just going to throw this out there. My wife is a therapist and she's over the past year or so she's like calling out these things where she's like I think I think you may have ADHD and like it keeps kind of coming up in these various forms. I don't know enough about it to be able to comment. Um, but based on a couple things that she's called out for me like I, you know, very, uh, naively assume that ADHD was like, you cannot focus. You're jumping around doing tons of things. And again, apologies if I don't have this correct. My understanding is that she's let me know that it can actually look very different where you like you hyperfocus on very very specific things. And um like I I actually do that like with everything like from the food I eat to like if I want to play a video game, it's like that's all I'm doing.
Um, so anyway, maybe I should go get that investigated cuz that could be interesting to learn about. But I would do this kind of thing, building hobby projects and um I just love to do that. Like that was my my focus. Like where was I going with that? I don't know. And then the more I was building, the more I was like, hey, I I'm building a similar thing. like I need to go build my own library of like things that I'm using. So, I was like kind of obsessed with doing that. And I think now now absolutely not. I wouldn't spend an ounce of time trying to build my own thing. There's been a couple of times um more recently uh where I have tried a little bit because it's fun, but I think that if I'm trying to build anything meaningful, I probably shouldn't spend my time doing that.
two things I can think of recently. Uh my sort of failed thing that I was trying before brand ghost was called meal coach and I was building my own um I don't like using entity framework core so I was building my own like like SQL translator um to use filters because I had done something similar at work before we didn't use entity framework core and um I wanted to go build that and build in like my own custom caching and paging stuff cuz it was interesting to me and um like that was probably a sign where like I was focused on the wrong things in that project. I really just needed to be like stop coding go try to sell. So good reminder.
And I think another thing was I was building um a little digital forensics thing where I was trying to recover pictures and videos for a friend and I was like, "Hey, like I spent 8 years building digital forensics tools." So, uh I'm like I know how to build my own from scratch. And as I was building this to recover their uh like from their family computer their pictures and videos, I was like, I'm going to I got very interested in seeing if I could go do like allocation or low allocation um like large file streaming with seeking and stuff like that. I'm actually very interested in playing with that more. I just do not have time at all. like there's no use case that I have for that. But just to elaborate, what I would love to build as a little library is the ability to open up a stream.
Ideally, it's like it doesn't matter what is underneath. if it's like a file on a network, if it's a network stream, if it is a file locally, um it gets way more complicated when it's not a local file. But the ability that you can open up this stream and um search across it uh with different patterns very effectively. So, low memory usage, the ability to basically um dynamically as you're searching, you can adjust like memory thresholds and uh sort of dynamically throttle if you will. So based on how much CPU is being used, how much memory is being used, your your read speed uh from the data source that you can dynamically adjust um how parallel you can run your search algorithm across the data set. And I'm like fascinated by that.
I would love to do that and build something that's like like a rocket ship for searching across data like that in a stream, but I there is no there is no incentive to do that aside from curiosity and I have other things that are kind of pulling my attention. But other than those things, like if I'm building like in Brand Ghost, I'm not building anything from scratch like that. No, ain't nobody got time for that. So my priorities have definitely shifted on that. I'm much more interested in trying to solve problems in the projects and stuff I'm building. All right. So it's a little bit less about the curiosity and more about the can I can I ship something that people will pay for. Much more of an interest in that. I think my curiosity gets settled uh or satisfied sorry in terms of like my content creation.
I go research topics, right? Make videos on them, short tutorials, and then I can find ways that I'm incorporating them myself. So, that's mostly how my curiosity gets satisfied now. So, that's that's that. Um, I want to talk about like coding practices and stuff, too. I think that really early on I didn't care about testing at all. Probably like most people that program I got to get around the Teslas that are going under the speed limit in the fast lane. Um, yeah, I didn't care about testing at all and then I don't know, pretty early in my career was like, oh, like that's why we test and was like very very focused on what I would call like true unit tests. Um, and people can debate this all they want. I don't like the nomenclature. I don't have time or I just don't give enough of a to to debate this kind of thing on the internet anymore.
But just for what it's worth, my definition when I say a true unit test, I mean like you have no other dependencies that you're working with. So if you have your objectoriented code, that's how I write my software and like I am mocking out if I'm doing a a test on a a method. Any other class that I have to interface with is mocked out. And I love writing tests this way because I could get like surgical in my test coverage. I have a scenario. Cool. I like I know that writing tests this way I can get like hyper specific and I love to do it and it it got me to write code in a different way like the way I wrote or I write code today is because of that and now I actually don't value writing tests like that and the reason is that I think in the time that I've been writing code and writing tests for my code.
Um, our ability to test other dependencies has been dramatically improved. Like I can spin up a Docker container. It's a really nice car. Um, I can spin up a Docker container with a database in like seconds and you know run tests against a real database. Why am like why mock it? I'm gonna mock my query against a database and then what am I asserting that like the the query string looks proper? Like I don't know. It seems like so little value versus using the real thing has tons of value. Um so I think that the the testing tools we have have come so far that I just don't value writing unit tests that way as much anymore. With that said, because of how I write my code now, if there is a situation where I'm like, "Oh crap," I really want to test like some complex logic in something, I know exactly how to do that with little effort because my code is generally already written that way.
So to go after into that code, add the tests is like most of the time trivial. I had a recent example. Um, I'm going to talk about Brand Ghost for just a second here. I was adding support into Brand Ghost where you can tweet to a community. So, Twitter has communities that you can send uh send your tweets to. And the the code that I needed to touch uh I was very nervous that I was going to break all the Twitter functionality. And I was like, I'm nervous because I had to go change the the request to the Twitter API, but um but I don't have tests over that. I have tests over my like database access and some other things like authentication, but I don't have it over that part. So I said, "Okay, no problem, Nick. You've been here a million times. Go write your tests over it.
You're good to go." And I realized that I had a situation where one of my dependencies needed to be mocked because it's going to go talk to the Twitter API. You don't want to be doing that when you're running your tests. So I went, okay, like I I've been here a million times. Let me refactor this thing out. Let me put my interface in place. I can mock that dependency out. So, you know, it still comes up where I need to have that kind of control, but um I I find that thanks to when I was more junior and focused on this way of writing code that it stuck with me and it's enabled me to be effective in these situations now. So, what else? Um when I was really junior, um nothing was modular. Right? I like first programs I was writing were like thousands of lines long um to do not a lot of work.
So you know copy pasted code absolutely everywhere because I think it was more just interesting to see things working right. I'm building small things. Let me just see them work. I don't know any better. And like it's kind of some of the stuff that I would be creating especially that early was like I don't know it's got a it's got a shelf life for sure and it's got a limited set of features that it will ever have so who cares right who cares if the code is good I don't even know how to measure good code so let me just make something work and um obviously this is probably the case for many people but over time from building more and more software and realizing that most of the time we're building stuff that doesn't actually have like a, you know, a goalpost of everything's done.
There's always work to do on it, always new features or enhancements or optimizations or bug fixes. Like if that is the more common mode that we're in, then it makes more sense to think about extensibility as you're building things. And uh I was actually at the podcast I was doing this morning. I was talking with uh a staff engineer at Google um and he was kind of bringing up this point right where like this is a factor like the more more soft the more times you've seen in your career and like software that you're building where you're like okay like I want to make sure that this has a a shelf life for many years down the road. like the way he kind of described it was like where do you want to put your cut points?
How much granularity do you want to be able to say like I can swap this part out like down from the function level up to like entire like you know microservices being swapped out kind of thing like where do you want to slice and dice because having that understanding and like it's not going to be the same for every project and every scenario. So just that thought process is really valuable and um I think that's something I value a lot now is trying to build modular flexible code probably to a fault to be honest like I probably overdo that. Um you know people will say like you know the way that you're writing your code why do you give a crap about trying to be able to like you're using a repository pattern.
who cares like you know you're using Postgress like you're not going to switch your database and I'm like okay yeah like sure but what if right so so by default I I just like building software that has that built in but um I think for me it's um it doesn't feel like much extra effort at all like 99% of the time if it did I I changed my mind, but I think I hear a lot of people complain about it that it's so much extra abstraction and it's wasteful. And I'm going like I it doesn't feel like it's extra work. Like there's people online that will freak out about like adding interfaces to things because it's like it's an extra layer of abstraction. I'm like, dude, it takes like literally like like 1.5 seconds in the IDE to rightclick and say extract interface. It's probably a keyboard shortcut.
Like, you're telling me that that's too much abstraction and too much overhead for you? Like, I I don't I just don't understand. Um, so there's like these things that I do to this day um because I'm thinking like, hey, that could help, you know, I'm decoupling from the actual implementation. How much, you know, TBD, but it's at least a step forward. So sometimes I'm doing that and it's just because in my mind that's what I'm prioritizing. So, that's something that's probably changed over time and uh maybe it's worth revisiting like how much I do on that because I said it's probably to a full. But yeah, I'm almost at the office so I'll probably wrap this up. But those are a handful of different things and that's totally off the top of my head. I gave this uh approximately zero thought before I started. It just seemed like it would be a fun topic to try and go through.
I don't know. I'll probably get out of the car and be like, "Oh crap, I should have talked about this and that." But that's why I'll give you another reminder like would love to hear from you in the comments like what stuff when you were junior did you really value as a software developer and now that you're later in your career like how has that changed? And uh if you are more junior like no worries like what what are the things that like maybe you're hearing about them online or you're applying them now and you're like I see a lot of value in this. Um there's I I don't want anyone to be like that's right or wrong or whatever. It's like these are all just our lived experiences, right? Um I think it's cool to talk about them. We get to learn from each other.
So, if you're comfortable sharing, I would love to hear it and I'm sure other people would get a lot of value. And uh what else? Let me let me kind of pitch you guys on a few things before I park. But um I mentioned my main channel, Dev Leader. That is my main YouTube channel. Um there are C tutorials there if you want to learn like stuff in C. There is a podcast there where I interview other software engineers. You get to hear about their career journeys and stuff like that. There's resume reviews there. I am behind on my resume reviews. Also, my video editor is uh away for a little bit. He's got some some things that he's taking care of. So, he had he just let me know the other day. He's like, I'm going to be behind. Um which is fine. I'm, you know, I I can still make videos.
I'm not going to edit them myself. if I don't want to do that anymore. So, I might be a little slow on the main channel, but I I'll be making the videos at least and then following up to post them. But, uh, resume reviews are coming, just a little behind. They're totally free for you. They cost me money. And if you submit them, I keep you anonymous and I will do my best to give you um my genuine feedback, right? Stuff that I think works well, stuff that maybe doesn't. No roasting. I'm not going to make fun of your resume. Nothing like that. I refuse to do that. I've had people ask me to roast their resume and I say no. So, we'll give you feedback on it, but I'm not going to make fun of you because I don't think that's fair. um mentioned the codecommute.com website.
Um I don't know like maybe I should ask like do you guys want to see other stuff on that? I don't know what else I'm I'm vibe coding the entire thing for what it's worth. Entire thing is going to be vibe coded. What's up right now is already vibe coded and I'm making YouTube videos to show it. So let me know. That's where the questions will be submitted in the future though. So thanks so much. I'm going to go throw some axes. See you next time.
Frequently Asked Questions
These Q&A summaries are AI-generated from the video transcript and may not reflect my exact wording. Watch the video for the full context.
- How have my career priorities changed from being a junior developer to now?
- As a junior developer, I cared most about investing in my future financially and having a significant impact within a company, often favoring early-stage startups for potential home runs. Now, I prioritize stability and career progression, especially in big tech, where promotions are necessary for increased responsibilities and impact. While financial goals remain important, I focus more on steady growth rather than high-risk ventures.
- How has my approach to building software projects evolved over time?
- When I was more junior, I enjoyed reinventing the wheel by building things from scratch to satisfy my curiosity and learn deeply, like creating my own UI frameworks or messaging libraries. Nowadays, I rarely build things from scratch unless it's for fun or a specific interest, because I prioritize shipping meaningful projects that people will pay for. My focus has shifted from curiosity-driven coding to solving real problems efficiently.
- What changes have I made in my coding and testing practices since starting out?
- Early in my career, I didn't care about testing, but then I focused heavily on writing true unit tests with mocked dependencies to get precise coverage. Over time, as testing tools improved, I value integration tests using real dependencies more than isolated unit tests. However, my earlier focus on modular code and testability still helps me quickly add tests when needed, making me effective at maintaining and extending code.