When I do programming, I do it in either of two "modes". Each of these modes serves a different purpose and I use them at different stages to achie...
For further actions, you may consider blocking this person and/or reporting abuse
How do you know what's "obvious" when deciding what to document?
Great question! And a question that you should ask yourself and your teammates every time you are not sure.
Here is a fictional example:
What would be obvious and what would not be obvious about this function?
It obviously prints
textatposition.What is not obvious: Is there a maximum length for
text? What happens when position is outside of the canvas? Will an exception be thrown? What happens when position is inside the canvas, but text will flow outside? Will it be wrapped?What color is
textprinted in? What font face, font size, etc.?And, since C# and Java are one of the stupid languages that mostly-always allow null for everything even when it makes no sense at all, you should state what happens when either of the argument is null. (Incidentally,
System.Windows.Pointis a struct in C# and therefore does not allow null, yay!)"I Don’t Always Test My Code. But When I Do I Do It In Production" :D
Nah, it's more about distinguishing learning from creating. I've seen all too often devs putting horrendous effort into code, design and tests when they didn't know the underlying tech, dependencies and quirks yet, leading to constant refactoring along the way - which actually leads to bad quality if you are not willing to throw away all your design. And it's still more effort than necessary, you could do better when first experimenting with no regard to quality. And after learning, throw the experiment away.