you are spending the least of your time actually coding
writing good code requires a lot of practice
reading code requires a lot more practice
code isn't done, when the problem is solved
sometimes it is more productive to delete lines of code instead of adding
beware of "this is draft code which will be changed later" - later easily becomes "never"
being new to a codebase introduce new paradigms and technologies carefully - perhaps the guy before you did and the guy before that did and that is the reason for the mess looking at you and giving you the urge of "having to clean up"
every line of code has a reason why it is like it is - although the reason was that the one who wrote it, did not knew better at the moment
do not be afraid to google - everybody does; but the experts use smarter queries
every programming language sucks
every programming language is dead - some are dead for decades
do not read »Why I left x for y« posts. They are only prequels to »Why I left y and came back to x - new sides of an old love«
do not read posts about »Why x is faster than y« because most people suck at benchmarking - unless you are Brendan Gregg or read a post from Brendan Gregg about benchmarking
stop writing to-do-list-apps in your sparetime unless you are doing a todo list on all the languages you want to write a todo-list-app in
learn languages you love - you will be good at it!
resist job offers for languages you do not love - it will suck and good payment doesn't help
be lazy - automate the hell out of your workflow. Machines have no bad days.
try to write as less code as possible to make lazy readers happy and bugs having a hard time to hide. Remember: »If debugging is the process of removing bugs, then programming must be the process of putting them in.« Edsger Dijkstra.
Do not outsmart yourself: »Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?« Brian Kernighan
I'm good a benchmarking and profiling. I tell all my interview candidates to stop worrying about optimization. I tell my colleagues they're measuring wrong. It's hard. Sounds like a good chapter on its own.
Just a few points:
you are spending the least of your time actually coding
writing good code requires a lot of practice
reading code requires a lot more practice
code isn't done, when the problem is solved
sometimes it is more productive to delete lines of code instead of adding
beware of "this is draft code which will be changed later" - later easily becomes "never"
being new to a codebase introduce new paradigms and technologies carefully - perhaps the guy before you did and the guy before that did and that is the reason for the mess looking at you and giving you the urge of "having to clean up"
every line of code has a reason why it is like it is - although the reason was that the one who wrote it, did not knew better at the moment
do not be afraid to google - everybody does; but the experts use smarter queries
every programming language sucks
every programming language is dead - some are dead for decades
do not read »Why I left x for y« posts. They are only prequels to »Why I left y and came back to x - new sides of an old love«
do not read posts about »Why x is faster than y« because most people suck at benchmarking - unless you are Brendan Gregg or read a post from Brendan Gregg about benchmarking
stop writing to-do-list-apps in your sparetime unless you are doing a todo list on all the languages you want to write a todo-list-app in
learn languages you love - you will be good at it!
resist job offers for languages you do not love - it will suck and good payment doesn't help
be lazy - automate the hell out of your workflow. Machines have no bad days.
try to write as less code as possible to make lazy readers happy and bugs having a hard time to hide. Remember: »If debugging is the process of removing bugs, then programming must be the process of putting them in.« Edsger Dijkstra.
Do not outsmart yourself: »Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?« Brian Kernighan
I'm good a benchmarking and profiling. I tell all my interview candidates to stop worrying about optimization. I tell my colleagues they're measuring wrong. It's hard. Sounds like a good chapter on its own.
Ah yes, the love affair with todo lists.
Depending on the language, the JIT (-Compiler) optimizes the code anyway - until it doesn't :D
Yes. I tell people to write decent code - the compiler does the rest.