1. Learn new tech and everything around it
Bad programmers learn new technical skills just in time. Good programmers learn the skill a year before. Great programmers learn new technical skills and all skills, technology, design, paradigm around it a year before.
2. Produce a working application, not technical perfection
There will be times you will write code that you would not show someone else as an example of how things should be done. It’s not bad code if there’s only way to write it — just make sure you have exhausted your other possibilities.
3. Know how to research for answers
Know how to find answers or discover root causes.
Many problems are situational, and if you depend on search engines and forums, you can waste a lot of time going down a rabbit hole and possibly never getting a solution. Learn to perform root cause analysis, learn enough about the underlying system to look for other clues and solutions, and learn to take a long distance view of an issue before deep diving into it.
4. Have passion
You must be passionate about more than programming — you must also be excited about your job, the technology you are using, your employer, your project, and so on.
5. Leave their egos at the door
Many developers have huge egos. Being smarter, more knowledgeable, or more experienced than someone else does not mean you are better than that person. You need to treat people with respect, listen and truly consider another person’s ideas, ask for help when needed, and don’t look down on anyone else. You should also care more about whether the team succeeds than if you get credit for your work.
6. Have entrepreneurial spirits
The best developers are not drones. They have a true sense of entrepreneurship and feel ownership in the product. To them, the product’s success means more than just the continuation of their paychecks. Because they have emotional skin in the game, they work for the good of the project, and go the distance.
7. Measure twice, cut once… but do not measure more than three times
The best of the best developers do not let themselves get sucked into the “analysis paralysis” trap. They know to be more cautious about some things, which is why I say it is fine to “measure three times.” Anything past three times, and you are just wasting your time
It’s important to stop planning after a certain point and start coding, and then see where you need to adjust your plans. Incidentally, this is one reason why I’ve become a big fan of Agile. The best developers I know are willing to sacrifice a plan if the plan is no longer suitable or is discovered to be flawed.
Resource: Seven traits of effective programmers