Hey, what's up?
John Sonmez from simpleprogrammer.com.Today,
we're going to talk about side projects and how they change with your experience.
This question is from Zoltin.
Zoltin.
Sounds—Hmmm.
Sounds either Russian or maybe—yeah, I think maybe Russian or somewhere around there.
I'm sure you guys will let me know in the comments.
He says, "How does the role of side projects change when you have, let's say, 2, 5 and
10 years of experience?
Must you build bigger or more complex projects?”
This is a really interesting question.
I don’t think anyone has really asked this question before, but there's definitely probably
going to be a change in the kind of side projects that you work on.
First of all, I'm recommend that you always be working on some kind of a side project.
It's just a good idea as a software developer for multiple reasons, one, to keep your skills
sharp and to also—you can also get to work on some of the fun stuff that you enjoy working
on.
You don’t always get to work on the technologies and things that you want to at work.
Especially, if you're trying to learn a new technology, you might not be able to use that
at work but you want to transition to a job that uses that technology.
You can do that with your side project.
Then also there's a real good financial incentive like if you're constantly working on a side
project and you do this for a long time, as long as you complete these projects which
is key.
I did this post on being a finisher.
You can check it out here.
As long as you complete those projects, you have a good chance of making some money and
maybe building a business.
I mean Simple Programmer and everything that I do in my Pluralsight videos, you can check
out the 55 Pluralsight videos I did here, they started out as side projects.
Okay?
Now, this si my full-time gig.
Now, I get to stand at the ocean and shoot videos for a living.
How cool is that?
Let's talk about the way the things change, okay?
When you first start out as a software developer, I think what a lot of—actually, most people
get this backwards.
A lot of people including myself, right—I screwed this up before—is they try to come
up with these huge challenging side projects.
They want to build this ultimate application and they're like, "Okay.
I got to learn how to write code so I could build the ultimate video game that I wanted
to create."
Right?
It never happens because it's too large and you don’t have the skills and the aptitude
to do it nor the commitment to do that.
So it never actually comes to fruition and you spend a little bit time and you get frustrated,
and it's a waste.
Remember: Things that do not get finished to 100% have 0% value.
You get nothing for them.
So you get something to 99%.
You've put in all the work.
You've put in all the time but you don’t get the economic value from that thing, but
you pick something smaller and you get it to 100% then you do get value.
You should err on the side of finishing things than making big things, especially when you
start out.
When you start out your side projects, actually it should be things like copies of stuff that
already exist and here's the reason why.
Because when you start out, when you have a not very much development experience, what
you want to develop is your ability to translate requirements, to translate what you're supposed
to build into the actual code and actually getting that done.
You want to build up those skills.
You don’t want to build up the skills of being a creative person who can design an
application or a game, or something like that.
Those are fine skills as well but your primary skill that you need to focus on is being able
to execute, being able to take an idea and turn it into reality.
Trying to do multiple things at once, trying to come up with the idea at the same time
is going to be destructive because it's going to make things too complicated for you.
Try to keep it as simple as possible.
The side projects for very early developers, very inexperienced developers should be copying
something that already exists.
Making your own version of it.
Something simple like a to-do list app, right?
That's a very common one that developers implement in a language, but start with that.
Start with simple stuff that you already have the requirements.
So you can just take something that already exists like an Android app or an iOS app,
something very simple.
When I first started doing game development, I kid you not I just reimplemented Pong because
that's a good place to start because I don't know how to do game development.
I don’t know how to create a Mario game, that kind of a game, so I started with Pong.
Then after I did Pong, I did like a space shooter game where it's just like a ship going
across the bottom and shooting enemies, very simple type of game and then I did platforms
and increasing mechanics, and stuff like that, but I copied stuff.
I'm not saying to plagiarize.
I'm not saying to claim that something is your own, but there are so many copies of
Tetris and Pac-Man and whatever to-do list app.
No one owns the idea of a to-do list app so just copy it.
Once you've copied it, maybe you can make some slight changes.
You can change how it looks a little bit.
You can add a little bit of functionality, but just try to do a basic copy.
That's when you're starting out.
Now, as you get more experience, these side projects should get a little bit larger, of
course, and you want to incorporate more things.
Then perhaps create your—build your own things.
Start building architectures.
When you first start out, don’t worry about architecture.
Worry about just building the thing.
How can you get it done?
How can you make this stuff work so you can get a feel for it?
As you get more experience, maybe you've got 5 years' experience and you're good.
You can develop these simple apps.
Now, maybe you say, "Okay.
Instead of just focusing on building the app, I want to focus on building a clean architecture
with my side project.
I want to actually focus on that kind of stuff."
If you want to go the entrepreneurial route, now maybe you start thinking about marketing
and design, and maybe hiring someone to do the design for you and stuff like that.
As you get more and more experience, what's going to change with your projects is I think
is that you're going to build on that and you're always going to do projects that you
can complete.
I talk about this a lot and the idea of making commitments to yourself, and these things
coincide.
If you become a person who lies to yourself, you're going to constantly lie to yourself
and you're not going to be able to follow through on anything that you say.
You're going to be a procrastinator.
You're never going to be a finisher.
If you can make small commitments to yourself and you can follow through on those commitments,
and this is the same thing, translate this as projects.
If you can do small projects and you can get those things done, then that's going to create,
establish that trust that you have with yourself, with your own abilities and then you can go
for a little bit of a bigger scope.
You can get that done and complete it.
If you don't complete something, it's time to take a step backwards and do something
simpler until you get—you always want to complete everything that you do.
That means, one, you got to have the gumption.
You got to have the perseverance and consistency to actually accomplish and complete the thing,
but, two, you got to be careful in your selection.
When you start to start a project, think about how will this end.
Think about am I actually going to finish this.
If your answer is no, you're not going to finish it, don't even start it.
Don't start things that you're not going to finish because you don't get the benefit.
Pick projects based on what you've already done and go a little bit bigger.
Go a little bit bigger in scope, but never ever, as a side project, pick something that's
going to take you 6 months or a year to build the MVP, the minimum viable product, because
it's just going to be a waste.
It's going to take too long.
Things are going to change.
You don’t even know if it's going to sell.
It's too big of a project.
I would say even if you're the most experience software developer, get—figure out ways
to ship early, so that your V1, you can build it in a month or 2 months, or 3 months at
the max.
If you go past the 3-month mark, your chance of failure of not actually completing goes
way up.
The time it takes maybe way longer than you expect and the chance of you actually shipping
it or actually making money goes way, way down because you can't respond, especially
when you're doing this as a side project.
Hopefully, that's useful to you.
I know that's a lot of advice there on side projects but this is something that is important,
I think, to a lot of people.
I actually have a new chapter coming out in my new book called the Complete Software Developer's
Career Guide.
You can check it out where I talk specifically about side projects if you're interested in
that whether you should do them, how to do them, all that kind of stuff.
You can sign up here to get on the email list.
At the time you're watching this video, that chapter might not be out yet for free, but
you can start reading the other chapters, and you can buy the entire book that will
include that chapter when it comes out.
If you like this video, if you haven't subscribed already, click that Subscribe button below.
If you have a question for me, you can always email me at john@simpleprogrammer.com.
I'll talk to you next time.
Take care.