Okay,
one more time around.
Originally Posted by
mwildam
It is very seldom that I really do have to perform debugging at the production client if I produce good logfiles. If I have to do debugging I actually maybe have to do some manual work and testing.
I wasn't talking about code errors, though. I was talking about someone having made a mistake modifying the class path when adding a new library (either forgetting about it or, sometimes even, the order), or that the packaging has gone wrong (which also happens and can be notoriously hard to find if you simply entrust it to your tools without knowing what it should be doing behind the scenes, especially when RMI comes into play, and the like), and those types of errors. The structural things. And, since those structural things are either built (in the case of the packaging), or even worse, only described, by the development department (through the Quality Assurance department, if your company is smart even to have one), those things are the developers responsibility, he
needs to know them inside and out.
The company I work for does not decide about the tools I have to use. The tool to use must be decided by the developer(s) and not by some manager never doing a line of code. If a group of developers decides to change IDE there might be pretty good reasons and then it might be worth learning the new IDE. And actually if component separation is done as it should it should either make no difference if developer A is using Eclipse and developer B is using NetBeans for example. In our projects C++, C# and VB are mixed while components are separated appropriately.
Well, large pieces of software also have multiple people working on the same "component". That component is broken down into modules, to be sure, but they are all closely tied enough that they at least must be the same language. But, regardless of those points, managers
do decide, many times.
I do learn things usually top-down: When I find out that for instance the default ANT-packaging in NetBeans does not fit my needs than I will dig into it. Just because I want to get my first productive project running does not mean that I will not go into details later - definitely not!
But I think that how fast you can get productive with a programming language and available IDE(s) is an important thing how it will spread out. Software Development does not get easier with the time and it will become more difficult to find good programmers if the learning curve (until the first results for production) is so flat.
I don't find the learning curve flat, however. Like I said, I don't believe you cut that much time out of the process using an IDE. While learning, what is to be used is usually pretty narrowly defined, so there isn't a lot of searching in the docs so it is only a few extra seconds per "need" (and you naturally aquire the habit of reading the docs, first), and it takes a little extra time learning how to use the classpath, jar, javac, and java commands themselves (but that little bit of extra time brings a whole lot of understanding along with it).
I agree, that the extraneous tools (like ant and the varying plugins) can be learned on the side (but they should be learned), but those tools vary from IDE to IDE (if they exist for the IDE at all), and so
must wait until you start learning the IDE anyway (otherwise the learning curve really would be flat). But the thing is, you shouldn't
need to learn the IDE. If you know all of the Java basics (and I am not talking any kind of enterprise stuff here, all that comes later) all you need do is
explore the IDE. There should be no real "learning" involved.