As an experienced programmer, I can say there's nothing inherently wrong with hardcoding data. If you're not presented with clear requirements up front (i.e. all the different use cases your code should handle) then it makes more sense to get something working and refactor as you go. In your case you said the data was subject to change, which doesn't necessarily mean you could abstract it out from the start (unless you were told exactly how it would change). In general, however, software development is all about iteratively refining your assumptions about how things should work while simultaneously juggling the changing demands of stakeholders. One of the most useful rules of thumb is the DRY approach (don't repeat yourself). This is complemented by WET (write exactly twice). Together this means that if you find yourself repeating logic three times, that's enough for you to refactor into a single, generalized function. Repeating twice is generally fine because your third use case might be sufficiently different that a premature refactor is a waste of effort. As you gain more experience programming, you'll find it's less about technical proficiency and more about working efficiently, creating fewer headaches, etc.