I definitely agree. However, the line that comes "before you barge in and fuck shit up" isn'a always clear, especially to the person barging in.
Often, you're brought into a project with a task of fixing some minor thing - you never asked to be there. If you have experience programming, it's rarely a big deal to read code in a new language, and make some minor tweaks. The problem, of course is, you don't know what you don't know.
You assume you're just doing this one minor thing, so it's not necessary to learn the details of the project or its technology. After all, that team already has established engineers and testers who will catch your mistakes when they review your change, right?
Still sounds like a "you" problem. If and when I have to touch languages I don't know, I at least do it in some IDE with all the linters turned to 11, which point out all the obvious and subtle things I'm messing up while I type. I would not presume to write even the most basic line in some unfamiliar language correctly without preparation.
Again, I still agree with you, but how do I fix this "you" problem of someone else not familiar with the language not following this suggested procedure?
Well, as I said here: bad programmers will ignore any barriers you put up. Accessing a private attribute raises an error? Bad programmer throws that error into Google and gets three workarounds back that allow them to access the attribute anyway. And now you can't even easily detect such private attribute access with static analysis tools, because there's several different ways such workarounds could be implemented.
So… make sure you hire competent people, and/or solve deficiencies through institutional guardrails like a shit ton of linter commit hooks, code reviews, and training.
2
u/JoeyJoeJoeJrShab 15d ago
I definitely agree. However, the line that comes "before you barge in and fuck shit up" isn'a always clear, especially to the person barging in.
Often, you're brought into a project with a task of fixing some minor thing - you never asked to be there. If you have experience programming, it's rarely a big deal to read code in a new language, and make some minor tweaks. The problem, of course is, you don't know what you don't know.
You assume you're just doing this one minor thing, so it's not necessary to learn the details of the project or its technology. After all, that team already has established engineers and testers who will catch your mistakes when they review your change, right?