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.
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!
Thanks for the response.
You’re correct in that I appreciated the bluntness of the feedback and I truly believe that you only learn when people are honest with you, plus I have a personality where I would rather receive negative feedback than positive.
Imposter syndrome is very real and I just hope that they see my passion and diligence in always asking for feedback on my implementations and keeping a list of todo questions for when I am unable to get the SE to come sit with me and go through them.
In guess a lot of this stems from the probation period and me being irrational about them not keeping me past then 😔
Just two months in and it’s your first time in the job? You’re good my man, your doing exactly as expected.
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.
I do enjoy the feedback and the more negative the better imo as that is a learning experience, plus I can’t handle praise.
I can relate to forgetting things I’ve done before but I agree, we work in this field as we like to solve problems and we are arrogant enough to think (know) we can just Google the answers to everything.
Speaking of docs, I got called out for Googling (with the SE) how to show the long day name using Moment. It is ‘dddd’. I was Googling and just clicking stackoverflow kinda out of habit until she said slow down, go back, let’s go to the moment docs and click on formats. We found the answer much quicker so I need to get in the habit of checking the official docs first.
Also, that meme is perfect. Self esteem goes up and down in this job. I think a lot of my worries will be here until probation is over and that I am safe.
Imposter syndrome isn’t fun.
Make use of ChatGPT if your employer allows it. It Is actually amazing. I’ve been using it for about 3 weeks now and I’m probably 400% faster. GitHub Copilot is pretty great too.
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.
