【转】My Top Ten Tips on how to become a Rockstar Programmer
Saturday, 4. July 2009, 11:15:40
说的经典啊
You will notice that there are no micro coding tips&tricks below. No info on how to make a fast for loop or such. The tips I post is what I think you should do to learn how to learn those tricks for yourself. In all, this list is a little softer around the edges and goes mostly for the background things.
Most noticeably you will see things that are totally opposite to what most recognized people say about how to code. This is probably because there is actually a difference in target audience. This is about you , and how you should become a great coder, maybe even a rock star coder! They often say how you should do to write good and portable code that other coders can understand and maintain.
#1 Do development on a fast computer
Wicked fast even. Compiling should take at most a couple of seconds so that you do this often. In fact what is most important is how long it takes from you hitting that Run Project short key until your application shows up. The lesser the time the more you will run the application and the more keen you will be to try new things, which is how you learn. If running takes too long you will go for, not safer, but code you know to work, and you will evolve more slowly. A good advice is also to keep a crappy computer around for testing. Your GUI might feel snappy on your super fast developer monster machine, but your customers might not be so lucky as to have one of those.
#2 Use a big TFT screen
Code is talking to you in more than characters. With a bigger screen you will get more overview and this helps your right side brain into the game. You will see patterns more clearly and you can see the structure of a whole method and not just parts of it. You should have such a big screen that your methods will fit, in most cases, on one page. Eyes move fast, editor scroll panes do not. I use a 30 inch Apple CinemaDisplay and a 20 inch Dell rotated 90 degrees as a second debugging monitor.
#3 Learn your IDE
It matters less what IDE you use, today they are all above the good enough bar. Be ashamed every time you do something in a way you know you can do faster another way. Learn a new feature of your IDE until you have learned them all, or at least learned enough. Use short keys but don't over exaggerate. Be super lazy and create short cuts for everything you do. All to keep down the waiting time and minimizing the most important code-to-show time.
#4 Don't learn APIs too well
The APIs might change and/or you might start to use another API. Learn how to find information about the APIs really fast. Use your IDE for this where appropriate. Use JavaDoc for your own code and mount the JavaDocs in your projects for imported APIs. Knowing how to find information is good for everything, storing APIs in brainRAM is bound to get old. If for instance you don't use some sort of parameter help/completion you have a long walk ahead.
#5 Write smart cool compressed code constructs
And test them thoroughly! You will learn what works and what don't. You will evolve, not to use the smartest and coolest code, but in terms of knowing that smart code constructs is seldom the way of the rock star programmer, other than for showing off. Less code, in a smart way, means less to maintain. Over-smart code that is just for show will make your fellow code maintainers put "fart bags" on your chair just when the new super-hottie from the Rocket Scientists Department comes over to ask you a question (which would be a bad thing).
#6 Read books
You might be good at what you do, but knowing only that, whatever it may be, is seldom enough to really shine. Knowing enough about more fields than the field you are about to shine in is golden. Take for instance a GUI coder that knows nothing about databases. He might be almost useless since he can't interact with the guy doing the backing store, and so on. It takes as much effort to be 90% good in five fields than to be 99% good one one.
#7 Go back and enhance your old code
Not that it is sound from an economical point of view but because you learn oodles of things reading you own crap, which old code always is. Code gets rotten after a couple of years, it really does, since you evolve. If you can't find bad things in your old code you either already are a rock star programmer, or maybe more probable, hasn't evolved much lately.
#8 Eat your own dog food!
If you create APIs, create some applications using that API. If you create applications, ask your friends/wife(s)/husband(s)/children to try it. Don't say you did it; say that your crappy no-good overpaid work mate did it, so you get some honest feedback. Honest feedback is golden.
#9 Don't ask people for advice
Learn how to get that answer yourself instead, it is way more useful. Finding out how to get information about something is a value in itself and may pay you back more than the solution to the problem in the first place. Ask only if you must or if the question in itself is more a discussion and you are actually spreading information. Of course you shouldn't take this too literally, but I see lots of people asking pointless questions they could have found out faster by ten seconds of googling.
#10 Do micro benchmarks
But know that they are useless for almost all purposes in the real world. It will increase your knowledge about performance though, and next time you have a higher probability of choosing the fastest construct for new code. Don't do premature code optimization but learn how to write fast code from the start, without sacrificing readability.
#11 And last...
Eat right, exercise more, don't drink too much coffee, and all that other crap that matter more than you think, but you won't do because I said so.
Have you got things to share?
Cheers,
Mikael Grev
You will notice that there are no micro coding tips&tricks below. No info on how to make a fast for loop or such. The tips I post is what I think you should do to learn how to learn those tricks for yourself. In all, this list is a little softer around the edges and goes mostly for the background things.
Most noticeably you will see things that are totally opposite to what most recognized people say about how to code. This is probably because there is actually a difference in target audience. This is about you , and how you should become a great coder, maybe even a rock star coder! They often say how you should do to write good and portable code that other coders can understand and maintain.
#1 Do development on a fast computer
Wicked fast even. Compiling should take at most a couple of seconds so that you do this often. In fact what is most important is how long it takes from you hitting that Run Project short key until your application shows up. The lesser the time the more you will run the application and the more keen you will be to try new things, which is how you learn. If running takes too long you will go for, not safer, but code you know to work, and you will evolve more slowly. A good advice is also to keep a crappy computer around for testing. Your GUI might feel snappy on your super fast developer monster machine, but your customers might not be so lucky as to have one of those.
#2 Use a big TFT screen
Code is talking to you in more than characters. With a bigger screen you will get more overview and this helps your right side brain into the game. You will see patterns more clearly and you can see the structure of a whole method and not just parts of it. You should have such a big screen that your methods will fit, in most cases, on one page. Eyes move fast, editor scroll panes do not. I use a 30 inch Apple CinemaDisplay and a 20 inch Dell rotated 90 degrees as a second debugging monitor.
#3 Learn your IDE
It matters less what IDE you use, today they are all above the good enough bar. Be ashamed every time you do something in a way you know you can do faster another way. Learn a new feature of your IDE until you have learned them all, or at least learned enough. Use short keys but don't over exaggerate. Be super lazy and create short cuts for everything you do. All to keep down the waiting time and minimizing the most important code-to-show time.
#4 Don't learn APIs too well
The APIs might change and/or you might start to use another API. Learn how to find information about the APIs really fast. Use your IDE for this where appropriate. Use JavaDoc for your own code and mount the JavaDocs in your projects for imported APIs. Knowing how to find information is good for everything, storing APIs in brainRAM is bound to get old. If for instance you don't use some sort of parameter help/completion you have a long walk ahead.
#5 Write smart cool compressed code constructs
And test them thoroughly! You will learn what works and what don't. You will evolve, not to use the smartest and coolest code, but in terms of knowing that smart code constructs is seldom the way of the rock star programmer, other than for showing off. Less code, in a smart way, means less to maintain. Over-smart code that is just for show will make your fellow code maintainers put "fart bags" on your chair just when the new super-hottie from the Rocket Scientists Department comes over to ask you a question (which would be a bad thing).
#6 Read books
You might be good at what you do, but knowing only that, whatever it may be, is seldom enough to really shine. Knowing enough about more fields than the field you are about to shine in is golden. Take for instance a GUI coder that knows nothing about databases. He might be almost useless since he can't interact with the guy doing the backing store, and so on. It takes as much effort to be 90% good in five fields than to be 99% good one one.
#7 Go back and enhance your old code
Not that it is sound from an economical point of view but because you learn oodles of things reading you own crap, which old code always is. Code gets rotten after a couple of years, it really does, since you evolve. If you can't find bad things in your old code you either already are a rock star programmer, or maybe more probable, hasn't evolved much lately.
#8 Eat your own dog food!
If you create APIs, create some applications using that API. If you create applications, ask your friends/wife(s)/husband(s)/children to try it. Don't say you did it; say that your crappy no-good overpaid work mate did it, so you get some honest feedback. Honest feedback is golden.
#9 Don't ask people for advice
Learn how to get that answer yourself instead, it is way more useful. Finding out how to get information about something is a value in itself and may pay you back more than the solution to the problem in the first place. Ask only if you must or if the question in itself is more a discussion and you are actually spreading information. Of course you shouldn't take this too literally, but I see lots of people asking pointless questions they could have found out faster by ten seconds of googling.
#10 Do micro benchmarks
But know that they are useless for almost all purposes in the real world. It will increase your knowledge about performance though, and next time you have a higher probability of choosing the fastest construct for new code. Don't do premature code optimization but learn how to write fast code from the start, without sacrificing readability.
#11 And last...
Eat right, exercise more, don't drink too much coffee, and all that other crap that matter more than you think, but you won't do because I said so.
Have you got things to share?
Cheers,
Mikael Grev
，突然听到门剧烈的响动
，偶第一反应是谁这么没礼貌，砸门啊？
我站起来正要去看门，就发现电脑屏幕，桌子开始晃动，
，随后感到地板也开始抖动，站立困难。
苍天啊，成都居然会有地震？
遂抓起一个座垫就往厕所里躲，蹲在地上，捂住头部，上帝啊，让这一切都快点结束吧
。真是“心随地动”啊，可怕的剧烈震动持续了大概1分多钟，一切恢复平静，可家里早已是一片狼藉，已顾不得其他，穿上鞋子、披上外衣就冲到楼下。。。。。。。。。
，为他们做点力所能及的事，天佑中华，为他们祈福！
当累加到1500元，在主持人的不断提示下终于有人答对了，
此刻我的耳边也传来了移动小姐清脆的声音：“对不起，你的电话已欠费。”
WIDGETIZE