God damnit, I have this too often. Something works in my mind no matter how often I run through it again and again but I've got no clue how to test it for real which brings me into a "mental deadlock" state aaaand then I lose all my programming motivation at once.

Having this right now, fucking annoying.

Do you mean some kind of algorithm?
I'm not sure if I understood you correctly.

@PonySlaystation Call it how you want haha, an algorithm is an example indeed.

Right now I'm trying to write a system which checks if something has to be ran every x seconds and I'd need 'real life' data in order to test it which pretty much means i could just write the fucker right now but i can't be a 100 percent sure if it works so then I go into 'deadlock' mode :P

@PonySlaystation rephrase: algo/piece of code etc yes

You code it and then see if it runs?

@billgates Well yeah but I've had it regularly that the technology simply works differently than I thought or i made a design mistake in my head anyways and then a few hours might be wasted and I fucking hate that

@linuxxx hmm maybe you started too big. I've had that a few times. Actually ditched my last project because realized I couldn't get the data I needed from the data source.

Usually I start out breaking up the problem and then sorta writing/testing the critical code, things that need to work. For GUI apps, I tend to write the API/backend first and just test each part by running some the code in a TestRunner class... Sorta like TDD, and I guess maybe that's the point. You figure out if something breaks early rather than after writing the whole thing and seeing it crash or not.

@linuxxx you mock the data source and feed it into a wireframe app

Break it down. You can create test data and have 100% control over the program flow. Expand test data, throw in random test data. Get real users to test etc. Adjust one small test case at a time. Adjust as needed and look for patterns to break down multiple test cases into smaller or combines cases. Step by step.

Actually I just really thought of an analogy. Coding an app is like solving a jigsaw puzzle except you have the diagram/blueprint but you need to create the pieces.

With experience, you know some pieces are easy to build with different tools and some pieces are hard you need to build from scratch. You start with those and make sure they can fit into the blueprint.

And if your blueprint isn't clear, has too few parts or too vague, you end up with shoddy apps that have to be replaced entirely when something in it is damaged... or u need to the use scissors to cut out the parts that are broken and need to be replaced