When I'm getting into something challenging, my first goal is to understand the code that's already there. I sometimes write tests just to experiment and see what the code does under specific circumstances, but usually I just read it thoroughly and make sure I understand it. (This does not cover the circumstance where you're dealing with horrible legacy code with no tests, no documentation, and no institutional knowledge beyond the desperate certainty that it must not break. That's out of scope for today.)
I draw a lot of diagrams (mostly just boxes and arrows on paper) to help me understand the code, or to help me clarify how I plan to implement something. (Mostly I focus on how the data moves through the system, as that's usually more illuminating than looking directly on how the code operates. The code is the how, the data is the why.)
When I'm starting to code, I'll write one or two basic test cases to clarify my thinking and give me an easy way to run in a debugger, and add more tests as I get closer to a finished product.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
When I'm getting into something challenging, my first goal is to understand the code that's already there. I sometimes write tests just to experiment and see what the code does under specific circumstances, but usually I just read it thoroughly and make sure I understand it. (This does not cover the circumstance where you're dealing with horrible legacy code with no tests, no documentation, and no institutional knowledge beyond the desperate certainty that it must not break. That's out of scope for today.)
I draw a lot of diagrams (mostly just boxes and arrows on paper) to help me understand the code, or to help me clarify how I plan to implement something. (Mostly I focus on how the data moves through the system, as that's usually more illuminating than looking directly on how the code operates. The code is the how, the data is the why.)
When I'm starting to code, I'll write one or two basic test cases to clarify my thinking and give me an easy way to run in a debugger, and add more tests as I get closer to a finished product.