This article was originally posted in the Barbarian Meets Coding newsletter.
Good day to you! This week's newsletter answers yet another question ...
For further actions, you may consider blocking this person and/or reporting abuse
I turned this article into audio using Blogcast!
If you want, you can add this👆 player to your article by adding the following code to the top:
Really nice work. You're 16 and already on the path of awesomeness.
I wish you the very best in life.
I've been doing side projects since I was studying.
I have lots of them, of all sizes: small, large, and giant ambitious ones. But most unfinished.
I always used them to learn something, and they're making me grow lot faster than my current job.
About timeboxing, I'm learning to dream less and make more doable things.
Step by step
Please, ignore point 2.
A side project is meant to be for you. It's something you do because you want to do, because you want to learn something new, because there's a hole you want to fill. Making something "to get better at your job" might be what you want, but shouldn't be the priority.
Don't live for your job.
I am using another approach that is not based on the job.
I mean I do tools when I need to improve my work or my job and release as open source (so other people will use it and improve like happen often).
In this way they are useful, have experience because they not die after releasing and still improving.
On my github.com/Mte90 there are a lot also in github.com/CodeAtCode and github.com/WPBP
From the real needs there are the best ideas and tools, I hate people that do projects only to show that they know how to do stuff and abandoning them.
If you want to improve also your personal branding creating tools that works (and are not abandonware because you are not interested in them) is quite hypocritical for me.
I agree in all the points, except for the timebox since most software engineers tend to underestimate (including me) 😂
I have a lot of not finished (and not public) side projects, just a few I have published and my learning is that it's ok to dream big, but be realistic and keep things small. Cutting features is perfectly ok, finish some small projects before doing a big one.
Also work on something you like and find useful yourself, not what someone else told you, and as said in the article, learn tons!
Totally agree on this part. It is better to pick a small product and go for it with the 80-20 percent rule;
Don't make it perfect, make it work
Don't keep building, start to finish
Obviously, you want something that works, but if the goal is to provide something you actually can make money off, cut out things that you can do manually (ie: forgotten password functionality with <20 users is perfectly doable manually, so scrap those screens).
As soon as you get revenue from customers, improve it and upgrade the experience :)
Nice article! Jaime.
One key takeaway that I learned (and blogged about on my personal blog once) Is that I need to do a side-project with one main goal: is it to learn something, or to make it into a viable, sellable product.
Mixing the two doesn't work since if you want to make money off a product, it's best to put in the least amount of effort (use things you already master) and gets user validation ASAP.
I believe any developer needs a side project to keep the learning going. A side project can be a good sandbox to evaluate new technologies, workflow and infrastructure. Obviously, if you are good at it you might even get something out of it besides the learning.
Great one! Thanks for this piece of article!
High fives for using knockout.js! it's an oldy but a goodie.
There is some really good advice here. Thank you for sharing!
I miss working with Knockout. It's one of my favorite JS frameworks of all time!
I've been studying JavaScript for sometime now, but I still feel like I cannot do much with what I know so far.