― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
https://www.goodreads.com/quotes/835238-indeed-the-ratio-of-...
Even within the same organization - a raise would typically entail that you take on new or more responsibilities.
“Read, read, read. Read everything -- trash, classics, good and bad, and see how they do it. Just like a carpenter who works as an apprentice and studies the master. Read! You'll absorb it. Then write. If it's good, you'll find out. If it's not, throw it out of the window.”
That a person functioning as a software engineer expects:
a) Not to need to read or understand other persons code
b) Not to need to learn how new codebases work
Sounds completely unprofessional and misguided based on my experience.
I get the point about everything being 100% new at a new job being more uncomfortable than the incremental newness you should constantly be experiencing. But still - if you do have a hard time justifying a raise, remember that you're asking the company to bet more money on your. Bet on yourself first, step outside your comfort zone a little, and try lead in a way you haven't much before.
But the fact is that it's just much much easier to convert ideas to code than code to ideas. It's also much easier to convert ideas to English than English to ideas, so better documentation probably helps, but it still sucks. (E.g. consider reading any sizable IEEE standard. It's all there, carefully described, but it's still a lot of work to understand.)
So yeah, many people prefer writing code to reading code, me including.
And BTW this is one thing that my university didn't quite get right. They focused a whole lot on writing code, but not as much on reading. The latter of course proved to be much much more important in my daily job.
/diversion