This blog entry is likely applicable to most people, regardless of their profession. There are many people in this world that have the false impression that you have to work hard and you have to work fast to win in a competitive business environment. I can tell you from experience that moving too quickly and working too hard will not make you the winner in the end. Working hastily leads to mistakes, working too hard leads to burn out, and your competitors will pass you by.
The secret to success is to work smart. While you have probably heard this saying before, it bears considering exactly what this means. For someone to work smart, they must consider opportunity costs, and evaluate their position before making rash decisions. Just because something can be attempted to resolve an issue, doesn't mean that it's the best solution, nor that it is guaranteed to have the intended effect. When you are working smart, you take the upfront time to validate your assumptions, consider alternative approaches, ensure your solution will gracefully handle all possible use cases, and test as early as possible.
Working smart is especially important as the scope of the issue increases. Large scoped issues beg for elegant solutions that optimize for many use cases and possible outcomes. Rushing into code may net you short term productivity on these types of issues but you are going to inevitably find one of two scenarios will present itself.
In scenario 1, you will neglect refactoring and lessons learned to continue your 'productivity' until you hit a point where the code becomes very difficult to work with or you encounter systemic issues caused by early decisions that didn't pan out as expected. At this point you will either bite the bullet and re-write the system causing major delays or you accept the design flaws and release a product that is not as good as it could have been.
In scenario 2, you will acknowledge as you work that assumptions you initially had were wrong and gradually incorporate these lessons into the code base. This is definitely the better outcome, but it takes diligence to upkeep. It is a slippery slope when you start to prioritize writing new code over optimizing poor existing code. At best you will occasionally slow yourself down as your refactor, at worse you may find that the constant refactoring leaves your system in a fragmented state.
Ideally you avoided both scenarios by deciding that some upfront time to investigate and ponder the best solution was worth it. You might make slower initial progress than your peers, and you might not even be the first to a working solution. But by working smart, you will find that the job is actually less stressful, and the final product is more robust, with less total effort.
The primary concern to working smart is knowing when to make the transition from analyzing to implementing. You want to avoid scenarios like 'analysis paralysis' where you get so caught up in the perfect solution that you never produce anything at all. This comes back to the opportunity costs of decisions. If your analysis starts to suggest that any further tests will not have major impacts to the optimal solution, or will cost more than they will produce, you are probably safe to begin the implementation.