I have written about this earlier, and its continuing relevance - buttressed by my day-to-day experiences - propels me to reproduce it here again.
In his blog, John Cook refers to a comment made by Joe Armstrong (chief creator of Erlang) about the use of tools while writing or learning to write programs. In response to a question about which editor/IDE/tools to use to get familiar with the development path in Erlang, he says '.. I am old school - you don't need any fancy tools. Just a text edit and an erlang shell.'
This has gotten me thinking about the very queer predilection of the young developers - who I meet almost everyday in my daily professional life - towards Graphical tools/IDEs. They are very comfortable the moment their preferred IDE is open in front of them. They are quick to create/open/modify/close 'projects'; their dexterity with various keystroke combinations is to be marvelled at; they move around various panes, buttons and windows with the mouse like a supremely confident general strutting around the war-field from which all strands of the enemy have been exterminated. But almost always, they are oblivious to what is happening underneath. More to the point, a majority of them are unlikely to know how the compiler works, how the symbols are loaded and resolved and how various libraries/components come together at the runtime. How to quickly check what is the date-time stamp of a certain class file inside a JAR after freshening? How to keep an watch on the log generated by a daemon server and monitor if a certain output pattern emerges? Almost always, they don't have an answer.
The question that I usually face whenever I meekly raise these points is 'Is there really a need?'. When an army of developers are fighting against impossible deadlines set by people who haven't really been in the trench, isn't it prudent to 'just go and finish it' with whatever help is available, rather than to 'sit back and understand what's happening'? Put in a different way, it makes no real sense for them to think, but to do. Time is of essence, which has a synonym: money! Completion of the job at hand matters more, not its analysis.
In an industry - where programmers are considered mere 'coders' and are dubbed as 'resources' rather dismissively - it is unsurprising that thinking is not valued. Eclipse - the ubiquitous IDE that Java developers are so comfortable with - allows one to write the code, automatically compile it, debug if necessary, create libraries (JARs), deploy them and even run them in a Server mode. All these require a few keystrokes. A lot can be 'finished' in a short time. But, does it help the programmers to understand what is happening underneath? After all, Eclipse is firing the same commands which we would have otherwise fired from command lines anyway. It is relieving us from the drudgery of having to fire those commands many times over during the development phase. It is a facility. But it is not a replacement of the knowledge. The sooner we understand this, the better.
Every top-notch programmer that I have come to know or know about or idolize, is quite comfortable in the hard-labour world of shells, command lines and OS to do a few things for them. They know that there is no short-cut to gaining understanding of technology. They value the impression that these understandings leave on their thought-processes. This helps them to foresee the possible problem spots, which in turn equip them to tackle the problems in a more controlled manner or to avoid the problems altogether. They use the IDEs to shorten the time required to finish the work, but never allow the IDEs to enslave them. In some cases, they create their own tools, which work more proficiently than the IDEs.
Before I begin to get the brickbats, let me say this in self-defence: I am not against using IDEs. I use Eclipse everyday and it surely is a great companion to have. But, it doesn't supplant the wealth of understanding that I get from working with the good old Linux shell, a Java compiler and various directories full of Java files (source and compiled).
In his blog, John Cook refers to a comment made by Joe Armstrong (chief creator of Erlang) about the use of tools while writing or learning to write programs. In response to a question about which editor/IDE/tools to use to get familiar with the development path in Erlang, he says '.. I am old school - you don't need any fancy tools. Just a text edit and an erlang shell.'
This has gotten me thinking about the very queer predilection of the young developers - who I meet almost everyday in my daily professional life - towards Graphical tools/IDEs. They are very comfortable the moment their preferred IDE is open in front of them. They are quick to create/open/modify/close 'projects'; their dexterity with various keystroke combinations is to be marvelled at; they move around various panes, buttons and windows with the mouse like a supremely confident general strutting around the war-field from which all strands of the enemy have been exterminated. But almost always, they are oblivious to what is happening underneath. More to the point, a majority of them are unlikely to know how the compiler works, how the symbols are loaded and resolved and how various libraries/components come together at the runtime. How to quickly check what is the date-time stamp of a certain class file inside a JAR after freshening? How to keep an watch on the log generated by a daemon server and monitor if a certain output pattern emerges? Almost always, they don't have an answer.
The question that I usually face whenever I meekly raise these points is 'Is there really a need?'. When an army of developers are fighting against impossible deadlines set by people who haven't really been in the trench, isn't it prudent to 'just go and finish it' with whatever help is available, rather than to 'sit back and understand what's happening'? Put in a different way, it makes no real sense for them to think, but to do. Time is of essence, which has a synonym: money! Completion of the job at hand matters more, not its analysis.
In an industry - where programmers are considered mere 'coders' and are dubbed as 'resources' rather dismissively - it is unsurprising that thinking is not valued. Eclipse - the ubiquitous IDE that Java developers are so comfortable with - allows one to write the code, automatically compile it, debug if necessary, create libraries (JARs), deploy them and even run them in a Server mode. All these require a few keystrokes. A lot can be 'finished' in a short time. But, does it help the programmers to understand what is happening underneath? After all, Eclipse is firing the same commands which we would have otherwise fired from command lines anyway. It is relieving us from the drudgery of having to fire those commands many times over during the development phase. It is a facility. But it is not a replacement of the knowledge. The sooner we understand this, the better.
Every top-notch programmer that I have come to know or know about or idolize, is quite comfortable in the hard-labour world of shells, command lines and OS to do a few things for them. They know that there is no short-cut to gaining understanding of technology. They value the impression that these understandings leave on their thought-processes. This helps them to foresee the possible problem spots, which in turn equip them to tackle the problems in a more controlled manner or to avoid the problems altogether. They use the IDEs to shorten the time required to finish the work, but never allow the IDEs to enslave them. In some cases, they create their own tools, which work more proficiently than the IDEs.
Before I begin to get the brickbats, let me say this in self-defence: I am not against using IDEs. I use Eclipse everyday and it surely is a great companion to have. But, it doesn't supplant the wealth of understanding that I get from working with the good old Linux shell, a Java compiler and various directories full of Java files (source and compiled).
I think using commandline tools(as a first resort) also can provide a higher level of knowing what is happening. Do you think, the Java sort of programming (which hides details, not entirely w/o merit) encourages the IDE based systems-view? The other reason I think command-line is very useful, is repeated run of a sequence of commands (with possibily minor modifications on each iteration) is much faster and also has something of a execution trail.
ReplyDelete