How do developers show progress when it's a "slow week"?

First of all, you say that you are a one-man "dev team," which actually means that you are not a "team" at all, but a lone wolf. So, "team" dynamics really do not apply to you now.

(Please understand that I do not say this "as a judgment." Every situation is different, and all are valid.)

Right now, you're the only one making the decisions, and you're the only one responsible for your progress because you're the only one who's making decisions about "what you'll be doing tomorrow." This is an acceptable(?) strategy, but only on an extremely small scale. And in any case, it is not a team. "There is no such thing as a 'team' of 'one.'"

In the classic spectrum of "project-management maturity," you're sitting at zero: there is no team, and there is no management. There's just one very-capable wolf. You.

I would say it's okay to be slow. I was thinking like that as well when I have nothing to do that much or when I feel like a little bit slow. However, it's good to think a little bit about that especially during the "learn" phase. Everyone learn at different pace. One person can try a little bit hacky way and make it works, others wants to put an ideal framework and idea before starting to work. Eventually, both will agree in the middle (in your case, you will find the middle ground)

ISSUE TRACKING AND ASSUMPTIONS

Most all teams (working proffesionally) have some issue tracking implemented.

They do not track "lines of code out the door" as others have commented on, but the progress on the task itself.

You (and your team) identify the issue and assume how long it's going to take you

The issue could be a bug, refactoring, learning something new, writing documentation or tests. Not all of those produce code or new features.

The time is including self-learning and everything else.

Unless you're experienced with what you're working on, these assumed times change, we try to give ourselves as much time as reasonable (i.e. assume how long it§s going to take and double that).

It's not always possible to have that time and at that point, you either scrap it, change the requirements, move it to some other time (ages and ages hence :)) or pull an allnighter and CRUNCH.

Correct identification of how long something is going to take is a very important skill learned by getting it wrong and learning from it.

Don't be afraid to change the assumption as you learn of new problems/constraints and don't forget to properly communicate with others around you who have an interest in them.

You then work on it and update the issue as needed (update the task in JIRA, tell others during a stand-up, tell your manager on a weekly meeting,...). You COMMUNICATE with people around you as needed.

People who are used to this know that as a junior (assumption on my part since you're asking this) you don't have the knowledge to call the time it's going to take. Even seniors don't know everything beforehand, they do preliminary checks and update/create the assumptions after that.

Tasks are not about how much code you've written. There are a lot of internal tasks (setting up an environment, trying to reproduce a bug, learning something new in order to implement something, refactoring, getting rid of technological debt, writing tests, writing documentation) where you don't write much code at all and instead sink your time to just trying to do something seemingly unproductive.

During a stand-up, you're answering not one, but three questions:

• What have you done yesterday?
• What's blocking?
• What do you expect to do today?

If you're blocked for the whole week, everybody will know about it, because you will be sharing it five stand-ups in a row.

In this case, the team is not expected to blame you for being slow, but rather to help you to figure out how to solve the issue which prevents you from making progress. This help can take a form of pair programming, or suggestions for a different approach, or advice to contact the persons outside the team who can help you.

It really depends on the company and the people checking the progress.

In some companies the managers just want to show what was done, and the best thing for that is releasing new feature (because that is what salesmen and clients see). In other companies they understand that the code need to be maintained and clean to avoid code cluttering (and usually those companies are the ones who were first running for new features).

Personally if I'm in a slow week (stay on a specific bug for a long time), I just write documentations to explain everything I do, every step I take to show that work is not always visible for a non-tech person.