January 17th, 2010 | Uncategorized
- Set a duration of how long you think it should take to solve a problem – C’mon, admit it! I’m just as guilty as the next programmer. I’ve seen programmers sit in front of a monitor for eight hours at a time trying to solve a particular problem. Set a time table for yourself of 1 hour, 30 minutes, or even 15 minutes. If you can’t figure out a solution to your problem within your time frame, ask for help or research your problem on the Internet instead of trying to be super-coder.
- A language is a language is a language – Over time, once you understand how one language works, you’ll notice similarities between other languages. The language you choose should provide you with a suitable “comfort” level, the ability to produce efficient (and clean) code, and, above all, allow the language to suit the project and vice-versa.
- Don’t over-”design pattern” applications – Sometimes it’s just easier to write a simple algorithm than it is to incorporate a singleton or facade pattern. For the most part, it even allows for cleaner, understandable code. :-)
- Always backup your code – I’ve experienced a complete hard drive failue and lost a lot of code when I was younger and felt horrible because of what had happened. The one time you don’t back up your data may be the one time where you have a strict deadline with a client and they need it tomorrow. Source code/version control applies here as well.
Please read the rest of the 20 steps at Jonathan’s site.
I’d love to hear from you. If you’d like to connect or respond, please reach out via Twitter, using DISQUS below, or by email. Also consider subscribing to the site via RSS and checking out my other content.blog comments powered by Disqus