2

I recently joined small software company and have been assigned to project in which one of team member is very senior has been working on the same code base for about 7 years.

Part of my assignment is to maintain this code base. There is not much comments in the code neither any documentation. I am struggling to understand the code and part of the reason asking senior lot of questions regarding various scenario logic of the code. My manager get very angry when I ask code related questions. According to him, I should be capable of understanding the code on my own.

Once I had a chance to implement a new logic. So I did – to take revenge I did not put any comment to the code. Now this senior is struggling to understand my logic. He came and asked me to make him understand the logic. I just smiled and explained.

Question: I am not sure how to approach the legacy code and gain trust. The Manager and this senior are working together for a very long time. It is becoming very difficult to gain his trust.

Edit: I myself have two years of experience from previous job. Where the practice is to have design documents/commenting code.

Edit: Thanks for all the Answers . I accepted the one which has list of points to be followed. The OP has a specific question[not broad] about how to work with angry manager[gain trust] when working with legacy code. The 3rd paragraph of OP is to demonstrate, all fail to understand the logic of the code sometimes.

Improve this question
9
  • 18
    Well, deliberately obfuscating your own code as an act of petty vengeance isn't a great first step. – RJFalconer Oct 22 '18 at 22:41
  • 1
    @RJFalconer That's not what he said. He just omitted comments (which is bad enough on its own) – rath Oct 22 '18 at 22:44
  • 1
    Possible duplicate of How do I establish credibility in a new team? – Jim G. Oct 23 '18 at 12:27
  • 2
    "to take revenge I did not put any comment to the code", well commenting code is generally a bad idea anyway, you should be writing code that is easy to understand without them. If your writing code that nobody can understand then it's no suprise he has no trust in you and starting to do improve your code quality will slowly help. – ayrton clark Oct 23 '18 at 14:07
  • 2
    @ayrtonclark This is correct. You code should be the document. In some cases people update code but not the comment. You shouldn't write clever code or use variables that don't mean anything. You should definitely document functions and parameters, but code documentation in logic, except in rare cases, shouldn't contain comments. I've seen legacy code where old comments are still left in place while the logic long changed. – Dan Oct 23 '18 at 16:49
2

My manager gets very angry when I ask code related questions. According to him, I should be capable of understanding the code on my own.

This is quite an immature attitude, and it's quite a presumptuous assumption even if he is from a technical background. When this happens again, there's a few approaches you can take / points you can make depending on what is true in this code base:

  • the code may have built-up technical debt and is in need of a refactor, impairing readability
  • seek to clarify that you can read the code, but want to understand the part of the business/domain it pertains to
  • lack of tests may mean you are not confident to make changes, or can't use tests to examine code paths through the system

Don't just blame the code for being "bad", even if that's true.

Meanwhile:

  • start small with your changes
  • continue to ask questions when you get stuck
  • endeavour to to write clear, testable code
  • perform minor clean-ups around the code you touch

The results will earn you a good reputation.

As a technical side-note, most code should not have comments; rather it should be self-documenting. It should be clear from names and methods what the intent is, without the need for explanation.

Improve this answer
2
  • 1
    For very simple code perhaps no comments are needed. For complex physics simulations lots of comments and references to the papers various bits are based on is an absolute requirement for the coder to ever understand it in the future (such as next week). – Jon Custer Oct 22 '18 at 23:23
  • 1
    What the manager does is immature, because a good developer can figure out what the code does, but cannot possibly figure out what the code is supposed to do which may be quite different. – gnasher729 Oct 22 '18 at 23:37
9

As a mainframe programmer, I live in legacy code. I have worked in applications older than I am and I can tell you that "taking revenge" only adds to the problem.

Yes you got to smile when your senior came to you, but give it 3 years and you will also have no idea and you wrote it. If you want to gain the trust of your peers, you need to act like your peers. Take the time to walk through the code and figure it out. There is a good chance part of the reason they don't trust you is because you seemingly can't do the work alone AND the code you did write is super confusing.

None of the code I work on had any form of documentation before I started. Now, most of the programs has comments and there is up to date documentation. This did not happen over night. Any time I was working on a piece of code I found confusing, I would go back and make comments once I learned how it worked and slowly reversed engineered some design documents. These documents are not perfect, but they are much better than nothing.

Until you start positively contributing, you will not gain their trust.

Improve this answer
1
  • +1 You must present the ideal you profess, otherwise, you're just another "do what I say, not what I do" programmer. – Edwin Buck Oct 24 '18 at 20:16
4

I've said it many times before, but learning to maintain legacy, undocumented code is a necessary skill to develop in this industry. You shouldn't be running to your manager for an explanation every time you see some code that's unclear or without comments - you should be taking the time to read through the code, try to understand what it does and then make notes as you go so as to get a grip on the codebase.

If you must go to your manager for help, then don't just ask him what it does - come to him with a reasonable explanation of what you think it does, and ask for clarification. You'll generally get a much better response (and start to build respect) if you show you've put some effort in first.

Once I had a chance to implement a new logic. So I did – to take revenge I did not put any comment to the code.

Noooooo. If you want to gain trust, this is entirely the wrong way to do it, you're essentially sabotaging the code base to prove a point. (Regardless as to the debate as to whether your code should have comments or not, your motive here is wrong.)

If you want to convince your manager to switch coding style, lead by example - create clear, concise code that's unit tested and easy to understand. If your manager starts seeing this code and immediately understanding what it does, then he's likely to get the impression that "hey, component writes really good, clean code" - and that's what's going to gain you respect.

Improve this answer
2

Once I had a chance to implement a new logic. So I did – to take revenge I did not put any comment to the code. Now this senior is struggling to understand my logic. He came and asked me to make him understand the logic. I just smiled and explained.

I'm normally an advocate of "trust your instincts", however given your instincts in this case lead you to behave like a petulant child I doubt that advice would work here.

Question: I am not sure how to approach the legacy code and gain trust. The Manager and this senior are working together for a very long time. It is becoming very difficult to gain his trust.

If you want to gain the trust of your colleagues the obvious path is to be trustworthy.

So far it sounds like you've been given at least one major opportunity to prove yourself worthy of their trust.. and you blew it.

So if/when you next have the opportunity to work on some new logic do a good job, comment it how you'd like it to be commented if you were to be seeing it for the first time.

Improve this answer
1
  • I like this. Instead of taking revenge, show your co-workers a better way. I often add comments to existing code as I figure it out, it doesn't have to be just new code. – DaveG Oct 23 '18 at 13:29
0

Do you have code reviews in place? If so, you could start commenting and documenting the code, and have the senior approve them. If you got something wrong, he would explain in the code review. This has two advantages: 1) you improve your understanding of the code, and 2) the code gets documented for others. You might even reveal an odd logic error this way, which could then be fixed.

Improve this answer
2
  • If the boss & senior dev don't like asking questions, I doubt very much they will be open to code reviews. – DaveG Oct 23 '18 at 13:30
  • Then stay faaaaaar away from such a red flag operation :) – Juha Untinen Oct 23 '18 at 17:24
0

I was in this same position recently where the code base had a great deal of technical debt. After my project lead started to show some frustration, I simply started writing documentation for myself. When questioned when I would have a new feature ready, I would respond that I'm building my institutional knowledge on the project, and I had the written documentation to demonstrate that. Fortunately, my project lead was willing to give me the time to learn this on my own as I poked through the code base.

Improve this answer