Sometimes there are little details that increase risk if you don't pay attention to them.
Like can't you use either "==" or "===" in Typescript but the first one can sometimes do a type coercion that can occasionally have unexpected effects? If I remember right it is a warning but not an error, a programmer who is clearing up warnings will stay out of trouble but if you weren't clearing warnings it would make a difference if you had a "==" or "===".
One thing that makes you a better dev as opposed to a worse dev is your habits, especially when it is something obscure where the compiler and IDE don't have your back.
Hopefully there's a senior/staff engineer where you're at that actually knows the difference and is able to (find time to) comment on PRs where the wrong one is used. It's one of those "background radiation" things that you develop after working in a language for long enough.
TypeScript on the strictest settings + aggressive ESLint rules is incredibly strict and a fantastic target for AI code. It's a good practice to have the CI/CD server reject code that fails ESLint anyway.
Comments
Sometimes there are little details that increase risk if you don't pay attention to them.
Like can't you use either "==" or "===" in Typescript but the first one can sometimes do a type coercion that can occasionally have unexpected effects? If I remember right it is a warning but not an error, a programmer who is clearing up warnings will stay out of trouble but if you weren't clearing warnings it would make a difference if you had a "==" or "===".
One thing that makes you a better dev as opposed to a worse dev is your habits, especially when it is something obscure where the compiler and IDE don't have your back.
Hopefully there's a senior/staff engineer where you're at that actually knows the difference and is able to (find time to) comment on PRs where the wrong one is used. It's one of those "background radiation" things that you develop after working in a language for long enough.
TypeScript on the strictest settings + aggressive ESLint rules is incredibly strict and a fantastic target for AI code. It's a good practice to have the CI/CD server reject code that fails ESLint anyway.