5 ms·

I think we already saw this manifestation a few decades ago, with kids who can't program without an IDE. IDE's are fantastic tools - don't get me wrong - but i

by aa-jv 2y ago

I think we already saw this manifestation a few decades ago, with kids who can't program without an IDE. IDE's are fantastic tools - don't get me wrong - but if you can't navigate a file system, work to understand the harness involved in your build system, or discern the nature of your artefacts and how they are loaded and interact in your target system, you're not doing yourself any favours by having the IDE do all that work for you. And now what we see is people who not only can't program without an IDE, but can't be productive without a plugin in that IDE, doing all the grep'ing and grok'ing for them. There has been a concerted effort to make computers stupider for stupid users - this has had a chilling effect in the development world, as well. Folks, if you can't navigate a filesystem with confidence and discern the contents therein, you shouldn't be touching the IDE until you can.

kasey_junk 2y ago
I worked early in my career with a developer who printed out every part of the codebase to review and learn it. He viewed text search tools, file delineations, and folder structures as crutches best avoided.
- aa-jv 2y ago
  Yes indeed, that is a perfectly reasonable approach to take, especially in the world of computing where rigorous attention to detail is often rewarded with extraordinary results. I have very early (and somewhat fond) memories of reviewing every single index card, every single hole in the punch-tape, every single mnemonic, to ensure there were no undiscovered side-effects. However, there is a point where the directory structure is your friend, you have to trust your colleagues ability to understand the intent behind the structure, and you can leverage the structure to gain great results. Always remember: software is a social construct, and is of no value until it is in the hands of someone else - who may, or may not, respect the value of understanding it...
silver_silver 2y ago
I have (older, but that generation) colleagues who simply stop working if there’s something wrong with the build process because they don’t understand it and can’t be bothered to learn. To be fair to them, the systems in question are massively over complicated and the project definitions themselves are the result of copy-paste engineering. Unfortunately they also project their ignorance, so there’s massive pushback from more senior employees when anyone who does understand tries to untangle the mess and make it more robust. The same thing will happen with these ML tools in the future, mark my words: writing code will come to be seen as “too complex and error prone” and barely working, massively inefficient and fragile generated code bases will be revered and protected with “don’t fix what isn’t broken”

by aa-jv 2y ago

kasey_junk 2y ago

I worked early in my career with a developer who printed out every part of the codebase to review and learn it. He viewed text search tools, file delineations, and folder structures as crutches best avoided.

aa-jv 2y ago
Yes indeed, that is a perfectly reasonable approach to take, especially in the world of computing where rigorous attention to detail is often rewarded with extraordinary results. I have very early (and somewhat fond) memories of reviewing every single index card, every single hole in the punch-tape, every single mnemonic, to ensure there were no undiscovered side-effects. However, there is a point where the directory structure is your friend, you have to trust your colleagues ability to understand the intent behind the structure, and you can leverage the structure to gain great results. Always remember: software is a social construct, and is of no value until it is in the hands of someone else - who may, or may not, respect the value of understanding it...

silver_silver 2y ago

I have (older, but that generation) colleagues who simply stop working if there’s something wrong with the build process because they don’t understand it and can’t be bothered to learn. To be fair to them, the systems in question are massively over complicated and the project definitions themselves are the result of copy-paste engineering. Unfortunately they also project their ignorance, so there’s massive pushback from more senior employees when anyone who does understand tries to untangle the mess and make it more robust. The same thing will happen with these ML tools in the future, mark my words: writing code will come to be seen as “too complex and error prone” and barely working, massively inefficient and fragile generated code bases will be revered and protected with “don’t fix what isn’t broken”