A lack of planning on your part does not constitute an emergency on my part.
Promoting a good developer to management is often a twofold bad move: you'll lose a good developer and get a poor manager.
Bad programmers worry about the code. Good programmers worry about data structures and their relationships.
The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.
Almost every attempt at making something better will be regarded by someone else as a personal attack.
I know testers who make good devs. I know devs who make good testers. I know Scrum Masters who make good coffee.
We crave for new sensations but soon become indifferent to them. Wonders of yesterday are today common occurrences.
Every great developer you know got there by solving problems they were unqualified to solve until they actually did it.
Start out with finding the right problem to solve. This is a combination of “what customers are asking for”, “what customers don’t even know they want yet” and “what can be solved with something simple to understand and manage”
Like designers, if you give a programmer a problem with parameters, they’ll apply every bit of genius they have to solve it in the best possible way. If you tell them how to do it, you’ll suffer the wrath of an angry God.
It can be better to copy a little code than to pull in a big library for one function. Dependency hygiene trumps code reuse.
A programmer does not primarily write code; rather, he primarily writes to another programmer about his problem solution. The understanding of this fact is the final step in his maturation as technician.
Telling a programmer there's already a library to do X is like telling a songwriter there's already a song about love.
Almost without exception, the best products are developed by teams with desire to solve a problem; not a company's need to fulfil a strategy.