Follow Slashdot stories on Twitter


Forgot your password?

Comment As a senior guy... (Score 1) 332 332

I would ask you: do you understand how the code works? Are you adding reasonable features, or fixing user-visible bugs? Are you restricting your changes to items that will achieve the project's goals, and meet the required deadlines?

If you are not doing these things, your changes are doomed to fail. If you are creating huge changesets that require additional review [time which could be spent making meaningful changes] but do not add (or fix) functionality, you are wasting the senior's time. Worse, if your changesets have bugs, you are actively hurting the development effort.

So what do you do? Add comments to help you find your way around; perhaps make suggestions as to how you think the code should go. Focus on how you can make a positive difference, and earn the senior's trust to rewrite the sections that bother you the most.

Change for the sake of change -- or to meet some irrelevant book's standards -- does not make production code work any better. And that's the usual goal. Be very aware of it.

"If a computer can't directly address all the RAM you can use, it's just a toy." -- anonymous comp.sys.amiga posting, non-sequitir