Yes. BUT! Only on non-critical stuff. I never, ever, let this stuff get to the core of my engine or to any important mechanics anywhere - knowing that if I do it will eventually make the whole game collapse because some obscure piece of code was left unattended. However, when prepping for release and fixing stuff all over the place I don't have the time to validate every bug, so if I throw it at a wall and it sticks it stays, full-stop. Besides, there is a lot of tinkering done that has less to do with bugs than it has to do with annoyingly specific bugs.

For example: I once had a problem with a character consistently falling off the map even though I was sure that particular place had no holes in the geometry, had absolutely perfectly valid collision meshes, and everything else checked out just fine - 9/10 it wouldn't even happen! So, naturally, I took the recourse of debugging, running through the numbers, even going as far as digging in the engine source for collision detection. Finally, admitting defeat, I just "plugged" the "hole" with a messy code bit that said something along the lines of "If character enters xyz area then don't let y ever fall below ground_h value". After that, it worked and I never found out why. Doesn't bother me much, even if I wish that I had the time to actually research the issue instead of just getting on with work, if only to avoid it ever cropping up again...

I will sometimes poke at stuff to try to figure out what's going wrong. I'll never check in code that has been "fixed" that way though. It's important to know why it didn't work, both for your own educational benefit and for the sake of your program.

There are some guys at work who routinely don't put in their due-dilegence. They tend to get their stuff into code review quickly. Then the code reviews drag on forever as people keeping finding problems or having questions that even the author can't answer. And the rest of us usually end up having to rewrite their stuff as it becomes clear that there are way to many bugs that just got hidden. Or the bug got created when they were poking randomly at stuff and they didn't bother to fully test everything afterwords. They also tend to be the ones that have to have stuff explained to them every month or so because they can't be bothered to get a firm mental picture of what the pieces are and how they fit together.

[color="#1C2837"]I personally do this a lot. Many times I'm faced with something I don't know or understand and I start making random assemblings and trials until it starts working. I sometimes think of it as a kind of "genetic algorithm" way of doing things. [/quote]
[color="#1c2837"]Fumbling in the dark is another way to look at this. What ever happened to craftsmanship ?

I'm sure I've done it a lot when I've been tired also. I definitely remember the, "Wait what am I working on? Hey it works! Sweet!"

Yeah, tiredness, boredom and deadlines are the classic situations in which this may happen. Sometimes you just don't have the time or the willingness to become an specialist in every aspect of what you're working at.

These approaches work well until you run into untraceable, hard to replicate bugs that leave you pulling your hair out for hours trying to fix and end up having to redesign a huge piece of architecture to fix. Often enough you save a ton of time with a good design and understanding of what you're doing in my experience!

This is pretty much the only way I code. Yes I suck at programming.


Almost nothing I do works the first time.