Output-first learning: okay or bad habit?

Hi everyone,

I noticed something about the way I solve challenges, and I’d like to ask for advice from more experienced developers.

Very often, I fully understand what I need to do only after I look at the expected output or test cases. Once I see the result, I can reverse-engineer the logic and implement a solution without much trouble.

However, when I read the User Stories or the challenge description first, it sometimes feels vague or abstract to me. I understand the words, but the actual transformation or rules don’t always “click” until I see what the function should return.

My question is:
Is this a normal stage in learning programming?
Should I force myself to rely less on expected output and more on User Stories, or is using the output as an anchor a valid way to understand the problem?

If you’ve experienced something similar, I’d really appreciate hearing how you trained yourself to read and extract logic from User Stories more effectively.

Thanks!:raising_hands:

are you writing code that give the correct output with any possible input, or only code that can solve the test cases?

if you are using the test cases to arrive to a general solution, that’s fine

1 Like

The User Stories are important but often the total working of the program isn’t going to be totally clear until you also read the tests.

You need to use both of them.

This is similar to building an application in real life when you will have certain requirements that you are building but then realize during testing that you need to handle certain other conditions.

1 Like