Lowering barriers to entry into new programming endeavors

Question

What things do you do to lower the barrier to beginning new projects? How long does it take to get into something new from when the idea hits to when you start making enough code to play with? In general, I'm referring to toy projects, but the concept still stands for more substantial FOSS projects upon which work is desired to be done.

For example, I would like to stop being afraid of image file formats, and to that end I'd like to be able to create an app that leverages OpenGL for viewing arbitrary image formats. Or, I'd like to explore how to handle very large image files. Maybe these kinds of projects are not casual enough for me to dive into and out of.

Other examples are things like, wow this FOSS program is great! But I'd like to fix some functionality. Oh look, if I'm going to build this on windows I have to find these million dependencies and compile them myself. Or, dang, this code is written in python. Oh wait, 2.6, now I need to make sure I install that version as well, and remember which version I'm writing for.

Do you find it more conducive to work in linux? Is the idea of a casual programming endeavor just a myth? In what ways have you lowered your barrier to getting started?

Thanks

Answer 1

This is a very difficult question to answer. Mostly because there are about four different questions in it that are only partially related. Let's start with the first one:

What can programmers do to reduce barrier to entry to new projects?

The only answer to this is to make a plan. You have to be able to break your project up into achievable milestones, and the put a reasonable estimate on them. Forming this plan may end up with a lot of research required in order to really understand what's going on.

It's a good idea to have your plan peer-reviewed, just as a sanity check. There's bound to be people out there (either ones you know, or ones in the community) who would be able to look over the plan if it only took say 20 minutes.

Is the idea of a casual programming endeavor just a myth?

Yes and no. It depends on what you call casual programming.

If you're talking about the time invested per day/week/month, no it's not a myth. You can work on a project a few hours at a time (it's more productive with a mile-stoned plan!) over the course of many months and produce great projects. You can even use the "downtime" to mull the plan over in the back of your mind, making decisions (and modifications) later on.

If you're talking about making a great project with a half-assed attitude, then yes that is a myth. You don't need to spend hours every day on the project for it to be a success, but you need to make sure the hours you do spend on it are quality ones.

Do you find it more conducive to work in Linux?

This is entirely unrelated to the primary topic. Yes, it can be painful to gather dependencies. But it's painful to gather dependencies if you're on a Linux platform and the only precompiled ones were made for Windows. Even in a "platform independent" language like Java, if you don't have precompiled jars, it can be annoying. I mean, does anyone actually like working with Maven? ;-)

How long does it take to get off the ground?

This is a function with three factors:

1. How much time you put into it.
2. How high quality the time you put into it was.
3. The scope of the project.

You could say there's a formula

Progress = (t*q)/T
    Where t = time put in already
      and q = average quality of the time you put in
      and T = the estimated required time to completion at maximum quality

How long are you willing to wait before you have enough code to play with? Hopefully long enough to make a good plan!