from Hacker News

Ask HN: How to jump into "real world" programming?

by dmn on 12/27/09, 4:20 AM with 16 comments

• by aaronbrethorst on 12/27/09, 5:30 AM

  I've always had my greatest success when I scratched a personal itch.

  My first released app, iRooster, helped me wake up in time for class, and ended up paying my rent after Apple featured it in a weekly email blast.

  My first iPhone app helped me track the daily fluctuations in electoral vote counts between Obama and McCain last year. In the first two weeks, I catapulted into the top 10 paid apps list on the AppStore, spent hours on conference calls with a fair number of bigwigs at Washington Post, and received a very nice writeup from Walt Mossberg.

  YMMV, of course, but scratching an itch means you're going to be able to solve a (relatively) real-world problem, probably help other people out, and will definitely increase your long term happiness.

  Good luck!

• by silentbicycle on 12/27/09, 6:05 AM

  I suspect part of your dilemma comes from too many CS students having the same problems. There are already a zillion webcomic downloaders, blogging engines, etc. You have other interests, yes? Perhaps you're geeked about baseball card statistics, blackjack, typography? Scratch an itch. Run with it.

  What tools would help solve (or even explore) your problems? Make them.

  That's one side of "real programming experience". Another side (which you won't learn from small - but ever so useful - projects) is how to work with other people on a common codebase under pressure, both writing clean code and interpreting other peoples' frantic twilight hacks. Kernighan and Pike's _The Practice of Programming_ is as good a style guide as any, and just practice reading code from open source codebases. Good code (Lua and the BSD userland utilites are good for bite-sized pondering) and bad code will teach you different things.

• by tomlogic on 12/27/09, 5:17 AM

  Pick an open source project that you like and use. Look for open bug reports (easy to do on SourceForge projects) and then dive into the code to fix the underlying problem.

  Or, take an existing project and read through the code looking for bugs. In C code, using sprintf() instead of snprintf() is generally a bad idea (due to potential buffer overflows). You could go through an entire code base and replace sprintf calls with snprintf with the appropriate buffer size parameter.

  If there's a project that provides a library of routines, you can write unit tests to verify that they work as documented.

  Find a project that's poorly documented, and write up documentation for it. If you document an undocumented API, you'll have to read through code to figure out what it will do. You may find that certain conditions are undefined (e.g., what happens if I pass NULL or a negative value here?). You'll be reading other people's code, learning how it works, and contributing to the overall project.

• by chipsy on 12/27/09, 6:03 AM

  Take a big idea and bite off the smallest piece of it. Preferably a boring(or boring to most people!) problem with one or more obvious solutions. Why boring? Because programmers have a nasty habit of wanting to jump to interesting, challenging problems at an early stage, before they have properly evaluated real requirements of the particular domain. Hence there are lots of dead projects with a fancy internal design and nothing working or useful about them. But, on the other hand, many programs can eventually reach a stage where the programming problems become simultaneously interesting and useful; it's just that you can't do this instantly because you don't know the real requirements yet.

  Instead, you can build prototypes to find those requirements. When you're solving "real world" tasks, a proof-of-concept solution can often be done as a weekend to two-week project. It'll look trivial and do trivial things. It's the progression and accumulation of little features and fixes that move the program from the proof-of-concept or prototype stage into a real, useful app. Eventually the accumulations overwhelm your original design, and at that point you'll have the information necessary to do things "the right way" - how much performance is necessary, what features are relevant, if the language and platform are appropriate matches, etc.

• by jrockway on 12/27/09, 11:27 AM

  Write a computer program. Any computer program. Then do that again.

  (Note: you will probably fail if you write something that someone else wants, rather than something you want. So decide what you want, and write that.)

  Ignore the advice to not write another blogging engine, or whatever. You need to learn to program before your programs can change the world. So learn first, change second.

• by elbenshira on 12/27/09, 4:44 AM

  I keep a list of possible projects on Google Docs. Most of the projects are small web-based apps.

  A great place to start is to use an existing API with a lot of data (Twitter, Facebook, Google Maps, etc) available to you and do something fun with it.

  Another idea is to contribute to a young programming language. Clojure and ooc comes to mind.

• by cmelbye on 12/27/09, 4:42 AM

  Pick an idea and make it. I've been doing that and it's really helping me with Ruby and it's led to me learning about a lot of other things like SSL, server administration, message queues, etc.

• by rms on 12/27/09, 10:31 AM

  You could try jumping in all the way... http://ycombinator.com/ideas.html

• by zackattack on 12/27/09, 10:20 AM

  If you're into hip hop then i'd be happy to give you some stuff for hiphopgoblin to work on. http://github.com/zackster/Hip-Hop-Goblin