Intel was my first exposure to "management by objective" and "key results". And yes, there were weekly reviews of your progress. Every quarter, a set of objectives and under each objective key results, and then weekly you reported on how you were doing with respect to those.
I think the key to your stress is either that you aren't clear in your head what you're trying to figure out, or your trying to figure out things that aren't actually relevant. In my life what I have done is to do get very very disciplined about what I'm to understand and how that will relate to the final goal. Not surprisingly that is different as a manager than it is as an individual contributor.
If I were your manager, and you came to me with this (and I would hope your relationship with your manager is good enough that you could talk to them about it) I would start with three questions;
1) What parts of your assignment are you completely confident you can build/write?
2) What parts are you unsure of how to build?
3) What things that you are unsure about are between you and building the things you know you can build?
Perhaps you can imagine how the conversation goes after you answer those questions. But lets say for this hypothetical that you were unsure if you could build a database fast enough to respond in time to meet the response requirements of the product.
At that point we'd talk about what steps you could take to understand what sort of performance to expect out of a database, what variables had the biggest impact on that performance, and which databases were designed to be fast. And you and I would agree that you would spend this sprint perhaps developing your understanding of database performance. So at the stand up I'd expect you summarize and article you read, a set of benchmarks you set up, a set of test tables you created in the existing system, or maybe the top 5 blogs/books/videos you've found on analyzing database performance. At the retro I'd want to know what sources gave you the most information for the time invested, what were the time wasters, if you were more or less confident about the database choice and its performance and maybe how you had, or would, quantify your understanding with something objective.
From your perspective you would probably have spent the time 'surfing the web' to find out various sources of information or perhaps prototyping some things on AWS or on a local server.
If instead you came back and said, "I really don't know anything more about databases yet but I learned Rust, and got stuff running in the new Angular release and updated my server to the latest Ubuntu and read a book on containers. Then we're going to have a different talk :-)
