Automated tools get in my way of thinking. I turn off intellisense, auto-formatters, etc...

I'll run auto tools during check-in, but not during coding sessions.

> I turn off intellisense

Unless you are doing this for performance reasons, this one I'll never understand.

I'd much rather type "x.someP" and hit tab then type in "x.somePropertyThatHasARidiculousNameIAlwaysForget" after having to consult the documentation yet again to get the name.

I already know what I want to type. Having something pop up with "suggestions", often obscuring the lines I need to read, is worthless to me at best and disruptive of my thinking at worst.

If I can't recall "x.somePropertyThatHasARidiculousNameIAlwaysForget" then there are other more serious problems.

> If I can't recall "x.somePropertyThatHasARidiculousNameIAlwaysForget" then there are other more serious problems.

I just prefer to press less keys. It shouldn't obscure anything in a decent IDE.

Often you are working with other people's code and having to "recall" every single property, method, etc declared is not practical, hence why I mentioned having to keep referring to the documentation for things you are not accessing very often.

If I keep forgetting that a property is .lastname and not .lastName in a library I'm using I can just type "last" and press tab.

This is even more crucial in dynamic languages like JS, where you will get a failure at runtime and not compile time.

It doesn't make you any "less of a programmer", it makes you a more efficient one once you are used to it.

If you have properties with ridiculous names, that's a bigger problem.

Autocomplete in code seems to mostly be papering over design smells that should be fixed.

> If you have properties with ridiculous names, that's a bigger problem.

I have no control over third-party dependencies and how they name things.

I tend to solve that by wrapping inane APIs. At most I deal with ridiculous names and other API-brokenness once.

> I tend to solve that by wrapping inane APIs.

That is just another layer of abstraction which leads to even more confusion.

These abstractions can be taken to the extreme in things like Java, that's how you end up with a class named "InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState".

If you wrap that in a new interface "IFIFTPIFTPMBWNFS" or even "crazyFrameStuff" (ridiculous enough), now you have to figure out what that actually is while debugging.

If one just comes to terms with the fact that Intellisense (and showing the method signatures while implementing) is extremely helpful even to very senior developers, life can be much easier.

It's not cheating.

No, I end up with classes like that because when I wrap APIs the point is to simplify, so I simplify. Though that is a last effort if ditching the broken API entirely isn't an option - e.g. if it's a third party API we can't avoid. That is rare to begin with.

You're free to find Intellisense etc. useful. I just don't. I go to great lengths to have an uncluttered view of the code when I work, because I find it far more preferable to focus on just the code. I'm not against it in principle - I've just not seen any solutions like that which works for me. I don't tend to need to look up methods much; when I work on a piece of code I tend to hold the APIs in memory pretty effortlessly, so that's just not much of a consideration.

I spent years actually looking at implementing visual languages because I liked the idea of providing more contextual information and views of information flows etc. to aid development, but I've yet to find something that works better for me than an uncluttered view of the text.

No find and replace, either? ;)

I use those. But how would those be automated exactly? How would they know what I want to find and replace?

By understanding the language, so it can do magic things like "rename this field (including uses of it)" without changing other uses of the same string. As a separate operation from general find and replace, of course.

You tell it what you want to find and replace with and then it automates the rest.

My point being that where you draw the line between what you consider automated vs not is pretty arbitrary.

All usable editors also infer the indent levels of brace-less languages. Sometimes you have to change that using a <tab> or <shift>-<tab>, but sometimes I have to write braces in languages with braces too.