IDE 会使你变笨吗？_AI阅读总结 — 包阅AI

I like my integrated development environment (IDE). I like it when it points out my syntax errors. I like all the different font colorings that show me all sorts of things about my code and how it works. I like it when I can view the members and methods of a class variable by doing nothing more than clicking a mouse. I like IntelliSense and code complete. Frankly, I’d be lost without them.

But there are times when the IDE does things for me, and I have no idea how it’s doing them.

As embarrassing as it is for me to say, the only way I know how to debug code is to use an IDE. How does it happen? You’ve got me. Could I figure out how it all works? Most likely. But, most times, I let the IDE lead and I follow — sometimes out of habit, other times just to get the code out the door.

As a result, there are some days when I fear that I will only be as good a programmer as the IDE will allow, or that the IDE has made me stupid. Maybe it has; perhaps it hasn’t. It all depends on two factors: cognitive ergonomics and corporate needs.

Allow me to elaborate.

What Is Cognitive Ergonomics?

Cognitive ergonomics is the branch of science that explores how work is done in the mind. Its goal is to optimize human thinking and mental performance.

Not all labor-saving technologies are cognitively ergonomic. There are technologies that actually impede human cognition. The modern cash register is one such example.

In the old days, using a cash register involved entering the price of the sale into the machine, taking the customer’s money, putting it in the drawer and then returning the correct change to the customer. It was the cashier’s responsibility to determine the correct change. In order to perform that task, the cashier needed to know how to calculate the difference between the cash received and the cost of the sale.

Then, as the technology matured, the newer versions of the cash register calculated change. All the cashier needed to do was enter the price of each item into the machine, along with the amount of cash the customer provided as payment. The cash register calculated the total amount of the sale and the change to return to the customer. The machine did all the “thinking” work. Within a generation, cashiers lost the ability to make change.

A grammar checker is not making me stupid. I am not losing my ability to write using good grammar. Quite the opposite: My ability to write has improved. The grammar check is making me smarter. Can the same thing be said about IDE technology?

The result is that while cash register technology has improved productivity, it has impeded human cognitive ability. The cash register made the human operator stupid. The business benefited, no doubt. But the operator? Not so much. If anything, the increasingly mindless automation escalated the drudgery of the job.

Still, there are technologies out there that improve cognitive ergonomics — spellcheck, for example. I’ve been using a spellchecker for years. If anything, this technology has made me a better speller. After a few episodes of spellcheck correcting me, my spelling improves. The spellchecker is actually teaching me how to spell correctly.

Grammar checkers also improve cognitive ergonomics, but with an important consideration. While I assume that the spellchecker will always provide correct spelling, using a grammar checker involves a bit of negotiation between me and the tool, and often requires more analysis on my part. The grammar checker’s suggestions are sometimes appropriate to my writing style, other times not. It’s my analysis that decides whether to use the tool’s suggestion.

The grammar checker improves cognitive ergonomics by forcing me to exercise my analytical abilities in a passive-yet-directed manner. The tool is not making me stupid. I’m not losing my ability to write using good grammar. Quite the opposite: My ability to write improves. The grammar check is making me smarter. Can the same thing be said about IDE technology?

The Ergonomics of the IDE

Dominik Tornow, founder and CEO of Resonate HQ, has an interesting take on IDEs. “If you use an IDE to improve the ergonomics of your toolchain, an IDE will elevate your abilities,” Tornow told The New Stack in an email. “If you use an IDE to hide the mechanics of your toolchain, an IDE will dull or degrade your competence.”

For Tornow, it’s about intention. An IDE can be an indispensable tool when used to help a developer think better. But when it’s used as a means of automation while removing the developer’s need to understand the underlying tasks of modern computer programming, an IDE can be a detriment.

No doubt, an IDE provides a benefit by automating programming tasks that are tedious and repetitive, or even those tasks that require the programmer to do a lot of typing. Still, those commands are there for a reason, and a developer would do well to understand the details of what they’re about and why they need to be done.

As anybody who has been in IT for a while can attest, locking up the details of a deployment process to satisfy a particular tool —in this case, an IDE — is risky, particularly when the deployment process is using the IDE to execute a task that could just as easily be done at the command line.

The “hiding the math” aspect of using an IDE might not matter to senior developers who have the experience and insight to understand the hidden details that an IDE has automated. However, for an entry-level developer, using an IDE without understanding what it’s doing behind the scenes can limit the developer’s ability to do the type of more advanced work that’s needed to progress in their career. Knowing the details is important.

Visual Studio “makes me a better programmer,” Carl Franklin, CEO of App vNext and a longtime fixture in the .NET community, told The New Stack in an email. “By removing tedious tasks, automatically changing names of variables and classes across the entire project, making it easy to use git, using Copilot to help with boilerplate code. That’s just the tip of the iceberg. These things and others let me focus on the code and the architecture.

“But, for the most part, I do know what’s going on under the covers.”

It’s the difference between an automated cash register and a grammar checker. A computerized cash register degrades your ability to think. A grammar checker, appropriately used, improves your thinking. In the final analysis, it’s your ability to analyze and act that counts.

An IDE can improve cognitive ergonomics, but you must want it to. Passive interaction with the tool will get you only so far. At some point, you need to know what’s going on underneath the hood.

But, there is still a danger at hand, particularly when a company mandates that all developers use the same IDE in the same way. Then, the IDE does not simply become a tool that’s used to improve developer productivity — it can also become a way of life. Once an IDE becomes a way of life in an IT department, the corporation runs the risk incurred by IDE lock-in.

The Danger of IDE Lock-In

No two IDEs work the same way. Not only are the GUIs different, but the way projects are configured and managed is different too. And, the underlying features and tools will vary according to each IDE.

This is not a big deal if a company stays committed to a particular IDE forever, or if automated deployment processes are agnostic in terms of the IDEs they support. But, for the most part, that’s not the case — quite the opposite, actually. Companies do not stay committed to the same IDE forever, nor are their deployment processes agnostic when it comes to IDEs.

Jeremy Hsu, chief architect at the development company mimik, pointed out the problem clearly. “Many IDEs use proprietary configurations or project files to manage builds,” he told The New Stack in an email. For example, Eclipse uses .project and .classpath files, which are not inherently understood by external tools without plug-ins or additional processing.

Relying on IDE-specific build processes can lead to maintenance challenges as a project scales or as team size increases, since each new environment, such as a different developer’s machine, might require individual setup and configuration. This can lead to increasing complexity and potential for errors.

This problem isn’t exactly an example of corporate dumbness. Rather, it’s a result of making the IDE an inflexible way of corporate life. To build on a quote from Shakespeare:

“The fault, dear CEO, is not in our stars,

But in our IDE, that we are underlings to its whims.”

As anybody who has been in IT for a while can attest, locking up the details of a deployment process to satisfy a particular tool —in this case, an IDE — is risky, particularly when the deployment process is using the IDE to execute a task that could just as easily be done at the command line.

When an IDE becomes a critical part of the deployment process, companies become married to the tool and its way of working. If the tool promotes a certain degree of stupidity, then, by extension, the company becomes a bit more stupid too. It can and does happen. Still, IDE lock-in is a small problem compared to a much larger one: the corporate need for speed.

The Corporate Need for Speed

Using an IDE to enable developers to code quickly while also allowing them to improve their cognitive abilities is feasible for devs working in small shops. Those devs tend to have a lot of autonomy over how they work.

For example, going back to my reliance upon the IDE to debug code, as I described earlier: If I really wanted to learn how to debug code without using the IDE, I have the luxury of taking the time to figure it out. I am an independent contractor, so I just won’t bill the client for my research time.

The client doesn’t need me to know this level of detail about debugging code to get the job done. I get that. I’m the one who wants to know – at the very least, just to assuage my sense of professional curiosity.

I’m fortunate to have that luxury. However, such luxury is rare at the corporate level.

In a larger enterprise, IT departments want two things: code that works according to expectations and code that’s delivered fast. Every trip back to the fix-it shed costs money and time.

“The choice between using an IDE or not often feels like a religious decision these days, with some vehemently favoring one over the other. However, I believe in a hybrid approach to .NET development. Programmers can opt for manual coding, use an IDE, or leverage both methods.”

—David McCarter, founder, dotNetTips.com

One way that companies mitigate the quality and time-to-market risks implicit in software development projects is to mandate that developers use an IDE. Sometimes, a company will even go as far as mandating that a developer use a particular IDE that’s been configured to enforce a company’s coding standards — everything from variable naming to code formatting to code coverage minimums for unit tests.

Understandably, companies like the predictability and easier maintenance that uniform code provides. They also like the efficiency of using an IDE. These tools do indeed get code out the door faster, but at what cost to the developer, and at what eventual cost to the business itself?

IDEs can be a real boon to both businesses and developers, particularly when a developer is given the option of which IDE to use and how to use it. David McCarter, founder of the developer blog dotNetTips.com and a Microsoft developer technologies MVP, advocates a hybrid approach.

“The choice between using an IDE or not often feels like a religious decision these days, with some vehemently favoring one over the other,” McCarter told The New Stack in an email. “However, I believe in a hybrid approach to .NET development. Programmers can opt for manual coding, use an IDE, or leverage both methods.

“Considering the intricacies of software engineering, utilizing the IDE for efficiency in application development is paramount. However, it’s essential for engineers to familiarize themselves with CLI commands for scenarios where IDE functionality falls short.”

Machine Smart, Human Smarter

When an IDE helps a developer think better and work faster, that’s better for the developer, their team and their organization.

But, when a company uses an IDE in a way that turns developers into deadline-driven coding machines, akin to a cashier mindlessly operating an automated cash register, that company’s executives might wake up one day to discover that they’ve created an IT department that is staffed with a legion of corporate lemmings — fluent in fiddling with an IDE to get the code out the door, yet unable to think on their own to solve the really hard problems that might come up.

A company will get its code today, but who will make the new, better system tomorrow once a developer’s ability to analogically “make change for a customer” has been stripped away? The IDE? I don’t think so.

Maybe the creative work will be done by an AI-powered IDE that requires minimal human interaction. It’s a real possibility when getting code out the door faster than the competition and achieving market dominance are key factors for a corporation’s success. In the race between humans and machines, the machine is always faster, but not necessarily smarter.

After all, it wasn’t the fast developers who changed the world — it was the smart ones.