I've become fairly competent as a programmer, but I would not say I am a master. I work independently, most as a hobby, although I have done some freelance PHP work. I tend to find myself dabbling in a lot of things: Java Android SDK, Arduino, game scripting, Lua, etc.

I've reached the point where I want to start a real software project, but cannot think of a small enough project that allows me enough practice, while still being able to publish a decent piece of software in a reasonable amount of time, and build up a portfolio.

More specifically, I was looking at Ubuntu development, in Python, using the Quickly toolset, which includes the PyGTK libraries.

So the question is, what is the best way to come up with a small project that is still useful, as a starting point to a software development career?

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

i started with projects that solved some of my own personal itches as @Yannis Rizos (+1) excelent answer suggests. However i learned most from expanding features to existing open source projects.
–
k3bOct 13 '12 at 10:08

3 Answers
3

I needed a POP3 client. So I went out on the Internet and found one. Actually, I found three or four. I used one of them for a while, but it was missing what seemed an obvious feature, the ability to hack the addresses on fetched mail so replies would work properly.

The problem was this: suppose someone named 'joe' on locke sent me mail. If I fetched the mail to snark and then tried to reply to it, my mailer would cheerfully try to ship it to a nonexistent 'joe' on snark. Hand-editing reply addresses to tack on <@ccil.org> quickly got to be a serious pain.

This was clearly something the computer ought to be doing for me. But none of the existing POP clients knew how! And this brings us to the first lesson:

Every good work of software starts by scratching a developer's personal itch.

Perhaps this should have been obvious (it's long been proverbial that "Necessity is the mother of invention") but too often software developers spend their days grinding away for pay at programs they neither need nor love. But not in the Linux world—which may explain why the average quality of software originated in the Linux community is so high.

Stop trying to think what might be useful to others, or what might look good on your resume, and concentrate on what would be useful and/or interesting to you.

Pick any little problem and solve it, then expand it as much as you like a little at a time. Tic-tac-toe would be a fine beginning:

Write a program that lets two users play tic-tac-toe.

Add a feature that makes the program detect when one user is the winner.

Add a player vs. computer mode.

Refactor the program so that you can easily change the board size and the rules.

Try implementing a two-player version of Go.

Add win detection.

Add a player vs. computer mode.

Try to get it to play a decent game.

Add more grid-based games like dots, checkers, reversi, etc.

Don't worry too much about designing a product just now. You need to get some practice building software first. Later, when you feel more confident, you can turn your project into a product, or you can apply the same methodology to some other product that you'd like to build: start with just a piece of the problem and get that working, then build out other parts.

You might want to read up a bit on test driven development. Actually using TDD might be difficult at the outset, but in some ways it's a version of what I wrote above. You think of something that you want to add to your project, and you write a test that will tell you whether that feature works in the product or not. The test initially fails, of course, because you haven't implemented the feature yet. So then you implement the feature such that the project passes the test. And then you write a new test, and so on. It's a nice idea.

Using this approach, you never have to strike a balance between 'useful' and 'feasible' -- each step you take should be feasible, and the project becomes more and more useful as you continually improve it.

To add to Yannis Rizos answer, you should decide if you want to play, or if you want to help, or if you want to produce something usefull.

One of the ways that helps you to become master is to read the code of the others, to understand the ideas of the others, to think about ideas that are not yours.

There are open-source/free projects that always need volunteers. It depends whether you want to promote your name or whether your satisfaction comes from the knowledge that you helped to make something better for the others.