Good coders can work effectively without the fancy IDE tools (autocomplete, inline code linting, button-based debuggers.
I have to take issue with that, because I'd consider any team member that write their (Java) code in a plain text editor to be a time waster. That does include them not leveraging an IDE for code writing, but more than that it includes the whole team's time when the bugs start rolling after a manual refactor.
I agree with both of you. I think there's a certain skill that you build with coding in text editors as well as learn to appreciate IDE's. I think everyone should start out writing code in text editors. However, they must work with IDE's once they familiarize themselves. I don't think that's plausible nowadays because everyone is so much into instant gratification. Although, I might be old-school. :o
And I'd counter that bugs from a manual refactor are largely because they never learned to work without the IDE holding their hand.
Go back in time a couple of decades, and we used to write very clean code. In binary. On punchcards. That worked surprisingly well on relatively few iterations.
Similarly, COBOL, C, and FORTRAN didn't have fancy IDEs back in the day, and yet we have a sizeable production code still running in those languages, some 10-20 years later. (We ran space missions on code written without an IDE, fer cryin' out loud.)
Now, that does not mean we shouldn't be using an IDE in writing mission-critical code, if we have it available to us. It's a superb safety net, and not using it would indeed be a waste of time.
However, my point is that, if a coder is unable to write good code in a plain text editor, that's certainly a skill they need to build (preferably on non-prod code!) If someone can write clean code in an editor, they can write clean*er* code in an IDE.
Conversely, the person who is unable to write clean code in a text editor will have far more bugs, and waste far more time fixing errors, in the IDE.
Put that yet another way, if you're hopelessly lost building a birdhouse with a handsaw and a screwdriver, power tools will only help you make a mess quicker.
I do see your point, but I don't consider writing without an IDE to a (useful) skill, anymore that I'd consider writing bytecode a skill (unless you have a very specific use-case that requires it). People were/are indeed able to write bytecode manually, but the expectations with regard to the productivity of an individual person were not then what they are now (that's in fact a reason why we have programming languages, libraries, frameworks, etc).
As to the carpenter analogy, my being able to quickly and accurately saw using an electric saw bench isn't affected at all by my not being able to produce similar quality with a manual handsaw and my leg to prop things up on ;-).
Heavens, if you're using your leg to prop things up on, put down the tools and take up something safe. Like, maybe knitting. ;-)
Joking aside, if one cannot properly use measuring tools and a vice to saw manually, they will also have trouble using a modern electric saw bench. That doesn't nullify the usefulness of the modern electric saw bench, mind you. It's just that the benefit of the manual method is that you really learn how to measure, sight, and position - the same skills you need with the power tools, which aid but don't replace the need for ability - and you can't screw it up quite so quickly. Besides that, there may well come a time that you don't have your fancy laser-sight electric saw bench, but you have a vice and band saw. What do you do then?
The IDE issue isn't even remotely dissimilar. If you just become reliant on always autocompleting, and using lint warnings in place of your own good eyes and brains, you are now totally reliant on the machine to do the thinking. You get to the point that you don't know why half the syntax is there, which makes logic checking and debugging that much harder. If you don't know your own code, how is anyone else going to fare?
IDEs are useful for inserting what you already know should be there, but too often, coders use them to insert what the IDE thinks should be there, without actually knowing it belongs. You can always spot an IDE-reliant coder because, if you ask them to write something simple in a text editor in that language, they freeze. They can't even remember how the main function is supposed to be structured! It's a dangerous and shameful position for any programmer to be in, to not know the what and why of their own code. They're the ones who write the most and nastiest bugs.
Secondly, you may not always have your IDE handy when you are called upon to fix an urgent issue. Imagine your build has fundamentally broken, and the chain of responsibility means that you need to do something about it right now. You don't have the luxury of installing IntelliJ IDEA on your Uncle Steve's desktop; you need to bring up a private browsing tab (so your creds don't get stored), log into GitHub, and fix the fundamentally broken function that somehow got pushed to live prod. (Yes, this is a rare situation, but I've had this happen to me two or three times in my career). If you're IDE-reliant, you're entirely useless in this case. But if you know how to write the code without the IDE, you are capable of editing straight in GitHub, fixing the problem in less than ten minutes in one shot, and mitigating major disaster or inconvenience.
It's really easy to say "working with the manual tools isn't useful anymore," but as someone who has trained interns for almost eight years, I can assure you that it makes a profound difference, even with the odd case above aside:
The coders who can work without an IDE can solve a problem with an IDE in easily half the time as one who is IDE-reliant. You're welcome to test this out (controlling for such factors as raw language familiarity and IDE familiarity). I know it's been proven time and again with my team.
The coders who can work without an IDE write cleaner code in general, and their IDE-written code is still cleaner than that of their IDE-reliant peers.
Like I said, my first iteration is always fairly clean, and my second iteration nearly always runs as expected (barring exceptionally complicated algorithms). That's true without an IDE, having summarily and deliberately ignored autocomplete and Intellisense for nearly a decade in any language I was learning. Now that I (equally deliberately) use Intellisense in C++ and Python, I can clatter out a fairly complex, clean class faster than many coders I know, and the linters seldom find anything to whine about with it.
So, while one may not need to work without an IDE in production code very often, if ever, in real life, the skills gained from the ability make one's use of the IDE far more effective.
By the way, the expectations as to productivity "back in the day" were a lot stricter than now. One of my devs and best friends was a gentleman who worked in COBOL, FORTRAN, and bytecode on embedded systems for the US Army. (This guy actually met Rear Admiral Grace Hopper once, around that time, for context.) If we had to do half of what he and his crew did in one week at our jobs, we'd probably lose our minds.
I do agree that there would be some generic benefit (i.e. all other things being equal), just not that it'll make an actual difference in how productive or reliable someone is at their job (and I've had enough encounters where considerable time and effort was wasted because someone thought they were so awesome that they coded better without an IDE).
So though I really enjoy the discussion, I think we'll have to agree to disagree on this one :).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have to take issue with that, because I'd consider any team member that write their (Java) code in a plain text editor to be a time waster. That does include them not leveraging an IDE for code writing, but more than that it includes the whole team's time when the bugs start rolling after a manual refactor.
(Only with that though, the rest is spot-on 😁 )
I agree with both of you. I think there's a certain skill that you build with coding in text editors as well as learn to appreciate IDE's. I think everyone should start out writing code in text editors. However, they must work with IDE's once they familiarize themselves. I don't think that's plausible nowadays because everyone is so much into instant gratification. Although, I might be old-school. :o
And I'd counter that bugs from a manual refactor are largely because they never learned to work without the IDE holding their hand.
Go back in time a couple of decades, and we used to write very clean code. In binary. On punchcards. That worked surprisingly well on relatively few iterations.
Similarly, COBOL, C, and FORTRAN didn't have fancy IDEs back in the day, and yet we have a sizeable production code still running in those languages, some 10-20 years later. (We ran space missions on code written without an IDE, fer cryin' out loud.)
Now, that does not mean we shouldn't be using an IDE in writing mission-critical code, if we have it available to us. It's a superb safety net, and not using it would indeed be a waste of time.
However, my point is that, if a coder is unable to write good code in a plain text editor, that's certainly a skill they need to build (preferably on non-prod code!) If someone can write clean code in an editor, they can write clean*er* code in an IDE.
Conversely, the person who is unable to write clean code in a text editor will have far more bugs, and waste far more time fixing errors, in the IDE.
Put that yet another way, if you're hopelessly lost building a birdhouse with a handsaw and a screwdriver, power tools will only help you make a mess quicker.
I do see your point, but I don't consider writing without an IDE to a (useful) skill, anymore that I'd consider writing bytecode a skill (unless you have a very specific use-case that requires it). People were/are indeed able to write bytecode manually, but the expectations with regard to the productivity of an individual person were not then what they are now (that's in fact a reason why we have programming languages, libraries, frameworks, etc).
As to the carpenter analogy, my being able to quickly and accurately saw using an electric saw bench isn't affected at all by my not being able to produce similar quality with a manual handsaw and my leg to prop things up on ;-).
Heavens, if you're using your leg to prop things up on, put down the tools and take up something safe. Like, maybe knitting. ;-)
Joking aside, if one cannot properly use measuring tools and a vice to saw manually, they will also have trouble using a modern electric saw bench. That doesn't nullify the usefulness of the modern electric saw bench, mind you. It's just that the benefit of the manual method is that you really learn how to measure, sight, and position - the same skills you need with the power tools, which aid but don't replace the need for ability - and you can't screw it up quite so quickly. Besides that, there may well come a time that you don't have your fancy laser-sight electric saw bench, but you have a vice and band saw. What do you do then?
The IDE issue isn't even remotely dissimilar. If you just become reliant on always autocompleting, and using lint warnings in place of your own good eyes and brains, you are now totally reliant on the machine to do the thinking. You get to the point that you don't know why half the syntax is there, which makes logic checking and debugging that much harder. If you don't know your own code, how is anyone else going to fare?
IDEs are useful for inserting what you already know should be there, but too often, coders use them to insert what the IDE thinks should be there, without actually knowing it belongs. You can always spot an IDE-reliant coder because, if you ask them to write something simple in a text editor in that language, they freeze. They can't even remember how the main function is supposed to be structured! It's a dangerous and shameful position for any programmer to be in, to not know the what and why of their own code. They're the ones who write the most and nastiest bugs.
Secondly, you may not always have your IDE handy when you are called upon to fix an urgent issue. Imagine your build has fundamentally broken, and the chain of responsibility means that you need to do something about it right now. You don't have the luxury of installing IntelliJ IDEA on your Uncle Steve's desktop; you need to bring up a private browsing tab (so your creds don't get stored), log into GitHub, and fix the fundamentally broken function that somehow got pushed to live prod. (Yes, this is a rare situation, but I've had this happen to me two or three times in my career). If you're IDE-reliant, you're entirely useless in this case. But if you know how to write the code without the IDE, you are capable of editing straight in GitHub, fixing the problem in less than ten minutes in one shot, and mitigating major disaster or inconvenience.
It's really easy to say "working with the manual tools isn't useful anymore," but as someone who has trained interns for almost eight years, I can assure you that it makes a profound difference, even with the odd case above aside:
The coders who can work without an IDE can solve a problem with an IDE in easily half the time as one who is IDE-reliant. You're welcome to test this out (controlling for such factors as raw language familiarity and IDE familiarity). I know it's been proven time and again with my team.
The coders who can work without an IDE write cleaner code in general, and their IDE-written code is still cleaner than that of their IDE-reliant peers.
Like I said, my first iteration is always fairly clean, and my second iteration nearly always runs as expected (barring exceptionally complicated algorithms). That's true without an IDE, having summarily and deliberately ignored autocomplete and Intellisense for nearly a decade in any language I was learning. Now that I (equally deliberately) use Intellisense in C++ and Python, I can clatter out a fairly complex, clean class faster than many coders I know, and the linters seldom find anything to whine about with it.
So, while one may not need to work without an IDE in production code very often, if ever, in real life, the skills gained from the ability make one's use of the IDE far more effective.
By the way, the expectations as to productivity "back in the day" were a lot stricter than now. One of my devs and best friends was a gentleman who worked in COBOL, FORTRAN, and bytecode on embedded systems for the US Army. (This guy actually met Rear Admiral Grace Hopper once, around that time, for context.) If we had to do half of what he and his crew did in one week at our jobs, we'd probably lose our minds.
Irrelevant historical context, my buddy got one of R.A. Grace Hopper's nanoseconds when he met her, too. ;)
FYI, I just turned this convo into an article.
The Curse of the IDE
Jason C. McDonald
That video is bloody AMAZING! Thanks for posting.
I do agree that there would be some generic benefit (i.e. all other things being equal), just not that it'll make an actual difference in how productive or reliable someone is at their job (and I've had enough encounters where considerable time and effort was wasted because someone thought they were so awesome that they coded better without an IDE).
So though I really enjoy the discussion, I think we'll have to agree to disagree on this one :).