Ask HN: How to jump into "real world" programming?
9 comments
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!
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!
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.
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.
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.
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.
Changing sprintf to snprintf calls? Really? While useful and necessary, thats all busywork and rather dull to hack on. Certainly not something I would want to (or happen to be) work(ing) on during my current break. Possibly minus reading other peoples code (but that depends on what type of person you are).
But, "I read the $x's codebase" isn't exactly the sort of thing that one would put on a resume (which I think is the OP's goal). At most, something to mention in an interview; "oh, $y would be good to do here - I saw it used in $x's codebase and it works quite nicely."
My suggestion to the OP: Find a service you use fairly often and make some sort of an addon for it. Maybe analytics/graphs for relationships between people Twitter? Who knows, it should be something you find interesting.
But, "I read the $x's codebase" isn't exactly the sort of thing that one would put on a resume (which I think is the OP's goal). At most, something to mention in an interview; "oh, $y would be good to do here - I saw it used in $x's codebase and it works quite nicely."
My suggestion to the OP: Find a service you use fairly often and make some sort of an addon for it. Maybe analytics/graphs for relationships between people Twitter? Who knows, it should be something you find interesting.
The snprintf idea is a real-world example of something I worked on as part of a larger project. I took over maintenance of a poorly-written code base and cleaned up all sorts of problems. sprintf -> snprintf requires you to look through the code to figure out how big the buffer is, update the API to include new functions with buffer size parameters, determine whether buffers are large enough in the first place, etc. Something that can be dull, but can't be automated.
"You could go through an entire code base and replace sprintf calls with snprintf with the appropriate buffer size parameter."
Slightly more useful (in every sense) would be to write a script which did this to code automatically.
Slightly more useful (in every sense) would be to write a script which did this to code automatically.
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.
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.
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.
(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.
Good point, I just need to get more "practice" with programming... anything :P thanks!
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.
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.
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.
You could try jumping in all the way... http://ycombinator.com/ideas.html
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
Im free over college spring break, and want to get some real world programming experience, By which I mean creating something of use to others. For some reason I feel lost as where to begin in that respect. (most my experience has been using programming as a problem solving tool, and a few tools like a broken link checking web crawler)
It seems like theres a large gap between where I'm at and where I would like to be. Any tips? like reading other peoples source code ect?
Thanks