[lmilcin]

> This is an argument against programming by autocomplete, not an argument against programming with IDEs.

Exactly. IDEs fulfil an important function of removing repetitive and mundane tasks. The goal is to be you, the programmer, to know what you want to do and the tool, IDE, to make it happen as efficiently as possible.

That can happen through parsing code, showing documentation, showing references, alerting to obvious bugs, etc. But it can also be fulfilled by generating code (esp. in environments that like boilerplate) and possibly also by finding pieces of code to achieve the operation you need.

Sure, by using autocomplete constantly I may impair my memory same way that using Google Maps impairs my ability to drive without navigation. So what? I care that the task is completed and my mind is available to thinking about higher level problems rather than how to exactly search the code for references or locate the documentation.

Isn't the goal of software development actually building something rather than obsessing about the process?

[lanstin]

There is an arrgument that the details matter a lot in code.

i mostly am familiar with network side of things, but little stuff like how you handle connection timeouts or retries, for example, make a really big difference to the overall quality of the system. Not thinking about a network call each time is setting up a system that will randomly fail in avoidable ways (excessive retries keeping a system from recoverying; excessive buffering in the face of latency; unbounded memory queues causing failure propagatin; having best effort code handle connect failure quickly but not have good rear time outs, etc)

The higher level problems often emerge from the exact nature of the lower levels.

[lmilcin]

> There is an arrgument that the details matter a lot in code.

The details of resulting code. Not the details of how exactly you wrote it.