5 ms·

Productivity Tips for Programmers

49 points by rvivek 16y ago

gkoberger 16y ago
It's down now; here's a cache: http://webcache.googleusercontent.com/search?sclient=psy&hl=en&client=firefox-a&hs=FuF&rls=org.mozilla%3Aen-US%3Aofficial&source=hp&q=cache%3Ahttp%3A%2F%2Fblog.interviewstreet.com%2F%3Fp%3D603&btnG=Search&aq=f&aqi=&aql=&oq=cache%3Ahttp%3A%2F%2Fblog.interviewstreet.com%2F%3Fp%3D603&gs_rfai=&pbx=1 http://webcache.googleusercontent.com/search?sclient=psy&#38...
satyan 16y ago
Seems down.. Can also view a copy here.. http://onsoftwareandstuff.com/2010/10/12/productivity-tips-for-programmers/ http://onsoftwareandstuff.com/2010/10/12/productivity-tips-f...
rvivek 16y ago
Apologies. It's up now. You can view the post at the original link -> http://blog.interviewstreet.com/?p=603 http://blog.interviewstreet.com/?p=603
antileet 16y ago
While it was well written, and with best intentions, I don't think there is any real significant "tips" to increase "productivity". All things aside these are just some best practices sprinkled with some examples. This is similar to when your parents tell you to brush your teeth and floss daily. I haven't been programming a lot but here are some ideas that I've found, in similar vein to the parent article. 1. Watch Bram Moolenaar's talk or read his notes - http://www.moolenaar.net/habits.html http://www.moolenaar.net/habits.html . Essentially learn how to use your text editor, as that's the thing you're going to be spending a good deal of your time in. In three steps, his suggestion is - Find what you're doing repeatedly, automate it and bind it to a key, make it a habit. 2. use a good version control system. Use a DVCS like git/mercurial/bzr and make lightweight branches for even the tiniest little features. That'll allow you to multitask like crazy! If you start properly using branching, you can write more code quickly and safely and switch between contexts. 3. Make sure your build system is optimal. If you spend too long waiting for builds to take place, maybe you can explore options to make it better. 4. The most important productivity secret imo - ACTUALLY WRITE CODE. Don't think about writing code, don't read blogs about writing code, don't follow twitterers who write code. Most importantly, don't get distracted and idle away when you're trying to write code. I have some amount of mastery over my text editor, my language, my OS, etc. But none of that compares to the mastery and discipline of sitting down, concentrating and not letting your mind wander too much - something that I am trying to attain, but it's harder than I would like it to be.
- sp2hari 16y ago
  Hi, I agree with you that these points are basic, but at times we forget the very basic stuff and miss out things there.. Totally agree with your 4th point. Unless you actually write code, nothing will help you..
  - cdavid 16y ago
    You have to write code at some point, but you also have to think about what you are doing. Especially in time-constraints environments, there is a big risk doing a lot of code which ends up totally useless because it was not well thought, and did not do what was intended, etc... More important than unit test and all that trivial stuff, what matters a lot in my experience is the ability to write for changes. That's really what's difficult about most programming tasks: how to deal with changing specs, change of deployment environments, etc...
    - satyan 16y ago
      @cdavid agree with you on forward thinking. Don't agree on Unit test being trivial. Infact, it is one of the things that aid you with changing specs and code. It helps you change your code with confidence. That really matters. I appreciate your overall point, had just one correction. thanks.
      - cdavid 16y ago
        I should have explained what I mean by trivial: I think any competent programmer knows the value of testing. So in that sense saying that you should write tests is like saying you should write good code - it is true, but not very insightful. In a time constraint environment, you often need to make a choice between more tests and more features, etc... I have seen a lot of people who said their code was great because it was well tested, but then the tests depend so much on the implementation that it actually goes against better code (since refactoring may mean breaking a lot of unit tests). So the more interesting question is: what to test, how, and how far. For example, my own rule for testing is that in general, I don't test something if testing it takes more code than the feature itself (except for regression testing, and things which really play well with testing, like parsers and the likes, and code which needs to run on many different platforms). It is also useful to recognize when testing has value, and to avoid overestimating its actual benefits. Too often, people don't really think about failures when testing, or how the API it exercices can be used in a straightforward manner or not. For example, I don't get so much the value of TDD - I find it much more useful to think in terms of API usecases, for which small tests are often not well suited. Sure, designing for easy testing can help, but you can get the same benefit without TDD in my opinion. Finally, too often, I see "this library is well tested" sold as a feature in open source projects - but test coverage is not a feature. Sure, everything else being equal, I would prefer a well tested library to a not well tested library. But everything else is not equal: there is a constant tradeoff between designing better API, getting a better documentation or installation process and testing.
froo 16y ago
Productivity tips for programmers: stop bumming around on HN and go code something.
lelele 16y ago
Not very insightful. Nice try, though. Here is the classic: http://www.joelonsoftware.com/articles/fog0000000043.html http://www.joelonsoftware.com/articles/fog0000000043.html

49 points by rvivek 16y ago

It's down now; here's a cache: http://webcache.googleusercontent.com/search?sclient=psy&hl=en&client=firefox-a&hs=FuF&rls=org.mozilla%3Aen-US%3Aofficial&source=hp&q=cache%3Ahttp%3A%2F%2Fblog.interviewstreet.com%2F%3Fp%3D603&btnG=Search&aq=f&aqi=&aql=&oq=cache%3Ahttp%3A%2F%2Fblog.interviewstreet.com%2F%3Fp%3D603&gs_rfai=&pbx=1 http://webcache.googleusercontent.com/search?sclient=psy&#38...

satyan 16y ago

Seems down.. Can also view a copy here.. http://onsoftwareandstuff.com/2010/10/12/productivity-tips-for-programmers/ http://onsoftwareandstuff.com/2010/10/12/productivity-tips-f...

rvivek 16y ago

Apologies. It's up now. You can view the post at the original link -> http://blog.interviewstreet.com/?p=603 http://blog.interviewstreet.com/?p=603

antileet 16y ago

While it was well written, and with best intentions, I don't think there is any real significant "tips" to increase "productivity". All things aside these are just some best practices sprinkled with some examples. This is similar to when your parents tell you to brush your teeth and floss daily. I haven't been programming a lot but here are some ideas that I've found, in similar vein to the parent article. 1. Watch Bram Moolenaar's talk or read his notes - http://www.moolenaar.net/habits.html http://www.moolenaar.net/habits.html . Essentially learn how to use your text editor, as that's the thing you're going to be spending a good deal of your time in. In three steps, his suggestion is - Find what you're doing repeatedly, automate it and bind it to a key, make it a habit. 2. use a good version control system. Use a DVCS like git/mercurial/bzr and make lightweight branches for even the tiniest little features. That'll allow you to multitask like crazy! If you start properly using branching, you can write more code quickly and safely and switch between contexts. 3. Make sure your build system is optimal. If you spend too long waiting for builds to take place, maybe you can explore options to make it better. 4. The most important productivity secret imo - ACTUALLY WRITE CODE. Don't think about writing code, don't read blogs about writing code, don't follow twitterers who write code. Most importantly, don't get distracted and idle away when you're trying to write code. I have some amount of mastery over my text editor, my language, my OS, etc. But none of that compares to the mastery and discipline of sitting down, concentrating and not letting your mind wander too much - something that I am trying to attain, but it's harder than I would like it to be.

sp2hari 16y ago
Hi, I agree with you that these points are basic, but at times we forget the very basic stuff and miss out things there.. Totally agree with your 4th point. Unless you actually write code, nothing will help you..
- cdavid 16y ago
  You have to write code at some point, but you also have to think about what you are doing. Especially in time-constraints environments, there is a big risk doing a lot of code which ends up totally useless because it was not well thought, and did not do what was intended, etc... More important than unit test and all that trivial stuff, what matters a lot in my experience is the ability to write for changes. That's really what's difficult about most programming tasks: how to deal with changing specs, change of deployment environments, etc...
  - satyan 16y ago
    @cdavid agree with you on forward thinking. Don't agree on Unit test being trivial. Infact, it is one of the things that aid you with changing specs and code. It helps you change your code with confidence. That really matters. I appreciate your overall point, had just one correction. thanks.
    - cdavid 16y ago
      I should have explained what I mean by trivial: I think any competent programmer knows the value of testing. So in that sense saying that you should write tests is like saying you should write good code - it is true, but not very insightful. In a time constraint environment, you often need to make a choice between more tests and more features, etc... I have seen a lot of people who said their code was great because it was well tested, but then the tests depend so much on the implementation that it actually goes against better code (since refactoring may mean breaking a lot of unit tests). So the more interesting question is: what to test, how, and how far. For example, my own rule for testing is that in general, I don't test something if testing it takes more code than the feature itself (except for regression testing, and things which really play well with testing, like parsers and the likes, and code which needs to run on many different platforms). It is also useful to recognize when testing has value, and to avoid overestimating its actual benefits. Too often, people don't really think about failures when testing, or how the API it exercices can be used in a straightforward manner or not. For example, I don't get so much the value of TDD - I find it much more useful to think in terms of API usecases, for which small tests are often not well suited. Sure, designing for easy testing can help, but you can get the same benefit without TDD in my opinion. Finally, too often, I see "this library is well tested" sold as a feature in open source projects - but test coverage is not a feature. Sure, everything else being equal, I would prefer a well tested library to a not well tested library. But everything else is not equal: there is a constant tradeoff between designing better API, getting a better documentation or installation process and testing.

froo 16y ago

Productivity tips for programmers: stop bumming around on HN and go code something.

lelele 16y ago

Not very insightful. Nice try, though. Here is the classic: http://www.joelonsoftware.com/articles/fog0000000043.html http://www.joelonsoftware.com/articles/fog0000000043.html