Looking Back on 20+ Years of Programming
Dev Leader Weekly 100
TL; DR:
Welcome to issue #100!
Your values will change over time.
Join me on Monday, June 30th at 7:00 PM Pacific for a livestream (or check out the recording!)
Holy Crap! 100 Issues!
It feels like just yesterday I started Dev Leader...
Just kidding. It's been ages. Almost 12 years, actually.
But things weren't always like this:
I didn't have a newsletter back in 2013
I didn't post to a YouTube channel
LinkedIn was some site I'd check once every quarter
Instagram? TikTok? Twitter? Pfft... I had Facebook, thank you very much.
But I had my blog, and I had a goal: Nobody knows what the heck they're doing when they transition to engineering management as an individual contributor, and I'm going to do my best to share what I learn.
12 years ago I gave up. It took a decade before I picked it back up and told myself I wasn't going to stop.
Why?
What we value in life changes as we gain different experiences. We grow. What I value now is different than what I valued back when I was first exploring my career as a software engineer and trying to figure out how to lead teams.
And what a great opportunity, since this week's top video on Code Commute was about reflecting on how things we value as developers change throughout our career:
Junior Developer Values
Let’s rewind to the early days of your software career.
Remember what felt important?
Maybe it was:
Choosing the right language
Perfecting your text editor setup
Getting your code running using that shiny new framework
For me? I was obsessed with building my own libraries, frameworks, and (crappy) games from scratch -- not because it was efficient, but because it was fun. I loved trying to "take things apart" and understand them by building them myself.
Fast forward a few years, a few broken builds, a few shipped products, and a few team changes... You might find what you care about looks different.
As you read through, I'd encourage you to think about where you're at in your career:
If you're just getting started, take a note of the things you get excited about now.
If you're further along in your career, join me in the reflection process!
Career Goals: From Big Dreams to Practical Clarity
When you’re just starting out, it’s easy to romanticize the startup dream.
Early-career Nick thought a lot about delayed gratification -- the idea that grinding at a scrappy startup could pay off in a big way down the line. The gamble was clear: invest in yourself now, and hope for a home run later.
What did that mean in practice?
Taking on high-risk opportunities in hopes of a big exit
Valuing long-term impact over short-term rewards
Hoping that passion and effort alone would unlock future freedom
These days, the goals look a little different.
Now, stability matters more.
The idea of betting everything on a high-risk venture doesn’t feel as exciting when you’ve got real responsibilities.
That doesn’t mean ambition disappears. It means the way you pursue it becomes more focused.
These days I have a responsibility to my wife and our animals -- I can't take the same sorts of risks with my time and finances. But that doesn't mean I don't have my dreams still!
Actionable Tip:
If you're early in your career, don’t confuse passion with direction. Document what motivates you:
Wealth?
Impact?
Recognition?
Freedom?
Then track how those motivations shift every 6-12 months. You’ll start to see patterns that help you make better decisions. And they WILL change over time.
Big Tech: Titles, Influence, and Realities
Let’s talk about the elephant in the engineering org: promotions.
When you're new, titles might not matter much -- they didn't for me, at least. I just wanted to build cool things, learn, and be part of something bigger than me. But over time -- especially in Big Tech -- titles often become the currency for unlocking new types of work. That's been one of the biggest shifts I've observed going from startup to Big Tech.
Despite being a manager for over a decade, I haven't yet made the jump to managing managers. Companies generally won't hire you in for it unless you've got a track record of it already, and given my career shift 8 years into my 13 years of managing, I effectively hit the brakes HARD on career progression.
It's often the case that you don’t get the opportunity until you’ve done the job. But you can’t do the job until you get the opportunity.
That probably sounds quite familiar to developers trying to get their first full-time job, too.
Actionable Tip:
If you're aiming to level up inside a big company, start by documenting impact in terms the business understands.
Create a “promotion doc” even if no one asks for it -- your future self will thank you.
Identify the stakeholders for your projects. Communicate with them loud, clear, early, and often.
From Curiosity Projects to Business Outcomes
Like I mentioned earlier, I loved building things from scratch.
UI frameworks
Messaging protocols
(more recently, actually) Custom caching layers.
It didn’t matter if there was an existing solution -- building it was the fun part. I attribute much of what I've learned with respect to writing code from exercises like this.
Of course, my curiosity hasn't died but over time things shift more. The question becomes less “can I build this?” and more “should I build this?”
Spending weeks reinventing something that already exists is a hard sell -- unless it's for pure learning. These days I'm trying to find my passion in solutions I can build, like BrandGhost.
Actionable Tip:
Before you start your next side project, ask yourself:
Is this for learning, earning, or my resume?
What does success look like?
Is building from scratch the best use of my time?
Answer honestly. There’s no wrong answer -- but the clarity helps. Especially for junior developers thinking about side projects, this is often one of the most confusing subjects.
Let's Talk Testing
Okay, it's time for a spicy take from previous Nick...
There was a time when I cared a lot about "true unit tests" -- isolated tests with mocks, strict boundaries, and high coverage. I worked with my teams this way and we DID have a lot of success with it, often able to identify bugs and fix bugs before support would report them through a combination of telemetry and unit tests. And to be fair, I do strongly believe writing testable code this way made me a better developer.
But these days?
“Why am I mocking a database when I can spin up a real one in Docker in two seconds?”
Exactly. Thank you, Testcontainers.
As tooling improves, your testing strategies should evolve too. Today, integration tests and real systems are easier to spin up than ever before. The brittleness of "true unit tests" has lessened greatly for me, but I'll still write my code in ways that makes them easy to add as necessary.
Actionable Tip:
Review your current test suite and ask:
Are you overusing mocks where real components would be better?
Are you duplicating effort in your unit and integration tests?
Can you refactor to make testing with real systems easier?
Better tooling should lead to better coverage and better confidence. Try this exercise again for some other development practice you can challenge yourself on.
Managing Your Engineering Energy
Let’s talk about hyperfocus.
I spent many hours (over many years) building hobby projects. I'd wake up and go to bed thinking about them-- notebooks filled with ideas, total immersion in the problem. It was fun, intense, and just mayyyybe even a bit compulsive.
These days, that energy gets channeled differently:
Into content creation
Into building my own product and service
Into answering questions and teaching others
That same energy is still there -- but now it's directed toward systems that matter. Those things that served me well for learning and practicing programming aren't as valuable for me today. It's not that they were bad or wrong, but things are different now.
Actionable Tip:
If you’re someone who goes deep into a topic, try to align your curiosity with your goals.
Want to learn something? Document it.
Want to build something? Scope it down.
Want to ship something? Ruthlessly prioritize.
Your energy is valuable. Spend it wisely. Personally? I struggle with the third one when it comes to my own projects.
Let Your Values Evolve
What you care about will change -- and that’s a good thing.
You’re not abandoning who you were as a junior engineer. You’re evolving. Your job isn’t just to write code anymore -- it’s to make good decisions, scale your impact, and enable others to be more effective.
So here’s your challenge:
Reflect on what you cared about two years ago -- or maybe go back a bit further if you have more years.
Compare it to what you value today.
Ask: where do I want those values to evolve next?
Remember, having awareness of this is what lets you steer your focus effectively.
For me? My focus is going into:
I need to drive growth on my YouTube channel.
I need to get BrandGhost in the hands of more content creators.
I need to scale my engineering leadership capabilities in the workplace.
Your turn.
Join me and other software engineers in the private Discord community!
Remember to check out my courses, including this awesome discounted bundle for C# developers:
As always, thanks so much for your support! I hope you enjoyed this issue, and I'll see you next week.
Nick “Dev Leader” Cosentino
social@devleader.ca
Socials:
– Blog
– Dev Leader YouTube
– Follow on LinkedIn
– Dev Leader Instagram
P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!