Ask HN: Side projects vs. day job beyond a day
So the question becomes, am I doing this all wrong? Should I really put in the effort to disconnect from the day job at the end of each day and try to really focus on some side projects? Or should I really give my day job 100% even if that means going above and beyond a typical 8-9 hour day boundary? This is a quandary I have had for a while and I am not able to resolve it on my own. So I figure I would ask the collective wisdom. Dilemma is this: if I put in extra time and energy towards my day job, I would probably only get some recognition and may be a raise, but the latter would be a long shot. However, I know I can push our company's tech limits if I did put in time outside of work hours and make us kick some ass out there. On the other hand, if I successfully get a side project of the ground, I might actually make some real side income. But again, historically I haven't been able to do so.
I always wonder if other software engineers have such a dilemma or am I the only one and the rest of you guys are absolute clear about your priorities?
7 comments
[ 0.31 ms ] story [ 21.8 ms ] threadIn your specific case I would lean towards putting in extra effort on work projects. You know the domain already and probably have a lot of interesting contributions to make. But a word of advice: don't tell your manager etc that you are working more hours lest it become an expectation.
With 15 years experience nobody is going to pay you more for having a basic side project.
What's the priority for you, let's say ten years out? ... Make a successful career working for someone else or eventually build something you own / created?
If you can't answer that question then you're always going to struggle.
Now once you have your long term priorities, now stop looking months ahead and start looking in terms of short term commitments to yourself and your project. Carve out some time every week to "plan". Make commitments to yourself in terms of days/weeks. Actually plan out your work and execute based on a plan of small iterations. Treat your side project like you would a work project except with much stricter time/resource constraints. This comes difficult to most people without the checks and balances of work, colleagues, bosses etc.
But it's much easier once you make much much smaller commitments about what you're doing and actually plan your work without jumping in to coding, which for coders on a side project is always the best part. You start tackling the most interesting bits in your head first and never want to get through the grunt work and the passion fades.