The author makes some good points about project organization and general attention to detail. I've used IDEs for over 20 years. Even when I used emacs for C++ a

The author makes some good points about project organization and general attention to detail. I've used IDEs for over 20 years. Even when I used emacs for C++ and scripting languages, back in the day there weren't worthwhile IDEs for them on the platform I used, I looked forward to the day when there would be. I'm an IDE believer. However, I'm a stickler for organization, naming consistency, and general tidiness in codebases, because I think it affects onboarding speed and mental overhead for programmers, and I often rub up against programmers who don't notice shortcomings in these areas, because they rely on their IDE features to avoid spending any thought on code organization. They don't care if a method is badly named or misspelled because they barely read names before they ctrl-click them. They don't care that files are haphazardly organized because they navigate by searching. They pick up a ticket and slack somebody to ask where the fix should go. Once they're in the right place, it's click click click and they're on their way. The best programmers read class names and method names. They look at the directory structure to get a sense for how the codebase is organized. They try to understand the logic behind code they inherit, they try to write code with an evident logic that the next person can follow, through good organization and meaningful, consistent naming. I've had programmers tell me that they didn't know a word was misspelled because they figured it was a word they didn't know. I told them if they see a word in our codebase they don't know, they shouldn't gloss over it, they should look it up, because somebody thought about that word before they typed it. They roll their eyes. They think everyone is like them and craps out names without thinking about them. They don't realize this has anything to do with why they're still mid-level at their age and people don't trust them with anything important. In the end, I don't think the author is correct. I don't think that using a poor tool makes a programmer better, even if it forces them to do important things they wouldn't otherwise, like notice how things are named and organized. And I think the best programmers are better and faster with an IDE. But I certainly understand where he is coming from.