These are 3 laws of software development I learned in graduate school from Mike Feldman, so I call them Feldman's laws. I think they are truly insightful.
1- It is easier to make a correct program fast, than a fast program correct
And the corollary: Make it right, then make it fast.
This rule is especially important for young programmers. These programmers are learning so many neat ways to make a program work that they lose sight of the main goal, which is to produce a program which solves the problem it was designed to solve. This leads to complexity in the design and implementation, and these complexities often overwhelm the problems in solving the original problem. There are other problems. If you have a correct program, you can add modifications to it and isolate the affects of those changes. You also have a baseline to test results against that you know are correct. Finally if you get a correct solution and then start improving it, you can instrument the program to see where the bottlenecks are, and address them. It is always a mistake to try to improve a program before you get it to work.
2 - Fast enough is fast enough
If the solution to the problem is for an online system, and it runs so fast that there is no way a human can perceive a lag between entering an action and that action being performed, it should be obvious that making that system faster serves no useful purpose (other than the aesthetic sense of the programmer). In addition, making it faster costs time (and hence money), for no payback. Finally making the changes introduces the possibility of new bugs or program complexity. I will never forget how once I fielded a system that used a straight array lookup to find addresses to call in an interpreted language. I left that job, and a good programmer took over the system. This array lookup incensed him, so he converted it to an AVL tree, which he convinced himself from a semester of Data Structures class was faster. The problem was the array was not that big (a few hundred entries), so the improvement was unnoticeable (if it existed). In addition, he was only a good programmer, not a intelligent programmer, so he did not fully understand the implications of this change or the complexity he introduced. Not only did he introduce some subtle bugs that were hard to reproduce and fix, the code was so complicated no one else could really figure out what he did. I was asked to come back as a contractor to remove this mess, much to his disillusionment, though I hope to his education.
This brings up the corollary to this law: If it works, don't fix it.
3 - You have to do what you have to do
Everyone knew this was coming. In the final analysis, you have to make something work for the user. Whatever that takes is what you have to do. It violates your programmer aesthetics, it is not as fast as you can make it, it does not showcase the latest data structure you studied, whatever... The job of a programmer is to do their job, full stop.