Hacker News new | ask | show | jobs
by Im_Talking 4412 days ago
I'm always suspicious of the advise to work on open-source projects, or practising programming on your own, or online coding academies, etc. I feel these are without purpose and people soon lose interest since there is no goal (although helping out on an open-source project is certainly noble).

My advise would be to look at your own network (friends, family, etc) and find those who are in business and ask them about their pain; and there is always some pain that a business has. Then figure out a solution to their problem and program that. This serves 3 purposes: 1) It has a definable goal and purpose (solving the pain) as it's a real-life project. 2) You will learn tons about yourself, programming, and the business. 3) It could lead to either employment or a program you could sell to others and start a business.

As always, make sure you write-up a contract which states that the IP is yours. Hope for the best; plan for the worst.

1 comments

> I'm always suspicious of the advise to work on open-source projects, or practising programming on your own, or online coding academies, etc. I feel these are without purpose and people soon lose interest since there is no goal (although helping out on an open-source project is certainly noble).

imho, if you work on an open source project and you find it (or your relation to it) being "without purpose," you're doing it wrong. You've picked the wrong open source project, the project is an undead zombie, whatever. If you do it right, it will most certainly (edit: "usually, at least") not feel "without purpose."

Perhaps consider looking at open source projects and your possible personal relation to any particular one from a kind of two-layer perspective:

1. General idea behind the project; its general goals; and how you feel about them. It's probably a fruitless thing to work on something you don't believe in. On the other hand, finding something that shares your values to a great extent can bring out actual passion.

2. This is (usually, sometimes) not enough: hence find particular lower-level goals (these are the "ideological<->technical interfaces" so to speak, or, purely technical particulars (think of some very particular problem or proposed enhancement on a bug tracker.)) In my experience, the lack of attainable (to you) lower level "what do i do" things (which you can use to deduce "how do i do", and then end up with a todo list of particulars, which always helps to curb general laziness (well, sometimes)) might run you into trouble (and maybe this was something the parent was actually commenting on, so we probably disagree on details only.) You have to also keep re-evaluating these lower-level particulars, and set out new ones, etc. (and this is not always easy, of course.)

A good combination of the two can be quite a powerful thing indeed. And if the project is lead by good people with lotsa experience, and if a wider community of smart folk is involved, you can learn a lot.

> My advise would be to look at your own network (friends, family, etc) and find those who are in business and ask them about their pain; and there is always some pain that a business has.

But I agree that this is probably also a great idea, and sometimes more practical, etc. (also, learning to translate business (and sometimes it is an actual business) needs into solutions / technical designs is a very practical skill indeed)