I'm interested to hear what your experience has been dealing with optional data. For example if the input pdf has fields which are sometimes not populated or nonexistent, is Gemini smart enough to leave those fields blank in the output schema? Usually the LLM tries to please you and makes up values here.
I had the pleasure of visiting Gunkanjima a few years ago. If you're in Nagasaki, there are a few tour operators that ferry you to the island for a tour. Unfortunately you can't explore on your own for safety reasons, but still an amazing place to visit.
I agree with everything said here, but I'd like to add a couple of extra points:
- 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.
It's hard to provide specific advice without knowing the exact nature of the underperformance, so I'll keep it general.
- 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.
Temporal has the option of using postgres as the persistence backend. Presumably, the simplicity of DBOS comes from not having to spin up a webserver and workflow engine to orchestrate the functions?
