[wvenable]

When I was working on this https://codaris.github.io/UnderDeskBike/ I honestly didn't know if what I wanted to do was even possible at many layers. I didn't know how to do Bluetooth. I knew nothing.

It's not worth doing things "the right way" right off the bat because you might not know what that is. My first version was literally a linear file of statements and console output.

Once I got something working and understood the problem space then I could back and fix it up. The final code looks like nothing like the original prototype although at no point did I actually throw it away -- I just transformed it heavily -- but the theory is the same. It started as a console app even though the final product was not one.

[_y5hn]

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.

[wvenable]

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.