4 ms·

It's not that you need to use it. It's that you need to understand classpath and classloaders to solve some problems. And if you always use IDE automation there

by ajuc 5y ago

It's not that you need to use it. It's that you need to understand classpath and classloaders to solve some problems. And if you always use IDE automation there's no incentive until it's too late. Stuff is autoimported and autoinstalled. There's dozens of forms where you can add paths to classpaths depending on what button you press to run stuff. It's all magic when it works, and when it doesn't work it's random changes in random places to fix it. There's many more variables than if you just run the compiler from the command line. Good education should give you understanding of the basics, not just higher-level stuff. It's easier to learn high-level stuff when you got the basics down than to unlearn the "magic black box" approach and dive into basics when you need it.

KronisLV 5y ago
> And if you always use IDE automation there's no incentive until it's too late. Too late for what, though? At any point in time there's a certain subset of knowledge that's most relevant that you're trying to do. If it's learning overall programming concepts not the internals of a language which you may or may not use, then NOT using the IDE automation would be detrimental. Furthermore, in every single project that i've worked on professionally, attempting to manually manage dependencies and the way things are compiled would earn me odd looks, since that's far more tedious and less productive than just using Maven/Gradle. Not only that, but manually attempting to manage imports as opposed to letting my IDE do everything that's needed in the background would provide me precisely 0 benefit. In my eyes, "It just works", isn't a bad thing at all, as long as you: - can look into the lower level mechanisms (but only once actually needed) - can find information about all of it, to make the above easier Why would you "unlearn" something if you'll still use it in 95% of the cases, the lower level approaches being the outlier?
- ajuc 5y ago
  > in every single project that i've worked on professionally, attempting to manually manage dependencies and the way things are compiled would earn me odd looks, since that's far more tedious and less productive than just using Maven/Gradle Of course, we're not talking about doing javac manually when you're working, we're talking about learning the basics before going on to use the automation. BTW Maven and Gradle have plenty of gotchas of their own. If you don't understand what exactly happens you won't solve "magical" problems like old builds of non-snapshot versions remaining in the repo for example. > manually attempting to manage imports as opposed to letting my IDE do everything that's needed in the background would provide me precisely 0 benefit. you say that, and just last month I've had to help a guy manually remove an import of Token class from a wrong package that "magically broke his code" :) > Why would you "unlearn" something if you'll still use it in 95% of the cases, the lower level approaches being the outlier? Because I've seen a lot of people decide something that always worked is not their responsibility to fix when it doesn't work. That's how you end up with 1 guy in the company that understands the build system :)
  - KronisLV 5y ago
    > you say that, and just last month I've had to help a guy manually remove an import of Token class from a wrong package that "magically broke his code" :) Hmm, the IDE should offer you multiple classes to import from in a dropdown if there's any ambiguity, as well as highlight any of the methods that aren't present or whose signatures differ and provide popups with essentially the same information that you'd get from the compiler, without even having to compile the project. In that regard, i'd say that IDEs are actually superior. A single ctrl+click that'd take you to the source of the class that you've imported should also clear up any confusion about the import. Importing the wrong thing and not bothering to figure out why their code doesn't work honestly feels like not being familiar with the language itself (as opposed to the tooling) and for some reason not trying to figure it out on their own by reading what the IDE is telling them - to me, that does sound more like learnt helplessness than anything else, which would also manifest itself when writing code and running into design patterns that they don't understand, as well as any number of other situations. > Because I've seen a lot of people decide something that always worked is not their responsibility to fix when it doesn't work. That's how you end up with 1 guy in the company that understands the build system :) To me, this also feels like more of an organizational issue: if companies don't have a RACI matrix (https://en.wikipedia.org/wiki/Responsibility_assignment_matrix https://en.wikipedia.org/wiki/Responsibility_assignment_matr...) and have a low bus factor (https://en.wikipedia.org/wiki/Bus_factor https://en.wikipedia.org/wiki/Bus_factor), then that's on them. If no one takes initiative and the company fails to find employees who will, that's also on them. If only one person understands how things work and doesn't document it, nor are there processes in place to ensure any sort of knowledge transfer, then that's also on them. That does sound like a dysfunctional environment and at that point builds will be the least of your worries - figuring out how to get code to prod, how to work with the DB and run tests (if any are present), as well as any other steps that haven't been formalized with an "Infrastructure as Code" approach will cause far worse problems down the road. Good luck if any of your servers ever go down and you haven't used something like Ansible for configuring them, but instead it was done N years ago by someone who's long gone along with their knowledge about how to do that. If you work in such an environment and care about personal success, consider either changing the company or changing companies.

by ajuc 5y ago

KronisLV 5y ago

> And if you always use IDE automation there's no incentive until it's too late. Too late for what, though? At any point in time there's a certain subset of knowledge that's most relevant that you're trying to do. If it's learning overall programming concepts not the internals of a language which you may or may not use, then NOT using the IDE automation would be detrimental. Furthermore, in every single project that i've worked on professionally, attempting to manually manage dependencies and the way things are compiled would earn me odd looks, since that's far more tedious and less productive than just using Maven/Gradle. Not only that, but manually attempting to manage imports as opposed to letting my IDE do everything that's needed in the background would provide me precisely 0 benefit. In my eyes, "It just works", isn't a bad thing at all, as long as you: - can look into the lower level mechanisms (but only once actually needed) - can find information about all of it, to make the above easier Why would you "unlearn" something if you'll still use it in 95% of the cases, the lower level approaches being the outlier?

ajuc 5y ago
> in every single project that i've worked on professionally, attempting to manually manage dependencies and the way things are compiled would earn me odd looks, since that's far more tedious and less productive than just using Maven/Gradle Of course, we're not talking about doing javac manually when you're working, we're talking about learning the basics before going on to use the automation. BTW Maven and Gradle have plenty of gotchas of their own. If you don't understand what exactly happens you won't solve "magical" problems like old builds of non-snapshot versions remaining in the repo for example. > manually attempting to manage imports as opposed to letting my IDE do everything that's needed in the background would provide me precisely 0 benefit. you say that, and just last month I've had to help a guy manually remove an import of Token class from a wrong package that "magically broke his code" :) > Why would you "unlearn" something if you'll still use it in 95% of the cases, the lower level approaches being the outlier? Because I've seen a lot of people decide something that always worked is not their responsibility to fix when it doesn't work. That's how you end up with 1 guy in the company that understands the build system :)
- KronisLV 5y ago
  > you say that, and just last month I've had to help a guy manually remove an import of Token class from a wrong package that "magically broke his code" :) Hmm, the IDE should offer you multiple classes to import from in a dropdown if there's any ambiguity, as well as highlight any of the methods that aren't present or whose signatures differ and provide popups with essentially the same information that you'd get from the compiler, without even having to compile the project. In that regard, i'd say that IDEs are actually superior. A single ctrl+click that'd take you to the source of the class that you've imported should also clear up any confusion about the import. Importing the wrong thing and not bothering to figure out why their code doesn't work honestly feels like not being familiar with the language itself (as opposed to the tooling) and for some reason not trying to figure it out on their own by reading what the IDE is telling them - to me, that does sound more like learnt helplessness than anything else, which would also manifest itself when writing code and running into design patterns that they don't understand, as well as any number of other situations. > Because I've seen a lot of people decide something that always worked is not their responsibility to fix when it doesn't work. That's how you end up with 1 guy in the company that understands the build system :) To me, this also feels like more of an organizational issue: if companies don't have a RACI matrix (https://en.wikipedia.org/wiki/Responsibility_assignment_matrix https://en.wikipedia.org/wiki/Responsibility_assignment_matr...) and have a low bus factor (https://en.wikipedia.org/wiki/Bus_factor https://en.wikipedia.org/wiki/Bus_factor), then that's on them. If no one takes initiative and the company fails to find employees who will, that's also on them. If only one person understands how things work and doesn't document it, nor are there processes in place to ensure any sort of knowledge transfer, then that's also on them. That does sound like a dysfunctional environment and at that point builds will be the least of your worries - figuring out how to get code to prod, how to work with the DB and run tests (if any are present), as well as any other steps that haven't been formalized with an "Infrastructure as Code" approach will cause far worse problems down the road. Good luck if any of your servers ever go down and you haven't used something like Ansible for configuring them, but instead it was done N years ago by someone who's long gone along with their knowledge about how to do that. If you work in such an environment and care about personal success, consider either changing the company or changing companies.