Also, I'm not a junior programmer that needs someone looking over my shoulder to make sure I've implemented a spec correctly. Saying it doesn't do what I think it is doing is like saying that I may not exist even though I think I exist.
Also, I'm not a junior programmer that needs someone looking over my shoulder to make sure I've implemented a spec correctly. Saying it doesn't do what I think it is doing is like saying that I may not exist even though I think I exist.
Therefore if you're taking short-cuts, the possibility that your code is doing something other than what you think it is is realistic, not ludicrous. Now it may be appropriate for you to take those shortcuts. But you shouldn't take them without being honest with yourself about the risk.
And what "risk" are you referring to? As I've stated, I decided to side with "more features" than "100% test coverage". Sure there is "risk" that there are bugs, but a) there are bugs regardless of how much testing you do and b) I've decided I'd lose users because I don't have features that stand out above the competition rather than because a minority of those features have minor bugs. So to me, the bigger risk is not developing more features.