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.
- Your Problem with Vim is That You Don’t Grok Vi
- Why clean code is more important than efficient code |…
- Are Libertarians Suffering From Technology’s XY…
- Polygot Programmers
- More People Need to Program
- How can I teach a bright person, with no programming…
- Programming as a Life Skill
- How to Write Without Writing | Coding Horror
- Creative Problem Solving with SCAMPER
- The Only Two New Years Resolutions You Need