String, or nothing!
August 1, 2013 6:08 PM   Subscribe

Beginning enthusiast programmers on MeFi are often advised to learn by working on a substantial project and then exhibit it publicly on GitHub. How can someone new to a technology or tool scope out learning projects that are (a) commensurate with the learner's current, possibly rudimentary skills, (b) substantial enough to be a significant learning opportunity, and (c) interesting enough to hold the learner's attention past the initial phase? I'm especially interested in suggestions for learners who aren't learning front-end technologies or don't want to build yet another shopping cart or calendar widget.
posted by Nomyte to Technology (12 answers total) 15 users marked this as a favorite
 
What is it you want to do with programming? That is, why do you want to be able to program?
posted by RustyBrooks at 7:36 PM on August 1, 2013 [3 favorites]


Best answer: Well, I'm an old school programmer, so I don't know from GitHub. But just to give you some thoughts:
- I think programming ideas best spring from areas where you have significant non-programming knowledge (e.g., you're a security expert, or a private pilot, or financial wiz, or something). Then you do something useful that you can either do better than has been done before or that fills a void.
- Another possibility is to look for questions on the Web where people are looking for some tool or utility or interface and it doesn't seem to exist. Places like Ask Metafilter or Stack Overflow questions.

I would think the above would answer your question b (assuming you did a good job on it, and not something sloppy). Question c is a challenge for any programmer, but a professional needs to have discipline and follow-thru, all the way into testing and delivery (assuming the project doesn't get cancelled). Question a is a tough one...in the beginning you don't know what you don't know. All I can say is read, read and read (take some long drinks from the Web fire hose, do tutorials, listen to podcasts on the language where people discuss technique, maybe attend a conference, and always read other people's code).

My 2 cents.
posted by forthright at 7:56 PM on August 1, 2013 [2 favorites]


You can work on a computer game with one of the many many frameworks out there.
posted by empath at 8:07 PM on August 1, 2013


I'm going to bed soon so I'll follow up on my first question.

The first things you make are going to suck. This is not an indictment on you. When I start a new project, my first take on it often sucks a lot, and I've been doing this for a long time, and I'm pretty good at it.

I started programming because there were Things I wanted to do with a computer. I was interested in music, 3d graphics, games, poker, photography, and generally making things that I thought would simplify my life (lol)

I started and abandonded many projects, finished some, or close enough.

I think to get good at programming you have to have something you want to do. Doing a project because it will be a way to learn a language or programming in general doesn't really work, I think. You learn just enough to crank out whatever it is, and a lot of it evaporates.

In fact, programming knowledge evaporates in general - maybe all specialized knowledge does. You have to keep refilling it. You have to Want to do the project, so that you're scouring man pages and books and the web trying to find things you don't already know about to help you in your project.
posted by RustyBrooks at 8:25 PM on August 1, 2013 [2 favorites]


I'm agreeing with RustyBrooks. You don't go looking for the One Perfect Project that fulfills all your goals and that you'll stick with for years. Instead you just try something that maybe fits one of your criteria, and see how it goes. And then you try another. And eventually, you find one or more that are good enough.

I'd focus first on existing projects that interest you, and that have a friendly community. Try just going to their IRC channel and asking what they need help with. If you can provide more details on what sort of things you find interesting, and where your skill level lies, maybe that'll help us find more concrete suggestions.
posted by vasi at 8:43 PM on August 1, 2013


Best answer: If you google around, there are plenty of lists of little language-agnostic programming problems to get up to speed on a new language and/or framework. The idea is that rather than trying to write one complete medium sized application, that you implement several small programs that exercise different aspects of the language (e.g. parsing, I/O, database access, mathematical calculations). One of my favorites to illustrate:

15 Exercises to Know A Programming Language: Part 1

The GitHub suggestion is less about learning and more a way to demonstrate to potential employers that you have skills.
posted by kovacs at 9:03 PM on August 1, 2013 [11 favorites]


There's no better way to learn to program than to solve a problem you have, no matter how trivial it seems. In fact, when you're starting out, there's no better kind of problem to try to solve.

I've been programming for years, and I'm pretty good at it, but when I'm learning something new, I'll just grab a little niggling problem and program it with the new language/framework/whatever just to get into the groove. Here's an example from a couple of years ago when I switched from Java middleware to .Net GUI programming:

I scan in my Page-a-Day calendar so that I always have it with me at work (my kids like to do it at home). I usually scan a couple of weeks at a time. Of course, the scanned images need to be resized, cropped, and renamed. I started by writing a simple GUI application that would let me select the folder where the images were located, the output folder, and the starting date of the scanned images. Then I click "Rename" and the files are all renamed appropriately.

That's really trivial, and it was just a getting-my-feet-wet-in-C# exercise, but I eventually used it to learn some image manipulation, and I'm trying to figure out how to OCR the images so that the renaming functionality doesn't need to be told what the starting date is or have to rely on the files being ordered.

Would I include that in my portfolio? No, but I'm not just starting out professionally, either. However, if you're still in school, or have never taken a programming course, a little app like that (assuming it's well written and well organized) is a fine demo that you know something about the craft.

Finally, something like that also becomes a fertile learning platform, because you're invested in the problem at hand, and you start looking for ways to make it better, easier to use, more fully featured, etc. As you alluded to (shopping carts), there are no broad-based easy problems left to solve, so you should pick something that you care about.
posted by Ickster at 9:36 PM on August 1, 2013 [2 favorites]


Response by poster: I asked the question generally, but forthright speaks to my particular issue.

At one point I was immersed in subject matter, but wasn't expert enough to create anything worth using. When I was studying statistics, I didn't know enough to make new statistical tools. I could only script existing tools. When I was immersed in neuroscience, I didn't know enough to build on the signal processing utilities designed by leading field researchers. Again, I could only script existing tools.

Now that I am immersed in general consumer computing, I can think of a ton of tinkertoy learning projects, but certainly not something I'd find useful or want to show to anybody.
posted by Nomyte at 10:08 PM on August 1, 2013


It's totally ok to write something that already exists that you wouldn't show to anyone. Making original software thats useful is incredibly difficult and I don't expect new people to do it.

And it's not the case that a larger project that interests you doesn't have small starting points.

When I started programming poker stuff, I started at the very core of it. I made a C++ class that represented a deck, and made functions to re-order it, shuffle it, deal cards from it, all the things you expect a deck to do. I made a class to represent a "hand". I made something that evaluated that hand and assigned it a rank. I made something that would deal hands of poker over and over again and compare "your" hand to other people, and so forth.

Then I did it all over again. Probably at least 2 more times. Each time I included new things I'd thought of and covered cases that I hadn't before and supported more types of games of poker.

A couple of years later and I had a full featured simulator capable of answering all kinds of complicated questions about poker. Along the way I'd made a few usable products out of it and released them into the wild.

This took years - I probably started on the project in 2003 and I still put work into it now and again today 10 years later. Some weeks I might work on it 10 hours, then I might do nothing for a month. When online poker was legal I worked on it a lot more frequently than I do now.

Anyway, my point is, every big project starts with small pieces and in making these pieces you learn something about programming, and something about the subject.
posted by RustyBrooks at 8:28 AM on August 2, 2013 [2 favorites]


I'm a big fan of reinventing the wheel, btw. There are libraries for everything these days. Sometimes it makes sense to incorporate them, sometimes it doesn't. I once spent days trying to find and incorporate the Perfect Matrix Math Library into something I was doing and eventually just wrote something in an afternoon that worked fine.
posted by RustyBrooks at 8:29 AM on August 2, 2013


For what it's worth, one thing that I used to do when learning a new programming language or operating system was to solve a small problem that, like Rusty Brooks said, reinvented the wheel. My choice was a color selector/previewer tool, like this. I wrote little color selectors in Perl, C, C++, LISP, Scheme, JavaScript, etc., etc. that run on Windows, Linux, Mac, in the browser, etc., etc. As a bonus, I would often combine the tool with a font selector so I could preview what text might look like against different backgrounds.

The point of choosing a color selector was: 1) it solved a problem that I had; 2) it was a very well-bounded problem (not a research project); 3) it had extremely clear requirements and success/fail criteria (can I choose/preview a color?: yes/succeed, no/fail); and 4) it encompassed a number of programming functional areas (e.g. user events, user interfaces, color spaces, color tables, data representation--hex, ascii, html values for colors--among other things) and bundled them into a neat little package with an outcome that I could actually use. (Granted, this was back before Google and before color pickers were so damned ubiquitous.)

Which gets me to another key point: break whatever problem you're interested in solving into the smallest, most easily defined and easily tested chunks possible. Then, tackle the little chunks. Even if you never tie all the chunks together to solve your larger problem, you'll still learn something!

This will also help you determine the problems that are beyond your immediate skill set (that you might be able to find libraries to solve) and the problems you can likely solve with your current skills or by stretching them just a bit.

So...do you have a music library or a set of recipes you'd like to organize? Or maybe you have a lot of tools in your shed and you'd like to stop accidentally buying that same size wrench again and again, so maybe it's time for a little inventory system? Perhaps you'd like to create a little Google Map app with a pushpin showing where all your friends live? Whatever it is, I would suggest that you find a real problem in your real life, break it into bite-sized chunks, and then give it a go.
posted by skye.dancer at 3:32 PM on August 2, 2013 [1 favorite]


Beginning enthusiast programmers on MeFi are often advised to learn by working on a substantial project

Some thoughts about this...

What is "substantial" is a function of how much of a "beginner" you are.

At some point in our lives with some hitherto unknown tech stack / OS / dev tools, just compiling and running Hello World was quite substantial enough as the next step for us.

It's probably good to just think up interesting next-project ideas rather than worry about if they're substantial. For me interesting project ideas tend to be a combination of a) I can kinda imagine how to do them given what I already know, but at the same time b) They will also take learning some major new stuff that I haven't tackled before and c) It's something I want to have and will be useful or fun for me personally.

There's also the question of why you're wanting to learn...

I didn't know enough to make new statistical tools.... didn't know enough to build on the signal processing utilities

Most professional programmers most of the time are not doing stuff like that any more than they are writing their own text editor. Most of the time people are using existing libraries and combining the functionality available to get what they want. And most of the time they are not working on a project they started from scratch, but are extending an existing large project that was around long before they were on the scene.

To do the kind of work you're talking about you would need to be on the frontiers of the relevant field. Which means either you already spent a fair bit of time getting up to speed in that field, or we're talking about some field that is so new that the frontiers are pretty much wide open to everyone who cares to come and play. (The latter case does happen pretty regularly in the tech world, but it's also why we have to deal with so much "legacy" software that was written by people who had little idea what they were doing, and which we can't now live without. cf A Brief, Incomplete, and Mostly Wrong History of Programming Languages and When should you raise an exception?.)

If your aim is to just enjoy a hobby, well you can do whatever is fun for you. If your aim is to be a competent programmer who could earn a living doing it, that's not about being able to come up with new-to-the-world innovations, it is mostly about being professional and disciplined in using toolsets that are already out there to get useful stuff done.

especially interested in suggestions for learners who aren't learning front-end technologies

Ask yourself what it is that you *are* interested in, either technology-wise, or domain-wise. And take a look at what web services you use, and what you could do with their APIs.

A couple of examples of smallish but useful and interesting projects I've come across include:

- Coursera-dl - automate downloading material from online courses, something that is pretty slow and tedious to do by hand

- ANAGRAMATRON - find tweets that are anagrams of each other. (This was on Mefi projects, which might be a good source of inspiration for you.)
posted by philipy at 11:40 AM on August 3, 2013 [1 favorite]


« Older How did you commemorate the day your divorce was...   |   ID that ice cream place: Moo Jersey edition Newer »
This thread is closed to new comments.