I have to say that since starting I’ve had a lot less support than I was expecting and I’ll be given something to do but very sparse direction. I’ll go away and do my best and usually be told that based on the little guidance I have done good but maybe we could do it this way or that way, which is great as that’s how we learn right?
Also, preface saying that I’m working on a Typescript React app alone as the others have other projects.
So queue today. I’ve got a todo list of questions about my implementation and things I could do better, which they like my diligence of keeping track. Well I was working on a component and like an idiot I hard coded a lot of the data that is subject to change if say they add a new let’s say PetType. So the SE comes over, tears my code to shreds and like a wizard makes it work even better with only dynamic use of data.
I don’t mind the tearing my code to shreds as again it’s a learning experience but my self esteem has dropped off a cliff.
Just to add. It’s not that I was incapable of loading the data in a dynamic way, it’s more the thought process and it didn’t occur to me at the time.
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.
This is the approach I generally take and I always think it’s poor as I watch the SE’s come over and just write whole components in one go that work seamlessly whereas I will tend to need to figure it out iteratively and thus my code can look like a mess but I will go back and refactor once I have something that works.
I guess it comes with experience as the app I am building is following the contentions of other apps this company has made so although it’s the first time for me, the SE might have made ten very similar apps using the same custom hooks etc.
There’s a difference between iterating on your code patterns until you get something working and iterating on the solution as requirements evolve. You’re only two months in so you still have loads to learn, but eventually you’ll come to know all the “best practices” so that when you’re presented with a problem, you can immediately know what the ideal solution should look like. The caveat there is that the ideal solution is subject to change as the situation changes.