Beat Frustration, Use Documentation
It’s dang hard to read the docs, at sometimes it can even be risky. You should do it anyway.
When Choosing a Project
There will always be a point as a software engineer when you are going to be faced with the possibility of having to learn something new, and it’s not something that comes freely or easily. You have to wager your attention and invest in deeply reading and researching some library, toolkit, or methodology, and each will come at a cost.
It’s always worth it to take a moment to outline what you’re going to do, or the goal you want to accomplish, and take a good look at your constraints before you set out to research.
Say for example you are building an AI business that can watch videos and spit out localized translations, add the translations as subtitles then output the video with the subtitles attached and ready to be viewed by the local audience.
There could be several different tools involved in getting the job done, you’ve got to find (or create) a tool that can watch a video, figure out what is being said then output what it thinks was said. Then some tool has to generate translations, followed by some tool mapping the captions to the points in time during which they are being said, and finally, another tool to get the captions on the video.
