I think most people are salty about your comment because they fail to see the subtle difference between:
1) "Everyday you should ship something"
2) "At the end of each day you should be able to tell your line manager in a clear and concise way exactly what you did; if you can't you've done nothing."
2) does not mean ship code: you could have spent 12 hours thinking and reading code. But if you can explain i.e provide a daily update, then you have actually done something, and not spent a day on slack sending memes.
i've had days where I did nothing but read code trying to understand a bug, and then my whole contribution was 1 line of config or 2 lines of code. But I have a clear achievement: I understood an area of the code much better and i have a fix.
Having daily updates to your manager also forces you to not slack and work on the most important problems: otherwise you might be tempted to work on sth fun but not mission critical.
At the end of the day, people should do as they wish.
Or you can hire good developers who value their work and want to ship high quality software, and get out of their way so they can get things done. Your method seems to be treating your developers like children who will refuse to get work done if somebody isn't watching over their shoulder. If that's happening, then I think you have a hiring problem.
Many software developers are not that effective at making rapid progress (for whatever reasons), so if you are actually highly skilled and highly motivated you can produce multiple of the progress of some coworkers. But generally management doesn't deliver high performers who deliver multiples of progress multiples of salary, instead they fight to keep it to small percentage rises and don't even fire the deadwood!
This (mis)management destroys intrinsic motivation of high performers and the manager is left with deadwood and skilled but unmotivated people and some average performers, which try to micromanage to get results out of.
Yeah, I think it's telling that folks here assumed I meant "give daily feedback" as in "tell your boss what you're up to".
It's probably a lot more effective to keep your team up to date on what you're doing, than it is to keep your boss up to date on what you're doing, and that's where I was focusing.
And yeah, while I did say "ship functionality", you're right, the real value is producing something you can show users. I prefer that ends up being code, because otherwise users are hard to pin down, but it doesn't have to be.
Finally yes, people should do as they wish, but with the understanding that if the thing they'd prefer to work on isn't the thing the team they're working on needs, that the team should be able to go find someone who does want to do the thing the team needs. It's not really fair to drag a team down because one person isn't having fun.
1) "Everyday you should ship something" 2) "At the end of each day you should be able to tell your line manager in a clear and concise way exactly what you did; if you can't you've done nothing."
2) does not mean ship code: you could have spent 12 hours thinking and reading code. But if you can explain i.e provide a daily update, then you have actually done something, and not spent a day on slack sending memes.
i've had days where I did nothing but read code trying to understand a bug, and then my whole contribution was 1 line of config or 2 lines of code. But I have a clear achievement: I understood an area of the code much better and i have a fix.
Having daily updates to your manager also forces you to not slack and work on the most important problems: otherwise you might be tempted to work on sth fun but not mission critical.
At the end of the day, people should do as they wish.