Ask HN: Learning to program for four years. What am I missing?

Don't be afraid to make a mess - Don't expect people to be impressed, except yourself.

If you want to do something you can't do, just do it whatever way you can at first (lift HTML from source views of pages, pre-render stuff with other tools, etc., hard-code variable data, etc.). Part of the idea here is to get into your mind you ARE capable of creating stuff. Once you get over that hurdle you can then think more about how to get it done better.

I'd probably stay away from frameworks, sounds like you might want to get your hands dirty with code - frameworks can put up guard rails and barriers to get things done.

Another idea is to take some crappy sample code or idea and expand on it; one of my first messing with PHP was making an event calendar - started playing with Datenator (a 2005 calendar program) Didn't like the program but it was something simple enough to pick apart, learn from, and rewrite to what I wanted. And my original calendar probably wasn't much better (code-wise) but it was more what I wanted and a start.

So, do what you can, however you can, don't listen to those "you can't/shouldn't do it that way" people for now (work on resisting random HN opinions), after successes see how you can make improvements.

Also during this "larval state" get comfortable with your tools and work to adopt good coding style (the bigger your projects get the more you need to have your tools working for you and have a methods to keep your data/code/data organized and readable).

My favorite teacher taught visual basic. I have barely used visual basic ever since. But what she hammered into our heads was flow charting, psuedocode and organization.

I organize the features I want long term, I organize the technologies I want to use, I organize my file structure, I organize how I'm going to reach each goal, I flow chart out how to solve smaller goals.

I'm not a teacher and I don't think I have a silver bullet. But here is what I would suggest

1) Write the program, but don't use any language. Use a language you've made up yourself (It sounds stupid I know)

  - Does it have a UI? - Make it.

    -Does the UI have squares? Where, what color

    -Does it animate?

  - Does it require information - Figure out where from

    -From the File system?

    -From a server?

    -From another peer?

    -Will information be pushed live or only retreived when requested?

  - Does it react to user input? - What kind?

    -Voice recognition?

    -Clicking on the UI?

    -Waiting to long?

2) Choose a language and figure out how to implement each one of these things

  -Look it up on a Search engine

    -I found the dumber my questions are, the better my search results are

  -Read documentation

    -Complain about documentation

    -Complain about the library being unintuitive

      -Promise yourself you'll never write something so terrible

3) Work until your tired, satisfied, bored, angry, had your fill or finished

This is the kind of work flow I get paid to do.

After reading the other comment, heres some more experiences. Your work will turn into spagetti code with plenty of errors and most likely unmaintainable. Making Abstract Classes and Using Object Oriented techniques will make your life much more easy. But I'm assuming you don't want to just keep hello world'ing and just build.

So, I'd suggest a few things.

First, stay the hell away from the web until you get some more projects under your belt. Especially nowadays, there's a huge number of opinions and frameworks out there, and a lot of bad information, and just generally a really bad place to start.

Second, stay the hell away from C++ and Java. They are, at best, intermediate level developer languages. They have a lot of power, they have a lot of moving parts, but they're complicated.

Third, build a simple game, in C. The language is small and well-supported everywhere. Use SDL to make a simple pong game. Use SDL to make a side scroller. The issues you run into will happen as you decide "Oh, I want to add jumping", or "Oh, I want to add an inventory". The language is low-level enough that you'll have built your abstractions from the start, and will have a good idea how more things fit in. Then, you can start learning how to build software better and organize your code.

Start simple and small, and grow. :)

To build more complex applications or systems, you need to have some notions of larger scale software engineering, which would cover modularization, components, interfaces, and indeed, frameworks. Also, you need to master how to build abstractions at the different levels (there are different ways to build abstractions).

So I would advise:

- study sicp (https://mitpress.mit.edu/sicp/full-text/book/book.html),

- study OOP and OOD (UML, design patterns; some OOD books cover modularization and component design),

- study some software architecture material,

- and to put it in practice, take some important application (something like Firefox), and study it, and contribute to some bug corrections or improvement.

You're missing six more years. Don't worry about it. Mature programmers don't appear overnight, and immature programmers aren't worth their salt.