- Stick to one computer as your workstation. If you use multiple computers they will tend to get out of sync WRT setup fairly quickly, especially if you are evaluating a lot of new technologies. Small niggling differences really slow you down. Using SCM will help, but it only goes so far.
- The computer you like to work on may surprise you. But when you discover it, go with it. (I found that I like to work on my ultra-portable more than my more powerful PC.)
- I think one of the reasons I like Quirky better is that, from the beginning, I treated it as a kind of "disposable PC" - as thin client as possible. Of course, I ended up installing things like Eclipse. But that attitude really helped me keep things simple. I was never tempted to tweak anything or add anything "risky" to the machine, or do any major surgery on it. Because of that, it's stayed very nimble. Another reason I like it is because the keyboard is clickier. :) Of course, I really don't like the fact that the hard drive is clicky! Perhaps when the price of solid state hard drives come down...
- Have a work computer, and a play computer. Another reason Quirky is better for me is that I don't use it for playing around. Sumi has some games, and it also has peripherals attached which have associated TSRs. (I do have some some simple games to show off the tablet, though!)
- Know what's important in an operating system. First and foremost is stability. It just can't crash. You need a wide selection of software, and if you have peripherals that are important to you, use them. Aesthetics are important, too. Macs are a bit too feminine for my tastes - I like the angular, black look of the Thinkpads. The iPhone "slab" look is pretty good, too, which probably means I'll get the Apple tablet when it comes out.
- Programming is different than thinking about programming better, or ways to make a team work better together. It's easy to get distracted by new tools, libraries, processes etc. Every tool will have deficiencies, and the perfect tool just doesn't exist.
- NIH 'syndrome' is a double-edged sword - sometimes it's actually appropriate to re-invent something before adopting a 3rd party solution; it's an (expensive, but necessary) learning process. Corallary: you don't really understand something until you've built it.)
- Dynamic programming is a different ball of wax - you often don't get code completion. Bad habits like misspellings will kill you. You must know the object model really well.
- Recognize when you're in new cognitive territory, and don't start from the middle. Sha hu ri, baby. You may be an accomplished programmer, but learning a new language and new libraries is a big deal. It takes time. It's an especially big deal moving from different kinds of languages - e.g. from Java to JavaScript (which, despite the similar names, are worlds apart). If there is truly reason to make such a huge addition to your toolkit, take the time to learn the technology properly. For JavaScript, that means reading some good books all the way through, doing exercises, writing "bare metal" code first - forget about using all the abstractions (libraries and tools) that exist out there. If you can afford it, hire a teacher.
- Don't add new tools until you need them. This requires that you be aware of your needs.The drawback is that you may get stuck in a situation where the thing you needed just doesn't exist. But you'll only do that once, and you'll know why your going down the path that you're now on. So, don't pull in libraries that you don't need - they are complexity barnacles that just slow you down. Don't get too caught up with new technologies, and take hot new tools with a huge grain of salt.
- Pay attention to the people behind technologies that you like. Sometimes they want to hide (probably from demanding users) but someone who makes something good is likely to make something else that's good. Send a thank you note or a word of encouragement - don't be shy with praise for open source stuff. People like PPK, like Oliver Steal, like....
- Internet researcher is a full time job. Maybe even more than a full-time job. There's a lot of stuff out there, and researching is a different skill set than programming, and like anything, over time you get better at it. But it's still another job. Researching new technologies is not an easy thing, especially when you're "not in the space".
12 Simple Programmer Lessons
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment