This is really how all new code is birthed. You start build something from no prior knowledge and few assumptions. It gives maximum agility and freedom to pursue multiple paths initially.
Well the other way to approach the problem is to basically craft out a whole framework: create classes/interfaces/tests and slowly fill them in.
Occasionally I will code that way when I'm fairly certain of what I'm doing but you have to be very careful that you're not painting yourself into a corner.
In my experience, new programmers tend to build a lot of structure for their code that it's not clear they even need yet or will ever need and then often end up solving a problem with much more code than was necessary. It's usually my advice to get something (anything) working end-to-end first and then expand on that rather than the more linear approach.
Occasionally I will code that way when I'm fairly certain of what I'm doing but you have to be very careful that you're not painting yourself into a corner.
In my experience, new programmers tend to build a lot of structure for their code that it's not clear they even need yet or will ever need and then often end up solving a problem with much more code than was necessary. It's usually my advice to get something (anything) working end-to-end first and then expand on that rather than the more linear approach.