There are idiots out there.
If I need to debug someone's code, probably the first thing I ask is "are there test?" If you are lucky there might be some unit tests ... and they might even all pass too! :)
Sometimes it is easier to debug a test then it is to debug the whole thing (due to isolating the code you are interested in). Even if it is easier to debug the running application, having a semi-decent suite of tests is your lifebelt for making sure you are not inadvertently changing behavior directly or indirectly.
Other things I like to do:
- ask if you are the best person to be doing this? Did it land in your inbox/task-list because people thought of your name first? Is there someone else better qualified/with-context who might be better to do anything before you even start thinking about it?
- look at the change history of the code you are debugging - is it a "hot spot" that has had a lot of different hands fiddling around with it in the past (indicative of code that might have been troublesome and/or buggy in the past, with the risk of dirty hacks increasing as the number of changes per LOC increases...), or has it not been touched since check-in #1? If there have been lots of changes in that code go through the changes and look at the associated bug reports to make sure that any existing unit tests cover those scenarios (you may want to add them yourself if not, before you make any changes).
- when reading someone else's code I actually find it better not to try to equip myself with all of the domain knowledge and docs. Often if the original developers are long-gone then the docs will likely be way out of date anyway, and sometimes it is easier to just be laser-focused on the parts you care about rather than try and get a handle on the whole system. I guess it depends on what you are doing though - i.e. simple bug-fixes or doing something more far-reaching).
If writing testable code means writing obfuscated code, it's a good sign that the language ecosystem needs to improve, and for Java, it has.
1) Never assume the person(s) writing the code will be available in the future.
2) Any given sprint should auto-add task/time for documenting and such. An hour or two now could save 5x, 10x or more later.
3) The more critical the feature/functionality, the more important #2 becomes.
With that said/in mind, I couple probably take the stand that this is because (e.g., marketing or finance) believe app dev/IT is identical to them. Bad assumption. Very bad assumption.
2. Find an entry point. If it’s a CL find main and then where params are parsed. If it is a GUI or web app find a form or menu.
3. Don’t debug, READ the code and trace with pencil and paper for notes. If you’re debugging you’re not reading.
Wash, rinse and repeat a few times. Note all questions you may have.
Now go find a domain expert to answer your questions.
The most efficient way to find the problem and fix it is to find a string and start pulling it. Don't waste your time researching everything - you don't where that problem is yet.
You're either starting from "when I try A, B happens, but I want C" or you're looking at "the logs show this error (or just stop after last successful action)".
Use that as a starting place and follow it carefully until you get to the suspect behavior. Then start learning what's going and why it's wrong. Half the time, it's a red herring and you need to keep looking elsewhere.
It's take some effort to put on the blinders and ignore everything else, and you need to be OK with not knowing how some parts of the system work. If you need to know it to fix the problem, you'll learn about it in the course of your investigation.
I’ve been at a couple of the large FAANGs. You don’t need to be able to do all of this on a day. If you do, your management fundamentally doesn’t understand what’s going on. If you’re at a senior level, it’s your job to communicate. If you have non technical stakeholders, you must be able to take complex topics and break them down and influence your stakeholders to agree to the right thing or at least explicitly accept the cost of what it is you lose by doing A over B or C.
Edit: I did work at a company before where something like this was an expectation, and not just from senior folks. The underlying issue was the manager chain upwards was all people managers who fundamentally don’t know the first thing about software development. The best you can do in that situation is break down the problem, size components, and communicate.
As a group, we need to better understand how to read and debug code written by others.
Unfortunately, the kind of environments that throw you into unknown code often change your project so fast that any attempt to understand the system more deeply will be soon lost as you change project again.
This might be a nihilist view, but lots of coding jobs are essentially exercises in futility anyway, so might as well be efficient about it...
1. Identify change points.
2. Find test points.
3. Break dependencies.
4. Write tests.
5. Make changes and refactor.
Working Effectively with Legacy Code, 2004, p. 18
