Which Projects Should Junior Devs Build?
Dev Leader Weekly 72
TL; DR:
Have you checked out Code Commute yet?
Get stuck building things!
Practice iterating on a codebase!
Join me for a livestream on Monday, December 2nd at 7:00 PM Pacific!
Exclusive Article: Which Projects Should Junior Devs Build?
Build It To $ELL!
Because I gear a lot of my content towards helping junior developers or aspiring developers get into software development, the question of which projects to build comes up a lot. But one of the common themes that's recurring is around this idea of creating a startup or some app/service that can generate money.
I'll be blunt: for the overwhelming majority of software developers this simply is not something I'd recommend doing. We'll see in the next sections, but I have two other focuses that I'd rather you take. And yes, these are just my opinions as someone who has been hiring software engineers for the last 12 years, but they're still only my opinions.
So what's wrong with trying to build projects that you can turn into a business?
It's not that it's "wrong" or that it's "bad", but I think that it's a distraction. For many aspiring or junior software developers, focusing on the OTHER key ingredients that go into building a successful product/service that you can sell is going to be an enormous tax.
You're going to want to find a market fit
You'll need to learn how to market
You'll need to learn how to sell
You'll need to learn how to run a business
These are all awesome things -- I'm not here to suggest these are bad things. But if you're still trying to figure out:
How to build different types of applications like web, mobile, desktop, embedded, etc...
How different programming languages compare as tools
How to iterate on building software
Data structures and algorithms
... Then figuring out how to jump into a little business is going to likely feel overwhelming. I'll caveat this though --If you're reading this and your goal is to become a solo dev, then jumping directly into the deep end could be a very enlightening experience. If you're interested in only joining extremely early stage startups, some of this experience could be useful for understanding what those businesses might look and feel like.
However, for the average software developer -- I think we have some better things to consider. You can check out this Code Commute vlog where I dive into more detail on this:
Build It To Get Stuck
Now of my two recommendations, this is one of the most effective ways I find to learn concepts in software development. These projects are going to be all about getting stuck on things.
I realize that sounds funny, but if our goal is to practice and learn, then we need to go through these periods of getting stuck.
We need to come up against challenges where we don't know the answer.
We need to explore different options
We need to research solutions online (articles, videos, etc...)
We need to overcome them!
Very much like how failing is a great tool for helping us learn and improve, the act of getting stuck while building projects is important.
Now you're probably thinking, "Nick, you're telling me what should happen and not what to build!" -- and you're right. We'll get to that. But I still need to tell you some more things to avoid.
Stop using your LLMs.
Okay, not entirely. I think you can do a LOT of awesome work building stuff with LLMs. But stop using it to blindly copy-paste code. Let's take an example to illustrate this more clearly.
You want to build a Pokemon tracker website
You come to be and say "Nick, which language and framework should I use?"
I say "Use C# and ASP.NET Core"
Now you say "What about the front end?"
I say "Use React and TypeScript"
... "What about the database?"
"Postgres or MySQL"
"... Okay Nick, but can you help me build the server?"
"Fine, here's the code for routes to save and store pokedex information"
"... Okay thanks Nick, but can you make it display in React now?"
"Fine, here's how you call the API..."
How much were you "getting stuck" in the hypothetical example above? How much did you have to think for yourself? Now, replace "Nick" with "ChatGPT", or whatever LLM you want to use.
It's not that using these AI tools is wrong or bad, but I strongly encourage that if you're using them, ask them questions to more deeply understand their suggestions. You are doing these types of projects to learn --so if you're cutting out the learning phase simply to create code faster, you're missing the goal.
Build It To Iterate On It
That was a lot of "what not to do" and not a lot of specific "go build this" examples. However, I regret to inform you that I'm still not going to list something like the top 10 best apps to go build -- because it doesn't actually make sense. Instead, I want to give you the ingredients for projects that, as a hiring manager, I am very interested in hearing about.
While I am not the one necessarily sifting through the hundreds of resumes, when I have a resume in front of me with some type of project history, I am interested in:
How it was built
How it evolved
And that's not because I'm trying to confirm someone picked C# or that I expect they need to use ASP.NET Core. Instead, I want to hear their rationale for why they picked a certain starting point. I want to hear about how the software evolved!
What was the original plan?
How did that plan change?
How did iteration continue?
Was a complete rewrite needed? Refactoring only?
Did technology stack choices have to change?
What factors influenced all of these decisions?
I'm trying to gauge how people build software--because that's what they're going to be doing if I hire them. I think one of the best ways that you can set yourself up on this path is to find a way to keep yourself motivated to keep building and iterating on it. So here's my lightweight framework for this:
Pick a platform that you wan to build for (web app, mobile, desktop, embedded, etc...)
Pick a language. Pick a framework. If you don't know where to start, ask an LLM to recommend one based on the platform you're trying to build for--remember to ask it to explain why!
Pick one of your favorite hobbies. Maybe it's Pokemon. Maybe it's basketball. Maybe you're a movie buff or you have a favorite TV series.
Build an app or service that's centered around that -- something that you're interested in and really enjoy.
The reason I recommend doing this is because you're going to be doing a lot of what I talked about before: getting stuck. If you're constantly getting stuck, that will create some friction and discomfort for you --but this is a good thing! I want you to lean into the fact that this app/service is related to a hobby of yours, so that should make it more enjoyable and exciting to see progress come together every time you get unstuck.
The really cool thing about these projects is that they never need to be "done". You can always keep coming up with ways to extend it or rebuild parts of it for new challenges. Use it entirely as a playground to practice building and evolving software.
Because that's going to closely resemble what you're doing in the "real world".
Closing Thoughts
If someone lists on their resume that they have paying users for their app or service, I think that's great for them --but it's not something I'm interested in hiring for. I think there are plenty of awesome skills and experiences you can gain from that, but that's not going to be the focus of what I am looking for on a resume.
Two major things I like to see:
Building projects to learn about and explore technology, language, and tech stacks
Building projects to iterate on, extend, or rebuild with different tech choices
These focus on the two things I really want to see in software developers:
An eagerness and willingness to learn and explore new things, because we'll be doing this for our entire career
Exposure to an evolving code base and not just a hundred clone apps
And yes--building an app/service where you acquire paying users CAN demonstrate these things! It absolutely can! But the amount of time, effort, and energy that goes into trying to do sales and marketing is likely distracting from building up some of the basics of just building software. If you're the kind of person with boat loads of time and want to dedicate a lot of energy to it, then try it out! For the average slightly-more-time-constrained person, I suspect this will be more of an unrealistic burden.
I hope that perspective helps! Get out there and get building!
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:
Weekly Recap
I'm ONLY A Junior Developer - How Can I Work On Leadership?!
This was an awesome question from someone in my Discord community.
Why awesome?
Because it's great to see more junior developers realizing it's not just technical skills they need to focus on.
Better to get started on this stuff early since we get PLENTY of obvious opportunities to work on the technical stuff.
Let's see how you can work on leadership as a junior software engineer.
All Software Engineers SUCK At Written Communication
And what could this super important skill be that tech companies aren't putting priority on?
JavaScript? Postgres? Blazor?
Is it some other programming language or tech stack? Or maybe some other technical skills like debugging?
... Think again.
In this video, let's jump over to Reddit and read through this realization from a software engineer that after FIVE years he claims "I realize companies don't place value on this".
How Engineering Managers Navigate Team Burnout
You asked -- I answered!
On my primary channel, Dev Leader, I had someone asking about a different perspective on burnout.
I have always shared information for individuals and how they can navigate burnout...
But I've never discussed how I try to help my teams navigate burnout as a manager!
Junior Developers Can Lead Too! - Principal Software Engineering Manager AMA
I'm only a junior -- is there any way I can demonstrate leadership skills?
This is a question I received on my Discord community, and I think it's a great one.
Too often we associate things like leadership with titles, such as manager. But the reality is leadership is not a role or a title, it's action that you can take.
Let's see how leadership can show up regardless of your level as I discuss which things I'd recommend focusing on.
As with all livestreams, I'm looking forward to answering YOUR questions! So join me live and ask in the chat, or you can comment now and I can try to get it answered while I stream.
A Typical Day For An Engineering Manager (Told From Traffic)
You asked -- I answered!
You wanted to know about a typical day in the life of a software engineer, but you ALSO wanted to know what it looks like for an engineering manager.
The reality?
It's all over the damn place.
WordPress is HISTORY! Get Your Own Blazor Blog Running TODAY!
Get your Blazor blog running almost immediately after cloning the repository!
In this video, you can say goodbye to dealing with WordPress and have a C# blog ready in no time.
I'll walk you through where to fork the repository and how the initial configuration of the Blazor blog engine works.
Stay tuned for configuring your setup (including deployment) in Azure!
Host Your MySQL Blog Database On Azure In Only Minutes!
Let's continue on the Blazor blog tutorial! Next stop:
Hosting your database in the cloud!
The reality is that for most folks you're probably fine to run with the base SQLite settings.
SQLite is plenty performant (billions of instances it across the world running on our phones)
Low effort. Low setup.
Just works.
But if you're interested in learning how to set up and run a database in Azure for your blog, this is for you!
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!