What are some things you wish you knew when you started programming?

With them, you will be able to quickly and easily make your code better and better, with much less risk of regression.

As a result, the initial implementation details of your code are not very important, and you don't have to spend much time thinking about how the code might evolve in the future (which is unknowable anyway).

PS Don't spent much time testing the internals of your code. Check that the inputs and outputs are correct, as thoroughly as you can. Testing internals actually makes refactoring harder.

I tend to want to know how _everything_ works; this let's me reason about anything and it helps a lot when debugging.

Learn from the Masters, do not seek advice in random people on Internet.

It is called "modeling". Pick your masters-mentors carefully.

For example we have people in my company that could do the work of tens or hundreds of people just by themselves because:

-they are incredible experienced and smart. -they know regular expressions, know how to automate everything. -they understand good design, and understand people as well as computers.

Just living around this people you will start modeling them, and doing the same they do.

But people also model bad behaviors just by proximity. Fat people use to have friends that are fat, and family members that are fat. The same happens with smokers or drug addicts. You pick from your surroundings subconsciously.

For example someone here recommends you to not use vim, use an IDE. Well , the masters I know either use vim or emacs a lot. They can use other tools like IDEs too, but instead of depending on someone else for automating the stuff they need they use to make their own tools.

Remember that no big company like Microsoft, Apple or Google are going to make your life easier for making your software multi platform for example, but for your company it could be essential. On the contrary, if you only use their tools your life will be miserable if you go against the interest of those companies.

2. The design and specification stages of programming are not pointless enterprise makework, they are genuinely useful.

When writing a program, make sure you understand what you're trying to achieve in detail, and write a plan about you intend to do that.

If you don't know what you're trying to achieve (and by extension your customer/client doesn't either), schedule in some research / exploration work as the first part of your plan.

Once you have a better idea, redo your plan (and maybe your budget) and check it with your customer/client.

3. If something is going wrong, or you think something is going to go wrong, it's much better to tell someone as early as possible. Even if it's your fault, don't sit on your shame - get some help.

For example, if you're going to go over budget, you may be able to get some more budget. Or you may be able to get some features cut.