I did a part-time Ph.D between 2004 and 2009. I had a plan for what I was going to research, but in the end ALL FIVE chapters of my dissertation ended up being work that started out as side-projects. Along the way, I got to name two new dinosaurs (and revise one of the best-known old ones).
So needless to say, I am a big fan of side-projects. My experience is that I attack them with an enthusiasm that's rarely present when I am doing scheduled work. Often the momentum that that gives can get them to the point where they have enough substance to be wrestled over the finishing line relatively easily.
(Of course that experience won't translate directly to the kind of work you living from.)
It was really just one side project for me, but my story is similar. I started out planning on doing parallel/distributed supercomputing, but in the middle of my 2nd year I was diagnosed with type 1 diabetes and spent several months learning to deal with that. During that period I couldn't focus on any "real work", so I allowed myself to get distracted by writing freebsd-update... and by writing bsdiff so that freebsd-update would use less bandwidth.
By the time I started by 3rd year, the fallout from bsdiff -- a new algorithm from matching with mismatches and applications to file synchronization -- was enough that I went to my supervisor and said "so, err, I got a bit side tracked, but I'm wondering if I've just done a thesis worth of research".
I think the key to think about side projects, is that they're just that - projects on the side. If it starts taking up full-time hours and responsibility than it's not really a side project anymore. For me, I have my desk job. Then I have my startup I'm trying to turn into my "desk job" if you will. And finally I have my side projects.
These side projects are mostly fun, or the fleshing out of an idea. But I really don't undertake any that would take a ton of time or effort - unless I'm really, really interested in the solution (it hasn't been done or a better perspective on an old idea, etc). This way I don't spend a ton of time - maybe a week of a few hours here and there - to launch it.
Interesting thoughts. And it felt like I am reading what I always felt. I have created ,sorry, started many side projects but none of them ended properly. Some left out in the middle, for some after starting I just had no vision what to do next with it.
Most of this is due to my day job(full time job). And so lack of motivation or loosing interest was because of the less time I could devote to it.But I still do not agree on :
"a lack of commitment to one thing is just as productive as doing nothing at all."
When you work on side projects you learn new things or you practice old things which makes you perfect. So keep doing something is always better than nothing. Because of these unfinished side projects I was able to learn python, machine learning, data mining, django and so many other tools and technologies which I would have never learned as these are not related to my day job(all java).
So I would still vote for keep doing side projects whether or not you finish it you have something learned in the process.
I've been working on one for six years now. Id say that it is 70% done -- I just cant bring myself to define, map, and execute that last 30. I'm putting other ideas on hold until I finish this one, ideas that could be viable money makers, but I dont want to leave the original one without at least putting it in front of people who do not know me. I can say that I have learned a lot in the process that will be used for the rest of my career. I'll free myself of this burden by launching in December -- I'll post here as "Look at my 2000 day old startup idea"
You should find someone else to go through it with you. An outside voice pointing out possible cuts is often a breath of fresh air and helps crystalize things.
I would argue that it's dependent on what you're trying to accomplish. Sure, you learn a ton, but it still comes back to the issue of how well you can perform when you're trying to juggle a side project, a day job or whatever else you're working on.
Personally, I've found that when I do multiple large projects at once, I sacrifice performance on each. There is a tradeoff in what you learn, but I'm not sure it's an equal tradeoff.
"a lack of commitment to one thing is just as productive as doing nothing at all."
I'd agree with this statement completely. Everything I've built that I'm proud of has always been something where I took my time, had a clear vision, drafted out exactly what I wanted and then didn't just take it on as "just a side project" but when needed, forced myself to see it through to the end.
I think he has some really good points about side projects in general. I think we (or at least myself) can tend to view them as things like hey let me build a framework so I know how to do it, without any clear goals in mind (besides the vague one). Then you do it for a while and afterwards maybe you have learned maybe not, maybe you just give up because you never have the time, and then you wasted the 4 hours you spent starting the project. This is more for myself, but I think when I get an idea now or want to make a side project, I'm going to force myself to sit down, spend the half hour and write down a clear set of goals that I want to achieve, and only after this start.
"a lack of commitment to one thing is just as productive as doing nothing at all."
If your goal is to build a finished product, yes, this is absolutely true. But if you choose ambitious projects beyond your current expertise, bringing the project anywhere beyond the planning stage will be a valuable experience for the purpose of learning.
Me and most people I know just have side projects for the fun of it. Why do we need strict metrics and goals?
Side projects boil down to two types - "for fun" and "for profit (maybe)".
My side projects are like yours; I dabbled for some time with machine learning and AI, despite being under-educated and under-brained. And though my projects never really succeeded I sure did learn a lot, and some of that familiarity helps with (and helped me get) my current job. The rewards were the fun of messing around and trying to understand something, and I didn't need a metric or goal for that.
what I was trying to say is that I think you need to be committed regardless. Even if your only goal as in your case is to learn something like how compilers work and not to make anything finished, I think we'd benefit by having clearer goals (such as now I want to build a small NFA from regex) and also having the commitment to not give up until we have achieved the goal.
I went through a little bit of the "lows" in the last couple days on my side project, http://nbaschedules.appspot.com. Yesterday, I sat down and made a few key decisions such as:
- Cutting planned features/Prioritized
- Stay simple
- This is a side project, a side project, a side project
- [important] Making sure it can run with a very minimum time and money forever so it won't just die (hence using GAE, no domain yet).
Hey, this is a cool project, keep it up. Finding gametimes on the NBA website is a PITA. My only suggestion would be to allow filtering by team (or geolocate based on IP and filter for me automatically).
I'm assuming most visitors are interested in their hometeam's games rather than the league at large.
I don't know who the visitors are but I'd like to fix the actual "game-time" (normalized to UTC, then convert to visitor's local time) and to add TV schedules as well (USA, Canada, Intl) first before doing other things.
You currently have the games as <home team> vs <away team>, it would be clearer if it were <away team> at <home team> (with the time zone indicated, preferably eastern time).
My plan was to UTC-ed all the time and present them to the visitor based on their local timezone (so no need to convert PST, EST, or even worse for international visitors).
But the concept of <away team> at <home team> is definitely better! Thanks a lot!
I don't know what it is about "side-projects". When I think about what I'm doing and why, it is rarely much different than any hobby I've had for as long as I can remember. But hobbies felt much less committal. Sure, I would get consumed by them, but I didn't really get these failure pangs when the plane or rocket sat unfinished for years. Now, it's different. The sludge of half or (worse) almost done projects cluttering my ~/dev folder is a source of some shame, and it can make it difficult to start new things. My best reasoning for why this is: a) there is a constant flood of "Show HN: My Before Morning Coffee HTML5 FPS" type news, which is simultaneously motivating and depressing to read, b) it is very easy to connect the dots between completing a project and some unrealistic outcome, usually involving money or some internet fame.
So I guess I'm basically agreeing with the author. If you want to build a salable product, then focus and do it. But if your really just screwing around because this stuff is neat and it's what you like to do, then call it a hobby and don't worry about it. At least that's what I'm trying to convince myself to do.
Depends on what your expectations are. I built https://www.delayed-tweets.com for myself and I'm a heavy user of it and I tinker with it when I have time (Heroku + Stripe, if you want to know). If it also becomes a source of income, so be it. Otherwise, it costs me just a little more than using an alternate service to do the same thing (like HootSuite, Buffer, etc). But, I get to tinker with it on the side, learning new things and making little improvements as I have time. So 6 months from now, I don't have to be disappointed that it didn't go anywhere. A side project is exactly that, something that you tinker with while you still have a day job.
I used side projects mostly for idea validation. For example, I am working on an MDSD system that takes a UML or RDFS model and generates a web 2.0 app written in Google Closure and using XMPP to interact with the application layer. All of these technologies show great promise but none of them have really taken off. http://www.dynamicalsoftware.com/mdsd/closure is where I have documented some of my findings so far in exploring the merit of these three technologies.
I've just completed an Android app on previous weekend. It's hard to find a good solid block of time to get a project done. I found it hard to even start, fearing it would be started and languished. Luckily there was a hackathon on that weekend, and I used that as an excuse (motivation) to start and finish it.
I just completed a small side project: A little Ruby gem on Github. And when I say completed, I mean it. It's launched, in use in the wild, and not taking up my time. I started the project last week and finished it over the weekend. I haven't put any effort into it since, and that's not a sign of failure or abandonment. It just means the project is done, barring bug fixes, and that's a good thing.
Sometimes a side project really is just a side project. You do it, you're proud of it, and you move on. I love those kinds of projects.
I started my side project in about 1993. I lost it completely[1] some time around 2000 and decided to rewrite it starting in 2008. Since then I'm still only 20% of the way through it (I probably got to 60% before).
Right now it's dropped way down the priority list below: wife, 2 year old daughter, full-time job, part-time degree (now complete!) and startup (that will hopefully take over from full-time job some time in the future).
1. Long story, I had a backup but the primary and backup were destroyed independently within hours of each other such was my luck.
Are you willing to share more info on your side project? Sounds like it's something meaningful enough to work on for nearly 20 years (minus gaps), and yet it sounds like it's not your startup... very curious as to what it is.
Sure, it's nothing special, it's a Robot Arena type programming game. Yes there are lots of them about (that have existed for many years), but I'm trying to remain as faithful as I can to a version (by SPA Publishing) that appeared on the RM 380Z/480Z machines back in the late 80's. The robots were programmed in a LOGO style language (I still have photocopies of the manuals somewhere). All of this was going to be open source (if I'd released it earlier I'd be able to find a backup!).
Rather than implement a LOGO interpreter I wanted to do it a slightly different way to learn some useful stuff along the way, so I decided to implement robots as a program running on a virtual CPU. I designed an instruction set and corresponding assembly language, wrote a processing engine that could run multiple robot programs at once, wrote an assembler to go from assembly to compiled robots. Next on my list was a compiler that would do LOGO -> robot assembly.
There was a strong ARM/RISC influence to the instruction set/assembly language as I'd been using Acorn Archimedes machines at college in the early 90's.
I then built a control system on top of the game engine that would run all of the robots against each other in all combinations and provide a league table of which robot came out best. The end goal was to stick it all on a website and allow people to submit their own robots and see where they came in the league table. They'd also be a discussion forum on programming tips/tricks, and for people to write compilers that would take other languages as produce appropriate assembly language.
I definitely learned a lot whilst doing it first time. One of the assignments in my first year at University (Comp Sci) was to design an instruction set for a basic CPU that would be able to be programmed to perform a certain bunch of tasks. It's quite easy when you've got programming experience in Z80, 6502, 68000, x86 and ARM, and you've designed/implemented at least one of your own already.
Other things I remember that were useful were writing my own PRNG (there was an instruction to get a random number) so that I could have individual PRNGs for each robot (and the game engine) all derived from a single 'game' seed number which made each game (with random starting positions) deterministic and repeatable.
Creating a two-stage assembler (thanks to years of typing "FOR loop% = 0 TO 3 STEP 3", "[ OPT %loop", etc), compiler design (for LOGO -> assembly), maths for doing intersection of two lines, intersection of a line and a circle, integer instructions, floating point instructions (and implementing this in a portable way), etc.
In '94 I'd hacked both an X GUI and a linux SVGAlib interface onto it so you could watch the games play out. Later on I'd even came up with a dissertation proposal that used it as a fitness function for robots created by genetic algorithms but decided against it after discussion with the tutor (no less than Dr Noel Sharkey who later sat as a judge on the UK TV version of Robot Wars).
I may finish it one day, and 10 people may remember the game and be interested in writing robots for it, but that bit doesn't matter one bit. It's my side project and I kind of enjoy doing it (or even just thinking about it) probably more than the feeling I'd get if it was finished and done.
I dug around and found the latest version of my latest incantation, which is less developed than I thought. It only contains the source of the assembler; there's nothing of the game engine itself. But there's a description of the assembly language and its encoding.
Nothing is uploaded at the moment (I'll start to add things once I've cleaned it up and sorted it out) but I've created a github repository for it https://github.com/alexkus/robotarena if anyone wants to watch it and keep an eye on the (slow) progress.
So needless to say, I am a big fan of side-projects. My experience is that I attack them with an enthusiasm that's rarely present when I am doing scheduled work. Often the momentum that that gives can get them to the point where they have enough substance to be wrestled over the finishing line relatively easily.
(Of course that experience won't translate directly to the kind of work you living from.)
Details of my dissertation here if anyone's interested: http://www.miketaylor.org.uk/dino/pubs/#diss