4 ms·

If you want to write code faster - I have 3 letters for you - I D E. Learn your IDE, be it vim, textmate, IntelliJ or emacs. I used to use textmate (w/ default

If you want to write code faster - I have 3 letters for you - I D E. Learn your IDE, be it vim, textmate, IntelliJ or emacs. I used to use textmate (w/ default plugins) for HTML, CSS, Javascript and Ruby. Now I discovered IntelliJ does stuff really fast and works. IDEs/Editors have macros help you perform repeating work fast. TextMate allows you to run shell commands inside the editor which is pretty useful. There are few for Ruby if you want to see output of an execution as a comment (see Avdi's screencasts). There are shortcuts for performing tasks. In case your IDE does not provide, use the ones which your operating system supports. Example for Mac OS X - you can use Apple Scripts, Alfred, Keyboard Maestro etc.,). Take time reading your IDE manual or help. Graphical UIs show tips and suggestions. console based provide tutorials when you open without arguments. With vi, use :help and follow the article. It takes months or even years to understand and learn your IDE. Talking about downsides, once you start using your IDE a lot, you will learn about the downsides like 'pinky finger problem on emacs' (Google for this), and then you'll realize you have to customize your IDE. Note: These are good to have problems because you realize you are advancing. For HTML, ZenCoding as a plugin came out 3-4 years ago where you can use div.container>div.hello+div.details>span>a*3 (on tab) will expand and give you html. StackOverflow has lots of answers and details on discovery of productivity tools.

coldnebo 12y ago
I would also add: get to know your debugging tools really well. I'm constantly surprised how many developers still use print logging to debug issues with data structures. Sometimes it's hard to visualize what's going on in your mind or with the code, why not let the computer "play computer" and actually see what it's doing step by step. We may not have the real time integration that Bret Victor demos, but a call stack, watch list and breakpoints are a beautiful thing when you know how to use them. A REPL like Ruby's pry is also invaluable for exploring return data and playing with data access syntax right in the console without long tedious trial by error sessions. (I know this annoys the purists who think you should know the data structures beforehand -- they are right; if you know what you are doing, of course you'll be fast -- but sometimes even the smartest of us don't know a service api changed without popping the hood. Use all the tools you can to understand what your code is really doing, not just what you think it's doing.

coldnebo 12y ago

I would also add: get to know your debugging tools really well. I'm constantly surprised how many developers still use print logging to debug issues with data structures. Sometimes it's hard to visualize what's going on in your mind or with the code, why not let the computer "play computer" and actually see what it's doing step by step. We may not have the real time integration that Bret Victor demos, but a call stack, watch list and breakpoints are a beautiful thing when you know how to use them. A REPL like Ruby's pry is also invaluable for exploring return data and playing with data access syntax right in the console without long tedious trial by error sessions. (I know this annoys the purists who think you should know the data structures beforehand -- they are right; if you know what you are doing, of course you'll be fast -- but sometimes even the smartest of us don't know a service api changed without popping the hood. Use all the tools you can to understand what your code is really doing, not just what you think it's doing.