On developer productivity Part 1

Firstly, there’s a sharp difference between being a developer and a programmer, in my opinion.

While both consist of writing code, some programs are experiments, hacks or tiny tools, compared to extremely large applications with thousands and thousands of lines of code and with many people working together with lots of source control, modules, unit tests, etc.

But the funny thing is, college seldom seems to teach people about how to make their code writing better. Most people were told to use emacs in their first sitting and still do. While emacs(ugh), or vi(yay!) is perfect for managing about a 1000-2000 line codebase, something better is required.

The biggest trouble is, at the end, that people do not want to learn anything which won’t directly give them marks, or help them finish their project, even though it may mean shaving off many hundreds of hours in the course of it’s use.

For a change, I won’t rant. I’ll rather give use cases comparing the current IDE I’m using, with what most people tend to do.

Note that this is largely C++ specific, but widely applicable.
I use the C++ Development Tools for Eclipse (CDT/Eclipse) as my development environment.

  1. Code completion: While most people think that code completion just helps ease out programming, it doesen’t. What it does do, is prevent mistakes while writing the code in the first place.

    I can safely agree it makes you a better programmer if you know what functions to call, and you know exactly what they are, and refer to the original source code to see how it’s spelled. But in typical scenarios, if I use a class once, and need a member of that, I can’t open that file, search for the function, see the definition and use it. I can just use code completion and be done with it.

    Code completion has also helped me prevent spelling errors so many hundreds of times.

  2. Debugging:

    The thing that annoys me most is when the first thing most people do when a bug exists is print out the values of the variables for every point. While this is a great method for examining patterns sometime, you *need* to know how to fire up a debugger, and you can watch all the variables you want.

    In extreme cases, like remote programs, or programs with large amounts of looping, logs are fine. However, logging is extremely important to notify stderr/stdout about important events.

    However, I find myself setting a breakpoint far before I try to print out the values of variables to the screen. They also start polluting stderr/stdout after sometime

  3. Jump to method:

    Here’s one more that helps while writing code which uses code other people’ve written. CDT/Eclipse allows you to Ctrl+Click on an object to jump to it’s definition. Another great feature is the ability to jump to a definition/declaration by typing in the first few letters of the method and finding the right one and hitting enter.

    This has saved me a ton of time.

  4. Pre-emptive bug checking:

    CDT/Eclipse does a very good job of this. I haven’t seen any other IDE do this so well. Most common bugs like forgetting to put a semicolon, or close a bracket, are given as warnings by the IDE, *while* you’re typing in the code, and it’s extremely unobtrusive. The best part is however is when you use a symbol that’s not in the scope or is not defined, the symbol name turns dark brown colored text(which is noticeable while not distracting), and it’s most often a typo in the filename. It would’ve been a nightmare to implement, but is a huge blessing.

Now I’m off to do work, writing code with my second favorite IDE, I’ll write another part later hopefully. I didn’t bother editing/proofreading this page(I never do), and it’s only a rant. It’s best you seek more authoritative sources on integrated development environments.

My favorite IDE however, has to be Visual Studio, and I unfortunately never use it.

2 Responses to “On developer productivity Part 1”


  1. 1 anomit

    Exactly what I felt. I mean I have written code for finding out the MST of a connected graph. I would term that as programming. But when implementing that concept for the OSPF protocol in a network simulation framework, I had to keep a javadoc open for keeping track of the attributes of other classes that would define the network. Without an IDE, I would have probably gone insane. The proper visual depiction of the classes and their members in the IDE saved me a lot of time. I guess this would actually count as development.

  2. 2 sindhu

    we don’t have an ide for java at college, look at me: am not okay :/

    i keep hitting ls in command prompt.

Leave a Reply