21–30 of 272 posts
Lots of times I use side projects as a way to explore new stacks, deployment approaches, etc. The goal of the project is not to deliver anything, it's to learn so that when I go to do my next "real" project at work, I know what works well and what doesn't.
That's not a problem, that's the goal!
For me it's very important that I don't discuss projects with friends / family / colleagues etc. until I really have something to show. I have always found it very easy to talk all the energy out of a good idea before I've even got any real work done.
> 4. Use frameworks and customise them – only refactor/build your own when absolutely neccessary. > 5. Build your project first – then worry about continuous delivery. These contradict each other. Building your own deployment system is just as much of a distraction as building your own CSS framework.
Your "deployment system" could be a 20-line systemd service and a git checkout. You deploy with a "git pull" and "sudo service restart".
"Continuously Delivering Nothing" is a mission statement for several companies I know.
sure it would be great to have scaling to 10,000 users already sorted by the time you get there but odds are your project will never get there, when you get to 5k users you need to start worrying about that
if you're just doing it to learn or for fun then obviously this article or my comment don't apply
Lots of times I use side projects as a way to explore new stacks, deployment approaches, etc. The goal of the project is not to deliver anything, it's to learn so that when I go to do my next "real" project at work, I know what works well and what doesn't.
Me too, I think there are two types of side projects, this article focuses on those which I believe people will try to generate a business out of, or at least some form of passive income. But there are also some side projects where you just want to get your hands dirty with some different tech, if you do deliver something then you can showcase it on your portfolio. I know when the app store gold rush first started a…
More often than not the skills I learn doing this kind of thing end up being very useful to me in the day job.
I'd like it if the side project was successful enough to justify all of that yak shaving, but I don't really expect it to be and I'm not that fussed when it isn't.
But if your primary goal is that your side project should become your day job then the article is pretty good advice. Leave your yak unshaven :)
For me it's very important that I don't discuss projects with friends / family / colleagues etc. until I really have something to show. I have always found it very easy to talk all the energy out of a good idea before I've even got any real work done.
That's a thing. Expressing in public your desire to achieve something makes you less likely to deliver. http://www.psych.nyu.edu/gollwitzer/09_Gollwitzer_Sheeran_Se...
> 4. Use frameworks and customise them – only refactor/build your own when absolutely neccessary. > 5. Build your project first – then worry about continuous delivery. These contradict each other. Building your own deployment system is just as much of a distraction as building your own CSS framework.
Why do you need a deployment system if you have nothing to deploy? Build the project locally, then use continuous delivery when you have something to deliver.
Triggering that pipeline from a commit trigger instead of manually just means copying the build command into a config file. It pays for itself in the first hour.
Users will absolutely notice if your product crashes or breaks, which is more likely with some languages than others. The single most likely reason for me to stop using a nominally useful product is that it doesn't work reliably. I hate the fact that so much technology today is broken, partly because people have this cavalier attitude towards choosing technologies that help to keep things working.
For me it's very important that I don't discuss projects with friends / family / colleagues etc. until I really have something to show. I have always found it very easy to talk all the energy out of a good idea before I've even got any real work done.
That's a thing. Expressing in public your desire to achieve something makes you less likely to deliver. http://www.psych.nyu.edu/gollwitzer/09_Gollwitzer_Sheeran_Se...
Looking back on my many projects, the feeling of delivering on an external commitment seems much weaker than the urgency of "wait 'til my colleagues see this!"