#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.
0 comments:
Post a Comment