Spoiler Alert: he was right
Step One: Use an Ubuntu computer. You're worth it.
Step Two: Make a program in C. Don't know how to program in C? Try learning from Lynda (MIT Certificates required). I recommend starting with something already made. I took pieces from...
Step Three: Make the makefile! For the most part, the makefiles look the same. Just change it depending on the clock you're using, and the IC. And, of course, the file name for your c file
Step Four: Now run your commands!
This command says, with the make program, run your make file. This compiles your c file (which is referenced in your makefile) for the device that you specify in your make file. It'll give you all kinds of fun errors when you do things wrong.
This says "run the program-usbtiny-fuses line in the make file" which physically makes the fuses for running the internal clock. This line needs to be run only once for your board. There isn't harm done if you run it again, it just isn't necessary. But once you run this on a board, you can't change out the timer or the board won't work.
This line puts your code (which has been compiled) onto the board (which has its fuses made). After you run this, your board should have its new behavior.
Step Five: GIF PARTY!
Well, kids, lower your standards to raise your satisfaction with your work. Haha, just kidding (sort of).
Lesson One: Hardware and Software are entangled I like to think this is not true, but a lot of my coding would have been easier if I'd had the datasheet next to me when making my circuit. Namely, I would have had all input devices on one port, and output devices on the other. Now that I've finished this, I need to redo my magic 8 ball (the dream is still alive, I'll do it another week) diagram so that all my buttons (or accelerometers) are on one port while the many leads going to an LCD are on another. This will make my coding much simpler.
Lesson Two: Have you thought of something? Someone else has probably already done it I don't mean to make you feel bad, but you should take advantage of someone else's learning. I have found programs where people use while loops, where they use interrupts. Pins are usually declared the same way, but some people define them as they go, and others define everything in the beginning. As long are you are producing new work, it's not bad to see how other people have solve the same/similar problem.
I'm looking forward to making more things using embedded programming, and I do eventually want to set up a development toolchain on my PC for my own work. But it's hard to justify when Linux machines are so readily available.