Top Ten Habits of Successful Programmers

来源:http://codepad.classhelper.org/top-ten-habits-of-successful-programmers/223/

Around the globe, millions of people are either working as software developers, or aspire to get paid for development work some day. These folks go by many names: software engineer, coder, and developer. At the end of the day, they’re all still programmers , people who understand how to translate what a computer needs to do into the code that gets the job done. To succeed at programming over the long term, a few simple rules need to be followed.

1. Never stop learning. Even if you’ve got thirty years of programming experience (I’ve only got a paltry fifteen), there’s always more to learn. New programming languages emerge periodically, existing languages evolve, and new frameworks come along to meet new needs. Spend some time each week reading industry journals, and keep tabs on popular online communities that focus on emerging trends in software development.

2. Know multiple languages, and know them well. If all you’ve got is a hammer, every problem looks like a nail. Some languages are better suited to certain tasks than others. While I’m sure someone out there is busy writing a first person shooter in Javascript, the end result will probably be less than awe-inspiring (aside from the fact that it’s written in Javascript, of course). Take some time to explore languages you’re less than familiar with; you’ll be equipping yourself to work on a more diverse range of projects. This translates to being more highly valued in the marketplace.

3. Get comfortable with different operating systems. We all have our favorite OS; mine happens to be Ubuntu Linux on the desktop, with Debian Linux on the server. That said, I try to keep up to date on Windows Server, FreeBSD, MacOSX, and Solaris. Part of being a good programmer is understanding the intimacies of the system you’re working on. This can make identifying bugs a heck of a lot easier, as the same program can (usually does) perform differently on various platforms. This is true for languages like Perl and Java, which are intended to allow easi(er) cross-platform development.

4. Don’t limit yourself to a single development environment. Again, everyone has their favorite tools. I’m pretty old-fashioned, as I prefer to do write mode of my code in gedit, with a simple terminal window for testing. Some folks prefer integrated development environments that allow them to more rapidly examine the relationships and dependencies between various parts of an application project. No matter what tools you’re using, try something different from time to time. You never know what might appeal to you, or help you work smarter.

5. Experiment with different source control systems. Plain vanilla CVS works for many teams, Subversion works for others, and Git meets the needs of a different group. Depending on the size of your team and their geographic dispersion, you may or may not be using the most efficient tool for the job. I prefer to use open source solutions, but some commercial packages may make more sense for you team.

6. Be a good team member. Unless you’re flying solo, cranking out apps into the wee hours of the morning, being a good team member is a huge part of your job. You might just be the most knowledgeable person in your group, but that doesn’t mean you should adopt the dreaded “prima donna” attitude. Good manners and frequent communications go a long way toward maintaining a pleasant work environment.

7. Document your work. This starts with the obvious mantra of “comment you code,” but it goes further than that. Well-commented code is the foundation of documentation, allowing you (and other team members) to understand what the heck you were doing in code you haven’t touched in six months. Overall project documentation should, at minimum, chart development milestones, provide easy access to requirements documents, contain logs of testing sessions, and have a section dedicated to security concerns. Not only will this save your company a lot of grief if you get hit by a bus crossing the street to the office, but it will help you stand out as an honest, professional developer.

8. Make backups. Lot of them. Almost everyone I know in the industry has been through at least one “oh, crap” event related to data loss. Stuff fails, it’s just a fact of life. Laptops get dropped, hard drives burn out, some enterprising new worm invades your enterprise, and entire buildings burn to the ground. Make sure you’ve got multiple copies of critical data stores, and make sure you’re doing daily (hourly, in some cases) incremental backups of your work. A set of backups should be kept at a separate geographic location for safety’s sake.

9. Keep your designs flexible. This applies to core coding practices (using standardized libraries, not reinventing the wheel, etc) and target deployment environments as well. You might be designing an application that your boss swears will only ever be used on a single browser, at a certain screen resolution, by a specific group of highly trained people. He doesn’t know it, but he’s probably telling you a fib. Applications have a habit of growing tentacles into various environments, and feature creep is always a concern. You don’t want to be caught off guard if your boss decides six months from now that your “best app in years” needs to run on portable devices that may or may not even have a persistent network connection.

10. Don’t burn yourself out. I have a really bad habit of telling myself that I can finish an application if only I stay up for a few more hours. This isn’t good for your body, your mental state, or the project itself. No amount of caffeine can replace a few hours of quality sleep, although you should feel free to experiment with different schedules. When projects permit, my most efficient most of operation is four hours of programming, followed by an hour-long nap, then four more hours of coding. Make sure your work environment isn’t full of constant interruptions, either… it can be really difficult to work with people whisphering in your ear every thirty minutes.

I hope this information is helpful to those who code for a living, and look forward to hearing your responses. Happy programming!