I no longer remember my first project. I think I was in my freshman year and I attempted to compute e^10,000 using taylor series expansion.

Anyway, I can not tell you which lessons I learned from my first project and what lessons came later. So here's a mix of everything I have that may/may not help you.

• Use linux. Learning to code under windows is like attempting to build a rocket-ship with silly putty.

• Get a throw-away computer and abuse it. Look in a junk yard or someone's attic or search ebay for a $20 computer. Your expensive gaming laptop/macbook pro has too many valuable documents to mess with. You need to know what will happen when you do something like this:

    #include <stdint.h>
    fuckEverything( intptr_t startHere)
    {
        uint64_t i;
        for(i = 0; i < UINT64_MAX; i++)
         *((void *)(startHere+i)) = 0;
   }
   int main()
   {
      fuckEverything((intptr_t) &fuckEverything);
      return 0;
   }

• Learn to use a debugger. Step through code, peek into memory, use breakpoints. This is the most important skill you'll ever learn

• Write stupid dumb things just for the fun of it. All code doesn't have to serve a purpose. Replace all instances of "wand" with "wang" in Harry_Potter_and_the_prisoner_of_azkhaban.txt and see what happens. Go have fun

• Install FreeBSD. See what non-consumer software really looks like.

• Get a Pic Microcontroller and build a fancy digital alarm with it. You'll learn more about coding while reading a microcontroller's datasheet than anything on coursera or youtube can teach you.

• Learn a difficult language first. Javascript and Python are cheap skills that are easily picked up. Master pointers.

• Read coding styles. Learn about the yoda-syntax and why people write code like that.

• Read every blog post on news.ycombinator.com

• Go have fun

• Read every line of your compiler output. every single line. Google for what you don't understand. figure out what flags make your compiler more verbose.

• Buy a legit textbook on computer science. Internet posts and articles can only take you this far.

I don't know if any of the above apply to you. I still wish you happy hacking! :)

First major projects? Just random things at work, mostly Access tools for data management.

Important things:

pick your tools carefully. Namely if it's programming intensive don't choose Access or anything else VBA based. If I had my choice I would have chosen any other programming setup that allows SQL queries fairly easily.

Comment your code. You won't remember why you had to call a DLL to do something instead of using the built in function. You will try to use the function. It won't work. You'll relearn why you used the DLL. Every. Time.

Don't work on your program in an isolated bubble (unless it's required). Try to get constant input from whoever is going to use what you're making or whoever wants it made.

Writing accounting systems on Apple ][s and IIIs, and Commodore PETs.

I learned that things will go wrong because there are always gotchas at lower levels that you will discover the hard way. Later, you learn that compilers and interpreters and third-party libraries always have gotchas that are going to screw you. I learned that co-workers will intentionally and unintentionally screw you over. I learned that employers have no idea what you do and always get pissed because it takes too long and they never want to pay what it's worth. I learned that customers want stuff that seems really stupid to you, but if you give it to them they will be really happy and they will pay you and you will understand that what you thought was a stupid idea was really a good idea because you only know programming and they know what they need in their business. I learned that you have to keep experimenting and learning new things, that you should never get complacent with a platform or a language, you should always aim for where jobs will be in ten years time, and keep moving there.

My first project was creating a Shadowrun dice roller for my Python class. Probably my best learning experience.

First, Python is a pain in the ass when it comes to graphics. But it was fun to logic out the design. Creating one dice, then a row, then multiple rows, all while keeping track of where the graphics point will be.

Then it helped me explore different libraries. I ended up going with Tkinter, creating buttons instead of graphics.

So i learned a lot from that project; breaking a complex problem into small individual parts, optimizing code so I create the element once then apply it repeatedly (do not repeat yourself), user interactivity, applying images (i remember that being a pain), and saving/loading.

That was the first project that I coded on daily for long periods of time, I couldn't step away from it. So the best thing I learned was to learn programming by finding a personal use/interest and trying to code it out. Really helps keep me focused and a bit of a perfectionist with it.

Right now I'm trying to pick up ReactJS with some Mobiscroll components, I'm pair programming on it and it's so massive of a project it's breaking my brain. Trial by fire can also be a great motivator. I'm picking up more than I did in school but I'm definitely lacking some fundamentals.

Hello, World!

I worked on a small team and wrote a tool in Java that maintained, aggregated and indexed a collection of files.

Biggest lesson learned? Bad programmers write bad code and sometimes it's not even salvageable. People like to whine about people like JoelOnSoftware telling managers to only hire rock stars but bad code is a nightmare to deal with. In this case I gave up and rewrote about 1/3 of the application myself out of desperation. I certainly wasn't a rock star at that point (still not) but at least I knew wtf I was doing.

I've run into similar situations since then with basically the same end result - having to entirely rewrite their code. In the most recent instance there were race conditions, no comments, the same variable would be used for multiple things (which frequently didn't match the name of the var), magic strings, magic numbers, long and inexplicable string manipulation blocks, they violated some of the most basic best practices... the whole thing was garbage.

Lesson: Don't be a half-assed developer. Everyone else you ever work with will hate you. You don't have to be a total rock star, but know what you're doing, and if you don't, ask someone else.

There will be active efforts to instill FUD among the testers. FUD will spread like wildfire and suddenly your manager will come asking what the problem is when there is none.

Keep tight control on your analysts, and don't let the drama queens wander the test center at the beginning of UAT.

Last week I wrote my first ever script. Basically a header and footer grabber in bash using xxd and sed. Felt good, I still suck ass at coding but gonna work on it more when I have the time. Was for use with scalpel. Oh, I learned bash and regex ftw.

My first 'real' project was a mobile game I did. I created all the assets and coded the entire thing with a framework I made (wrapped around the Android SDK). I honestly had no idea that modern games (and software in general) are pretty much all made using existing engines and frameworks. It was pretty eye opening when I'd be browsing game development forums and see people posting games like, "I made this in like a week", and it'd be a decently polished game. Meanwhile, my point and click game took almost a year.

So that was the most important lesson; open source and free libraries are plentiful, time is valuable, and don't reinvent the wheel (unless you have to).

When I first started teaching myself to program?

• Various fractal image renders = pixel graphics, mouse/keyboard input, window management
• Various small games (Tetris etc.) = 'Realtime' programming, animation, bitmap graphics, storing game state
• Programming text editor with syntax highlighting and automatic indenting = Document/View architecture (ie. MVC design pattern, although I ballsed it up and put all my 'model' code in the view... you learn by making mistakes :P ), text handling, caching
• Various raytracer type things = implicit rendering, vectors, matrices, coordinate transformations, lighting, procedural texturing, text file parsing
• More games = networking, latency / desynch / resynchronization, in-game chat

That kind of thing. :)