Steve Jobs once said that the difference between an average programmer and a gifted programmer is 50:1 - maybe even as high as 100:1. Although I am not sure that the dynamic range is that extreme, I can say I've worked with average programmers and a few gifted programmers. Regardless of talent, I think many programmers can benefit if they did the following:
Stop overanalyzing things.
“It's like a finger pointing away to the moon. Don't concentrate on the finger or you will miss all that heavenly glory.” - Bruce Lee
Overanalyzing things slows programmers down and is a waste of time. I can’t tell you how much time I have wasted overanalyzing my code. My best work has often been a result of spontaneity.
When I had started my career fresh out college, I was too focused on perfection. My code was clean and elegant. I used all the correct patterns to ensure that my code was extensible for World War X. The thing is, most of the situations that I coded for never happened, and I wasted a lot of time overthinking things. In retrospect, I would have been a more productive coder by at least a magnitude or more had I kicked perfection to the curb.
Good code is an on-going process that doesn’t happen all at once. The process unfolds naturally as the ideas and relationships make themselves visible while you work. If you think things over too hard you cut yourself off to true genius.
Don't switch tech stacks unless absolutely necessary.
If your goal is to release a product and you’ve already put work into it, go the rest of the way using the technology that you started with. I’ve redone login registration after login registration in various frameworks/languages because I thought it was going to be better. In retrospect it was not a good idea.
Do not think that because a new technology is subjectively better that it is going to solve all your issues. No language or framework is perfect. Stick to your original plan and get it done. Make compromises if you have to, but keep your eye on your target. Get your product out there!
Your first version won’t be perfectly polished nor should it be using cutting edge technology. If you’re going to be on the bleeding edge of a framework's/language's version you’re going to encounter bugs or other issues. These issues are going to cost you a lot of time. What's worse is that often you will find out that nobody in the general community has encountered your situation so you won't be able to ask the general community for much help.
This is not to say that you shouldn't switch tools if your current tool set is not a good fit - you really should be using the correct tool to begin with. No, that is to say, it’s better to stick with your current toolset if you know that it will get the job done. Do not switch unless you absolutely have to. You’ll be revisiting a lot of ground that you have already covered otherwise. It certainly makes sense to do new things with new technology, but redoing existing things that already work is rarely a good idea. Every company that I have worked for that has tried to reimplement the legacy codebase has failed.
Don't be clever.
If you've chosen some obscure framework or language to do your project in you're shooting yourself in the foot. This is the only time that I would suggest that you consider doing your project in something else.
Yes, I know that being clever and saying that you know something that nobody else knows can set you apart and make you look smarter than all the other programmers. But it doesn't do you any good to not have community resources at your finger tips that only a larger development community can provide.
Smaller dev communities or technologies that are dying out are going to slow you down because there will generally be less internet resource to tap into. Languages and frameworks with large communities have a wealth of resources in the form of tutorials and questions/answers. You'll be able to find solutions to your problems quicker if there is a substantial community to tap into.
In addition, you may or may not be able to do all the work yourself either now or eventually. It's not a good idea if a tiny talent pool is all you can recruit from. This is going to negatively impact your efficiency because there will once again be a lack of resources.
Nobody cares how pretty your code is.
At the end of the day, what matters most is if your product works. More importantly, your product needs to generate revenue. As an engineer I like my work to be maintainable and clean. But in all seriousness the users do not care what your code looks like.
If you want to break out of your engineering cubicle and make it on your own you have to drop the “Software Engineer” mentality and stop being pedantic about the quality of code that you write. Does the product work? Is it stable and relatively free of defects? Is the codebase just readable enough without it being a hindrance to moving forward?
The “Software Engineer” mentality is great when you want to remain employed, but it is terribly inefficient for entrepreneurs. Be results driven, and ditch the "Software Engineer" mentality! You've got to start from the customer's experience. It's not a good idea to start with the technology and figure out where you're going to try and sell it. People are not going to buy your product or service on the basis of how well it is coded.
Talk less if not at all.
I've worked with one particular engineer that was not only below average in ability, but he did not produce much because he had a habit of talking too much. The conversations were almost always petty and off topic. The output of this engineer was very poor because he didn't put enough time into his work. He was too busy in his social life.
Group meetings were also almost always him talking over everybody else. His personality was toxic to our startup. He wouldn't listen to ideas or current issues because he thought he was above them. Sadly to say, many people left the company because of him, and the product that he was responsible for maintaining did not get better. It only got worse as more features were added.
The quiet coders that produce are the real masterminds. There's definitely more to being a gifted programmer than just coding. Knowing when to listen with critical time management skills are skills that every entrepreneur should have. It's your time and your project. Don't squander your time. Perfectionism will also slow you down so don't worry that you're not using the latest and greatest technology or your code is horrendous. Take a deep breath and do the thing!