In fact, not only should you be able to give daily updates, you should be able to ship functionality on the daily. From first line of code into production and in front of customers should only ever take about 2 to 16 hours of work.
If you can't work at that cadence, you're probably not being as effective as you could be, as a developer. A "good" manager enables you to work like this.
Agile is, by far, a more effective way to run an R&D shop. By far.
"Agile teams show progress with working software, not documents. Right from the beginning. And that's huge." [1]
[0] The Art of Agile Development, pp. 35 [1] The Art of Agile Development, pp. 8
Breaking down work into small, day-or-two chunks is a team effort that the developers are doing together, alongside the customer (representative, usually).
I've worked on teams that run the full gamut here. Those that did scrum and enforced "an every task should be one or two days" did not ship more or higher quality software than those that didn't, and the development teams were consistently more stressed and less satisfied with their work.
Hell, I've fixed 1 liner bugs that have taken me a week to figure out.
...
- ask for help
- try to explain how it's supposed to work
- try to explain how it's not working
- Listen to them come up with all the ideas that I've already ruled out
- Try to explain why their preferred idea has already been
ruled out or is not actually relevant to the problem
- conclude they still don't understand the problem or even
how this part of the system works
- go ahead and just solve the problem myself
...
What I've found to be a good middle ground is take some time to think things through myself first, at least in rough strokes. Then have someone else come in and review the work. There is a balance of doing too much vs too little yourself of course, but I don't think there is a hard and fast rule (e.g. 1 day worth) for it.
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.
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.
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.
I didn't make up any of this, it comes directly from Joel Spolsky in his article titled, "Evidence Based Scheduling". [0]
[0] https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...
This creates unnecessary exaggerated expectations. There is only so much you can accomplish in one day, some functionality take way loger than that. We don't want to ship half baked solutions, but we are expected to do so... In order to accomplish that sacrifices have to be made on everything else that is important in software development: proper testing, documentation, refactoring and a clean codebase. Its perfectly valid for a developer to give the update "I am still working on ..." / "I am still trying to figure out:..." / "I am in the process of preparing the codebase for this update" for a certain period of time.
The systems supporting shipping daily should exist either way, though.