jonwah

When I had to fix a bug, I made sure not to just fix the problem, but to understand it.

There's a massive difference between the two. When I was a junior I would often find out how to fix a problem by googling and trying different things until something worked, but I wouldn't understand why.

Then I started digging into what was actually going on under the hood and finding out the why of things - sometimes it was to do with a framework, sometimes a language, sometimes it reveals a fault in yours or someone else's programming.

But every single time you learn something new and it solidifies your knowledge of your tech stack and programming in general.

Also, one of the best phrases I've ever heard in programming is "every bug is a missing test" - these days the first thing I do with a bug is write a test to expose the bad behaviour - then you can go about fixing it with confidence and preventing regression errors.

React / TypeScript / Vite (sometimes Redux) for the front end, C# .net / SQL for the backend..

Fast-ish to get up and running, scales to a medium-large project with minimal headaches

Stick with it. Programming takes a long time to learn - and I don't mean the fundamentals; I mean there's so much to the job that just takes experience to pick up.

After a while, you can pick up a problem/feature, dive into a code base and instead of becoming lost, things just slide into place in your brain and you can focus on the problem/feature rather than having a whole bunch of non essential stuff stuck in your head.

And the secret to getting there is simply wanting to understand. Don't be satisfied with knowing that you fixed a problem, make sure you understand why your fix worked. Don't sweat the bigger picture, just focus on each task. And get good at debugging early, that helps soooo much.

Good luck homie

Yup all valid points. And I find Nuget to be a heaps less painful package manager than other ecosystems

Copying code is exactly the opposite of DRY lol