Ten Thousand Hours of Code

Over the past 5 years, I've learned a thing or three about software engineering that I think would be useful to know.

If you are sure of the answer, look it up anyways

All too often do I find myself in the throes of a problem, confident in a solution, only to find a better one on a blog post or a StackOverflow question. It never hurts to get a diversity of opinions contributing to your decision making process. Keep an open mind. It's okay to be wrong. It's okay for the solution you found to be wrong. Worst case: your original solution is affirmed. Best case: you've learned something and have a better solution.

Depth then breadth

Become as proficient as you can in one thing. See how far the rabbit hole goes. Fear not, in the pursuit of depth, you will inadvertently gain some breadth. Additionally, the struggles that are borne will prepare you for the next pursuit.

Even if you succeed, try and try again

Solving a problem on your first attempt can be a risky pleasure. "It's good enough", "it's just part of the agile process" and "in the next iteration it will get better" are signs that the code has room for improvement. Knowing the faults of your code and then willingly shipping it is just another loan increasing your technical debt. You will learn to write good code if you try to write good code.

When substandard code is shipped, 6 months later, not only is the code unfamiliar again, but features have been built around that code. Or, even worse, a stopgap solution has been implemented to patch a bug in your code.

Take some time to write things a couple more times. Which one is more readable? Which one is more flexible? Which one performs better?

Ultimately, you'll learn how to best write a certain feature and you'll be able to implement it again confidently and painlessly.