Software managers, team leads, and the like often use software estimation to evaluate the time and efforts in achieving project goals. These are educated forecasts. They’re based on individual experience, metrics, skills of staff, domain knowledge, et cetera. You could call it a black art, like predicting the stock market but in a different paradigm (you’re not hoping for a win, you’re looking to create one). When they estimate, they are either creating a project plan or evaluating progress.
As a front line developer or anyone else, where do you fit in with all this? You’re the one who will complete the activities in the plan. Does this mean you’re just a spoke in a wheel? Not quite. This is where you get to shine in your every day job and demonstrate you are valuable. As odd as it sounds, you can do this by being predictable in your work and in consistently doing so. It means being on time and on budget. Bonus if you create a high-level of satisfaction (in quality and service). As you do this and you complete more activities, you’ll gain more confidence, trust, and respect from others you work with. It means you can get things done and you are reliable. You have learned how to manage your time and focus on priorities. You can be trusted with bigger responsibilities and eventually oversee the work of others (if that’s what you want to do). The fact that you are tracking to your manager's plan means her or she doesn’t have to explain to someone else why the plan isn't working. In fact, the plan IS working.
Your lead’s estimate may not be accurate, however. Maybe there is something they didn’t know and they didn’t allocate enough time for something. Maybe it was accurate, but something came up that is imminently blocking you from achieving your goal. When they approach you in a friendly way asking "how are you doing?" they’re fundamentally asking how your progress is, not how you are today. Don’t dwell too much on what you did this weekend and take the opportunity to manage expectations. It’s your responsibility to discuss completion time, for the project’s sake and yours. Even if there's nothing to report, mention that. If you need more time because you hit a road-block, plans can change if discussed. This helps you remain predictable. You’ll be asked to do estimating of your own: "how long will it take?" To which you might respond "I think I can solve that in two days," but don’t forget to add any overhead time involved: " ... I'll also need to update the unit tests, run them, and update the documentation... so an extra day if all goes according to plan. Three days."
If you were a manager, wouldn’t you want someone you could just give the ball to, say "score a goal," and watch that point get scored?