So working backwards: Good code is documentation. There's high level overviews of 'this is the intent of this vast construct that is our program and what we want it to do and where we want it to fit in' which can be separate, but for the daily work intent should be clear simply based on patterns and idioms. For example, if you see code like:
int n;
api::Foo( nullptr, n );
char* data = new char[n];
api::Foo( data, n );
You can tell what that code is doing as well as knowing that api makes use of the pattern in which you call twice, get a size the first time, then fill a buffer with that size the second time. If it was your company's api, you should also know to use that pattern if it becomes relevant for your work. Name the api and function appropriately (FileSystem::Read? NetworkLayer::ReadPacket? GPUContext::CopyBuffer?) and you know exactly what it does and who owns what at the end of it. Basically all code you will ever write in a job setting is banal stuff doing mundane things a slight permutation away from how a million other programmers did them over the years. Leave documentation for the bits that are non-trivial or non-obvious; like the weird looking workaround you did to work around a unicode bug when you did NetworkLayer::ReadPacket( data, n/2 ) on a string of Japenese characters that one time. If a system is complicated enough to need documentation, it's also complicated enough to produce so much documentation that left unchecked, no one will bother to read the documentation.
I mean, if you use proper asserts, you can make template metaprogramming compilation errors work just fine. That's what Eigen does.
Again, it's not that you *can't* use them, it's that you've got an added layer of friction to doing so.
Is it feasible to be a "real programmer" (ie have a paid position at a company of some kind, writing some kind of code) if you hate C/++?
There is no way around it. I've tried using C with different IDEs, tools and aids (including none of those at all) for tasks of varying difficulty. It is still far and away the most tedious and annoying language I've ever attempted to learn. There is so much time spent on header files and templates and forward declarations and why compilers don't like certain situations and it's all just so fucking tedious. Writing C gives me the same feeling as doing my taxes. It feels like a meta representation of the paperwork and meetings and email chains that programmers at "real jobs" complain about, built right into the very work itself.
Depends on what type of application you want to write, but in general, yes. C/C++ are awful in those regards largely because of age. Header files are kind of an abomination tbh, and mostly come down to 'we do this so the compiler doesn't have to.' Without a complete survey of today's trendy languages, I would say it's probably safe to say most of them don't get bogged down in those things. Whether you find that's a good thing or not depends on how recently you've wrestled with a misbehaving package manager.
C++ is and will always be the go to language for 'does everything passably' and so will always be in demand, but for most specialties that are focusing on one particular aspect, other languages and tools are used because lower level code is a distraction. Things like neural network machine learning, for example, have tools that at the heart are compiled C/C++, but which are so standardized that nobody cares to rewrite that basic stuff. The field is concerned more about neural network operators and chaining together various inputs and outputs such that actual work and innovation occurs primarily in higher level languages like Python/Lua through use of frameworks like Tensorflow, Theano, Torch, etc. Nobody there cares about allocating and freeing memory and who owns what pointers; with faster iteration times, they could be getting a 100x speedup by tweaking their algorithm instead of 50% speedups from optimizing their memory use slightly better than a pre-built solution. There are also domain-specific languages, with R being a notable one among statisticians. And that's not even getting into the trendy language-of-the-month used for Silicon Valley apps or the massive regions of web coding.
Come back a year later, or have a junior developer take over an unfamiliar subsystem? Now you don't even need documentation; the IDE practically instructs the programmer on what is relevant, what isn't, and what they should read code for before continuing.
This makes me believe you have never actually been the one to come back to code "a year later".
I would also say: If you have to rely on an IDE to understand code, the code could be improved*.
I would couple that with: code (especially without documentation) can only tell you what the code does, not what the code is supposed to do.
*This is not to knock the utility of things like Intellisense - it does indeed make writing code easier. But if you can't find where something is declared easily without search and autocomplete, or you have to rely on it to know what members are in your struct/class, that code is getting unwieldy and is probably subject to worse issues than compiler errors or warnings. There is after all the old (?) adage: "Yay my code compiles! Now let's find out what the real bugs are..."
Programmers take the path of least resistance. Intent not imparted through code is mostly intent wasted. Basically nobody reads documentation unless they're already facing a bug or something is really ambiguous. Between function, argument, and variable names, I would contend that things just plain shouldn't be that ambiguous. On the rare case they are, that's what comments are for. Beyond that, there's the occasional idioms that need explaining, but those are just as often done better in person, as they tend to weave together high level vision and low level reality in a way that isn't easily conveyed through documentation. Some things just need tutorializing; but those tend to be in the 'what is possible' space more than anything tied to code.
Sure, you can do find in files; that's the entire reason I have notepad++ on my work machine (a tangent I will get back to, as it's notable in its own right). But in combination with even trivial polymorphism and C++'s love of header and cpp file separation, now you're searching through several files for an implementation, following a chain of dependencies attempting to find the source. If that was what developing with object oriented approaches meant, it would be seen/derided as an obscure hobby like pure functional programming often is. This is where the tools come in.
Intellisense (of which the autocomplete you mentioned is a part) gives you a list of functions, shows you the comments around them, can link you to their implementations for further detail, and can help discover things in large interfaces. It serves a similar role to NEI mods in minecraft -- I may not know how to transfer this RF power, but I know if I type in 'cable,' 'conduit,' or 'duct,' I will probably find something to do what I want so long as I have a general sense of what is possible, what I want to do, and commonly used terms to do them. It, and solutions like it are probably as big a part of OO's success out in the world as anything else.
(As for the tangent: Intellisense *doesn't* always just work. Sometimes, often with special project setups or very large projects, these tools fail. Intellisense is notoriously crashy and locks up Visual Studio on things the size of a game engine. Sometimes, they just aren't pointed at the right place and fail entirely or in part for certain libraries. Failures of these tools adds a lot of friction to things like OO code -- which results in less OO code being written in those spaces.)