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.

  • LondonPilot@lemmy.worldEnglish
    9·
    1 year ago

    I got my first programming job in 1996. I still have days like this.

    Today, I had a conversation with my boss about an apprentice in our team. Our senior front-end dev left a few months ago, and the apprentice has had to take on a lot of work with little guidance. Our team is very full of back-end devs with no front-end experience. During this conversation, we described our apprentice as “extremely capable but lacking experience”, and discussed the best way of getting him more experience. The conclusion we came to is that there is no shortcut here, but having good guidance from senior devs can help somewhat.

    What I’m trying say here is that what you’re describing is absolutely normal, and based on what you’ve said, you’re doing fine. You have a little imposter syndrome, which seems worse than it is because of your genuine lack of experience… that experience will come with time, and days like today are the days where you learn a load from your mistakes. You’ll probably not hard-code things like that in future, and today you gained a tiny bit of that experience that you need - well done!

  • Cosmic Frog@lemmy.mlEnglish
    4·
    1 year ago

    Just two months in and it’s your first time in the job? You’re good my man, your doing exactly as expected.

  • SokathHisEyesOpen@lemmy.mlEnglish
    4·
    1 year ago

    maybe we could do it this way or that way

    This is where a team coding standard, naming standard, and formatting standard really helps.

    You’re always going to receive feedback on your code. Part of what makes coding fun is that there are a million different ways to make something that works and most people are going to think their way works best. More experienced engineers most likely do know a better way to do it, so take their suggestions, figure out why it’s better, and apply those principles to all of your code. But sometimes junior level people come up with great ideas. It’s important that you know why you made certain decisions, and to be able to defend those decisions. After considering recommendations, consider if they are actually better, and if you think they aren’t, then have a conversation about that.

    If you don’t have experience working with dynamic data then it’s normal that you just forgot that you needed props instead of text (or whatever your situation was). Now that you made that mistake, you’ll probably never make it again.

    Don’t be too hard on yourself. There is too much for any single person to remember. I’ve been doing this for 20 years and I still have my head in the docs several times a day. On that note, make frequent and liberal use of the documentation. It’s okay to forget stuff you haven’t done in awhile. Yesterday I forgot what the freaking span element was called and I’ve made spans a hundred million times before. It just poofed out of my memory. What’s not okay is not knowing how to find the information you have forgotten. Again, learn the docs and use them religiously.

    Always remember that there are two states to every programmer. That link is a funny but accurate reminder of something we all experience…

    Good luck. We’re all counting on you.

    • django@sh.itjust.worksEnglish
      4·
      1 year ago

      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.