To begin with, computers were created to make things easier. First, to do math that took humans far too long. As they've evolved, they've taken over assembly, production and all sorts of things that humans are slow and inefficient at. All programming should follow this logic as well - make it simple.
Reductivism can be applied to all levels of programming; for instance - when you first design your program's purpose and functions, ask yourself: (Am I making this task easier to do for the user? How can I make it easier?). If your program makes things harder or more exasperating, who would want to use it?
At the lower level, you apply it to your code itself. If you find yourself writing a Java class with thousands of lines of code, chances are there's functions of that class that can be put in others of their own, to make your code simpler. If you're dealing with boolean logic, say in PHP, and you have an if statement with 10 different "else" lines, couldn't you make that a switch? Catching little things like that make you a good programmer. Remember, when the same logic is executed over and over by a computer, a tiny bit of extra processing time adds up quickly.
I'm reminded of something I was told in /r/learnprogramming:
Many people think that being able to write clever, difficult to understand, convoluted programs makes them better programmers. In fact, the opposite is true: writing an easy to understand, simple looking program is much harder, and also much better.
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." - Antoine de Saint-Exupery
Your code should make sense. This is something even well paid programmers have trouble with.
Name your variables what they store - $derp or int herp can lead you to make a lot more mistakes when computing them than $totalInterest or int accountNumber. The same with functions! Imagine you're coming back through your code several weeks later: what's going to help you understand the point of a code block better: the function ab() or the function convertToCompoundInterest()? Obviously, the extra second it takes to type out the name instantly tells you that the function converts the input to compound interest.
The above also explains why /* commenting */ is important. Comments can detail a function, a block of code that looks out of place, things to do in the future, or even a kludge that you plan to replace with good code later.
Commenting is also very important as a professional programmer. A great deal of work out there is dealing with someone else's code, or writing code that someone else has to deal with. Sure, your code may be obvious to you but will someone else's code be that obvious? Someone with different naming styles, different ideas of what parts of a program come first? Probably not. So it helps a lot to have explanatory comments along the way.
These are only some basics that will help you along the way - there's much more to being a good programmer, but keeping what I've said here in mind will keep you above a large heap of skiddies and scrubs out there.
Feel free to ask questions or add opinions below.