

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

Hey everyone,<p>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)<p>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?<p>Thanks
======
aaronbrethorst
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!

~~~
tolenka
An aside: I'd really love to excise "scratch an itch" from the collection of
developer idioms.

It sounds so unnecessarily uncouth. =)

~~~
bigjust
if only it didn't fit.

what would you suggest?

------
silentbicycle
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.

------
tomlogic
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.

~~~
Zev
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.

~~~
tomlogic
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.

------
chipsy
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.

------
jrockway
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.

~~~
dmn
Good point, I just need to get more "practice" with programming... anything :P
thanks!

------
elbenshira
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.

------
cmelbye
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.

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

------
zackattack
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>

