Have you asked the original author?

I haven't asked, as I was unsure if it would come across badly. The company culture is very open and friendly, casual and relaxed for the most part.

Be careful that you don't send a message of "I don't have anything better to do with my time, so I'm going to edit the spelling and grammar of random documents."

For the code, learn how versioning works at your company. In other words, don't be like a manager I know who supposedly corrected a typo in a string, but who somehow broke the signed production android apk that was uploaded to the Google Play store (that had gone through the testing phase already). In other words, if you correct something, make sure that it still runs and still passes all the tests. If you're not sure on how to do that yet, just make sure that your correction appears only into the code for the next version of the application, so that it can still be properly vetted and tested.

@JoeStrazzere - That was a concern of mine as well. Though I don't spend time hunting for problems, I was worried it could come across that way. To clarify though, I would only edit documents that I actively work with and use in this manner.

@StephanBranczyk - I know not to interfere with actual code, strings, etc. I meant strictly cosmetic text output, such as the result of log.debug, println, or a comment that explains what a method is meant to do.

I doubt this can really be answered because each company will have its own policies. Code refactoring is often done methodically or not at all. You wouldn't just fix the few typos you happened to spot and check in a new version to your VC. Even for documentation you might give later readers the impression that a document is up to date with the latest version when it hasn't been properly reviewed in years. The only thing you can or should do is ask your team or manager what they do currently and if what you suggest is a good idea and a productive use of your time.

@Lilienthal, "Code refactoring is often done methodically or not at all." Fixing typos is not code refactoring, not at all. In any case, it sounds like your own company is still using the waterfall development model. The waterfall methodology still makes sense in some industries, but it is definitely not universal in all industries anymore.

@Donglecow, Yes, even in the scenario you're describing. Make sure that you test your changes (or that your changes are in the next version, not the current one), even it's just a cosmetic change in a log.debug or in a println statement. Because as the most junior employee, if you break something in production even only once, no one will trust you to change anything by yourself for quite a while after that.

Your question itself has grammatical errors, such as the sentence starting with "in other instances". Before you go correcting others' stuff... hmm.

@XavierJ: couldn't disagree more. Leaving in errors because you've made errors yourself leads to a universally high error rate. Fixing each other's errors, even though none of us individually is perfect, might still result in a high error rate but at least it's lower than before! Each workplace needs to find a way to make it clear that just because someone improves something you did, doesn't mean you should react as though they're claiming they're somehow better than you.

Just bear in mind that if you have enough time on your hands to do this sort of clerical work thoroughly and accurately, your management might decide that the project is overstaffed and get rid of you! (And if you don't do them thoroughly and accurately, you may be just "poking a stick into an ant nest" but not really "adding any value to the project" - and the only result will be to annoy the rest of the team!)

@Lilienthal "You wouldn't just fix the few typos you happened to spot and check in a new version to your VC." Literally every company I have worked at does this. If you spot a typo, fix it. It's the programming equivalent of dusting off your dresser when you notice it's dusty during the act of putting your clothes away. It's just keeping things tidy.

@2rs2ts And at literally every client I've worked for you'd get sent home over it. If you're maintaining the Wild West that is an internal codebase perhaps this would be fine but if you're dealing with production-critical systems, release management and user acceptance testing you never make idle changes that no one asked because you're "dusting the code off".

@StephanBranczyk That depends on your definition, though I agree that code refactoring should be much more than that. But I'd rather not get into a pissing match over who's working on the best and most innovative code, how waterfall is dead and how Emperor Scrum reigns supreme. My main point, which is that every company or team will want to handle this differently, has I think been sufficiently proven true based on the comments here.

@2rs2ts: Besides which, if you just fix it then you miss the opportunity to put the client over a barrel because they forgot to include "user-visible text must be spelled correctly" in the contract. You can drag your feet until they pay your late-change fee, or you can fix it in a couple of minutes including code review. Easy choice. Whereas in the Wild West of an internal codebase, the goal is for the code to be correct, because the interests of the user and the developer are pretty well aligned. I wish I was entirely joking.

Perhaps I'm naive but I think it's more important to deliver quality than to shake your clients down for extra money because you don't bother to proofread. I understand change and release management can be arduous in some workplaces, but I don't think it is responsible to say "You wouldn't just fix the few typos you happened to spot and check in a new version to your VC" when there are actually many instances in which you would. It's your call whether you would rather avoid some inconvenience and accept mediocrity I guess...

I would never, ever, ever push a code revision of any kind unless I had a proper business reason to be altering that code. I would feel comfortable fixing comments and typos in the neighborhood I'm working on. The problem is, with any edit, there's always the possibility of inadvertently breaking something. And then you are into a debug cycle for something that was totally unnecessary.

I worked on a project where log message had a typo in it, but this exact wording (with a typo) was used to trigger another process. If you fixed the typo, trigger would fail (unless you looked for same typo and fixed it too. Fixing that typo would break the code.

@2rs2ts I agree - I think it's a sad state of affairs when simple refactoring is inhibited by downstream gates and we accept that that is a normal and healthy process. I think there is a BIG culture divide in this conversation. The grass really is greener.