- Be aware of the volume of logs you generate. For e.g. if you're in a for loop iterating over a thousand elements, and have a try/catch on processing each element, you're going to generate a thousand lines of logs if there's an upstream issue (database connection error, network error etc.). In such cases, always exit early when you have an unrecoverable error. And I don't necessarily mean exit the whole program, just exit the loop early.

- If you're logging to file, make sure you have a log rotation policy in place with a maximum file config set. In a previous workplace we had a system wide outage because a core component got wiped out because it got too many connection errors, wrote the errors to disk, filled up all the space and took the box down.

- Sometimes underperformance can stem from a lack of engagement because of a disconnect between the work they would like to do, and the work they've been given. In this instance you could try giving them a wider variety of tasks and see if they prosper in anything else.

- You could also change the level of work given to them. If it's too easy or repetitive, this can often cause people to switch off and lose discipline. On the other hand, if it's too hard they get overwhelmed and don't know what to do. If this is the case, then mentoring is the right approach, but only if the level of work is just beyond their abilities. If you give them something miles out of their league, no amount of mentoring is going to get them over the line.

- Something I've tried when I was in your position is to enforce tighter standards in the CI pipeline (test coverage, manual testing notes, linting etc.) to enforce discipline before they push code which forces them to fix their own issues before seeking a review.

- Try getting them more involved in code reviews. Reviews are a skill that should be taught just as much as writing code, and poking holes in other people's code might prompt them to do so on their own. Reviews are also a great opportunity for senior devs to perform mentoring asynchronously - long form explanations on why a design choice was made in a git diff for e.g. and sharing that across the team.

- Finally, they could just be outright negligent, but I'm assuming this is not the case with you. If they're resistant to taking advice and improving, then this might already be a lost battle.

Good luck!

- Top 10 for LLMs - https://owasp.org/www-project-top-10-for-large-language-mode...

- Top 10 for OT - https://ot.owasp.org/

- Top 10 for Smart Contracts - https://owasp.org/www-project-smart-contract-top-10/

- Top 10 for Open Source Software - https://owasp.org/www-project-open-source-software-top-10/