Comment Some tips (Score 1) 662
Some stuff I've learned over the years:
1. Learn to use Google and techie-based forums effectively for the language(s) you are using - 99 times out of 100 someone else has had the same problem you are facing and has solved it, and posted the solution
2. Get in good with your network admin - this is a must if you need network stuff done in a hurry!
3. Know when to code fast and ugly, and when to code elegant - whats the point in spending 2 hours to code the elegant solution when you KNOW your code is only going to be run once, and the 10 minute ugly version with hardcoded everything will work just as well?
4. When writing classes/methods/etc, think about the programmer who comes after you in 3/6/12/18 weeks/months/years time and has to modify what you've done. In most cases, it will be you and then you have to re-figure out what you did and why you did it that way. Make method names and variable names consistent and easy to understand, use the datatype of the variable in the name, etc...simple stuff like that helps enormously. The coding books can teach that stuff.
5. Linked to point 4....Comment, Comment, Comment! But do it wisely - dont comment each and every line but comment a "block" of codelines. Describe what the block is doing, and if its relevant, WHY you chose to code that way - there may be a certain reason to do with the database maybe, or with the network setup. It explains to the reader why the code reads the way it does. It keeps down the "WTF/min" count!
6. Dont refactor just 'cos you can - quite often you will come back to a piece of your code to fix a bug, and you'll find that since you wrote it, you've learned more stuff that you know will make this piece of code fly, but it involves major rework to the code. Resist the temptation (and the temptation will be there, believe me) to do the major rework! Your boss is expecting you to fix the bug, not re-invent the entire method, and if you post a fix time of 3 hours to a job that should have taken your 15 minutes...you wont win yourself friends with your boss. Plus you are introducing a new set of code to the system that requires testing, and all the stuff that goes along with that...
7. Bide your time - the way to get onto the big, interesting projects is to do the drudgey hack work in the beginning. Do the hack work well - keep your code efficent, relatively bug free, get it done ontime and the interesting stuff will come to you.
8. Bugs happen - just like life: make a mistake, learn from it, and try not to let it happen again. It is very rare that you will have a program run bug-free first time...and the more lines of code you have, the higher the chance it wont run first-time.
I'm sure there's more stuff, but you can figure it out yourself ;)
1. Learn to use Google and techie-based forums effectively for the language(s) you are using - 99 times out of 100 someone else has had the same problem you are facing and has solved it, and posted the solution
2. Get in good with your network admin - this is a must if you need network stuff done in a hurry!
3. Know when to code fast and ugly, and when to code elegant - whats the point in spending 2 hours to code the elegant solution when you KNOW your code is only going to be run once, and the 10 minute ugly version with hardcoded everything will work just as well?
4. When writing classes/methods/etc, think about the programmer who comes after you in 3/6/12/18 weeks/months/years time and has to modify what you've done. In most cases, it will be you and then you have to re-figure out what you did and why you did it that way. Make method names and variable names consistent and easy to understand, use the datatype of the variable in the name, etc...simple stuff like that helps enormously. The coding books can teach that stuff.
5. Linked to point 4....Comment, Comment, Comment! But do it wisely - dont comment each and every line but comment a "block" of codelines. Describe what the block is doing, and if its relevant, WHY you chose to code that way - there may be a certain reason to do with the database maybe, or with the network setup. It explains to the reader why the code reads the way it does. It keeps down the "WTF/min" count!
6. Dont refactor just 'cos you can - quite often you will come back to a piece of your code to fix a bug, and you'll find that since you wrote it, you've learned more stuff that you know will make this piece of code fly, but it involves major rework to the code. Resist the temptation (and the temptation will be there, believe me) to do the major rework! Your boss is expecting you to fix the bug, not re-invent the entire method, and if you post a fix time of 3 hours to a job that should have taken your 15 minutes...you wont win yourself friends with your boss. Plus you are introducing a new set of code to the system that requires testing, and all the stuff that goes along with that...
7. Bide your time - the way to get onto the big, interesting projects is to do the drudgey hack work in the beginning. Do the hack work well - keep your code efficent, relatively bug free, get it done ontime and the interesting stuff will come to you.
8. Bugs happen - just like life: make a mistake, learn from it, and try not to let it happen again. It is very rare that you will have a program run bug-free first time...and the more lines of code you have, the higher the chance it wont run first-time.
I'm sure there's more stuff, but you can figure it out yourself
