Guilty. Usually when coding UI stuff or getting a webpage to display right. Most recent example: moving some code from the keydown event to the keypress event made it work and I neither know nor care why.

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...

It depends on how late it is at night and how close we are to a deadline. If I've been sitting there trying to fix something about its going on midnight then I don't care why the fix worked as long as it worked. Likewise if we are close to a deadline and running out of time then I need to move onto other tasks once that one is finished instead of trying to figure out why a fix worked. I always tell myself I will come back someday to see what magic happened, but I rarely do.

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 ?

[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.

[color="#1c2837"]Fumbling in the dark is another way to look at this. What ever happened to craftsmanship ?
[/quote]

It's called deadlines.

Even though I stated above that I tend to be a slower developer, I look at it this way. In the overall lifespan, I actually tend to have a finished product at a similar rate as a faster developer. Take the 80/20 rule. I try to spend more time having cleaner code so that I don't spend time in the future debugging. I just personally find that spending a bit of extra time to make sure everything is maintainable and in proper working order makes future development on the software easier than hacking the code together.

But your manager (or the top brass, or whoever) doesn't see it that way. For some reason, almost every company I've ever worked for sees the programming as the end-of-life for the project, and sets the deadline based on that alone (for the most part). Any debugging is required afterward is a necessary evil. In that sense, the faster developers are viewed as the more productive members regardless of how much time needs to be spent fixing the code.

When I was first messing with AABB collision detection and basic physics I did a lot of copying and pasting stuff in different orders when I would get frustrated and didn't want to think anymore.

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!"

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.