Item — HN Reader

I wholeheartedly agree, if you need daily feedback you're a bad manager (unless you're in some exotic situation like a rocket launch or something).

This issue largely disappears if your engineers are given the proper context, background and system overview.

I'm not advocating everybody should take their project and run with it for weeks on end, but daily updates are ridiculous.

1 comments

I'd actually flip that, and say if you can't give daily feedback you're a "bad" developer (I'd probably use "inexperienced" or "new" rather than "bad", because it's a hard mindset shift and it takes time).

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.

I used to work at an R&D company. While that cadence is possible in a website mill, it’s a laughable blanket statement.

Agreed - I’ve spent months working on a deep tech problem before I could even show a functional core, let alone putting it into production. Some problems take time, experience and foresight to solve and the solution only dovetails at the end.

Just wanted to say thank you for "website mill" … I'm reminded of this stark difference when talking with a friend who builds ultrasonic hardware.

Exactly .... Agile works pretty well in the "execution" phase when all of the requirements are known upfront. For any kind of R&D agile is not a good fit at all. R&D fits the waterfall model better. Ideally it should be like you do your R&D with waterfall and the agile for execution.

"Waterfall works best in well-understood domains without a lot of uncertainty."[0]

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

In my aforementioned example, the set of development practices most often called "agile" was neither the right approach nor what we did. Agile as defined as the ideas in the agile manifesto might have been what we did. It would depend on who you asked and whatever their particular axe to grind was.

So I don't know, and quite frankly we didn't really care if we were "agile." All we found was that "agile" is simply too lossy of a descriptor for meaningful conversations about development process.

People writing books and blogs about what they mean when they say "agile" hasn't caused the industry to coalesce on a concise definition. That horse is out of the barn, and I don't expect we're getting it back.

You can be as cynical as you like, the general idea of (very) quickly iterating to stay focused on what your customer wants is a proven and effective way of build software.

It's not as effective if you're not working in software, or at least I don't know how effective it is, but that's not what this submission is about.

This may be true if you have no aspirations for your software beyond what your customer can imagine in the present. Almost seems like a methodology that has internalized learned helplessness.

I didn't know I was coming across as cynical? Just saying that I have no idea if we were "agile" because the term is so damn malleable. I do know we weren't a cookie-cutter copy of the popular SCRUM inspired workflow that's commonly just called "agile" regardless of whether the team is being "Agile."

This presumes that software is the entirety of the problem being researched, which is not always the case. Especially as you get more physical.

That said, I don't think waterfall works any better there either. Sometimes there's no way past the "muck about and find things out" work.

Keeping a daily log of progress helps prove your research is original.

I strongly disagree with this. This is an approach to development that encourages an extremely limited and short term view on development that leads to low quality software and unhappy developers. It's also only remotely possible with a certain type of software.

Yes. And additionally, you're going to be context-switched constantly by people wanting to show off their days work. No thank you.

If this approach results in you taking limited and short term views of development, or low quality software with unhappy developers, you're doing it wrong.

Breaking down work into small, day-or-two chunks is a team effort that the developers are doing together, alongside the customer (representative, usually).

Not all development fits nicely into day-or-two chunks. Forcing all your work to fit nicely into this type of mold is an arbitrary restriction that serves no real purpose except to check all the necessary scrum boxes, give the illusion of extra productivity, and allow for micro-management. It ends up being completely antithetical to thinking deeply and long term about the the code you're writing.

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.

What do you think of the idea that providing finished work on an every-day-or-two cadence allows you to collect feedback from your customers in a way that keeps your work focused and relevant to their needs?

You can gather plenty of useful feedback to keep your work focused and relevant on cadences other than one or two days. What kind of customer even wants to provide feedback that often? That sounds awful, not to mention being a poor user experience, where users are treated like beta testers, with half baked features constantly pushed out the door.

This also ignores the fact that there is a huge amount of important work that is effectively invisible to the end user, but is absolutely crucial. The workflow you're suggesting disincentives the team from working on those things, and may even punish them for it (as they are not shipping customer visible features).

There is no such thing as work that's absolutely crucial and not customer facing, so it makes perfect sense to disincentivize work that's shaped as you describe.

And before you try to list off work you think fits this category, I urge you to think about how that work could affect a customer's experience.

We asked our customer to include a small piece of information for every request they made to us to better serve them. It took five years for our customer to make the change. A one-or-two day cadence didn't make sense for us, nor apparently, for our customer.

Oh, our customer? It's the Oligarchic Cell Phone Company. They don't move fast. And as a result, neither do we.

let's have a meeting about how to break down our investigation of the unexplained segfaults in nginx that occasionally happen in our cdn into chunks that deliver value daily!

And then let's have daily progress meetings to report on the status of each chunk of the investigation! Please update Jira at least once a day!

This is a great example of the perverse incentives built into the "everything should be done in one day chunks that you report on daily". The team is incentivized to ignore highly important but challenging / hidden work, and instead only focus on things that are highly visible to management.

I think the point is that the only work that matters is work that will improve the customer experience in some way. That could be infrastructure/stability work, or that could be visible front-end work. Not sure how you're using the word "hidden", but that's my reading from this discussion. Either of those things are important/valued by management probably. But none of that should imply or require micromanagement in a high-trust engineering org.

This is really not that hard: "Yesterday I looked for correlations between segfaults and hardware vendors. I did not find a correlation, and my deliverable for the day is narrowing the search space. Today I will set up a micro cluster of random traffic to try to reproduce the crash. Tomorrow I will look for patterns in request bodies and stack traces."

Seriously, I feel you should write a blog post about this types of reporting strategies that describe the work that are both accurate and palatable to management (and perhaps most importantly avoid despise from other developers).

For larger pieces of work, some times it takes me more than a day to just figure out what's where and where I can even get started. I guess I can still give updates daily, but it'll just be "still investigating".

Hell, I've fixed 1 liner bugs that have taken me a week to figure out.

You shouldn't be figuring any of those things out on your own, is the whole point of both the article and my comment.

How many times do I need to go down this path:

  ...
  - 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
  ...

before it's OK to stop "asking for help", and just fix the damn thing?

I could see this the other way, where the reason this path happens is because of a problem with how the team operates so others are not in the loop on the problem or , even worse, the entire system. I think what the parent is proposing is trying to combat that entire issue

Possibly in an ideal environment. But expecting the same someone to work with me for an entire week to either debug or design usually hasn't been realistic. Keep talking with different people, or the same person on and off has a huge context cost.

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.

I'm confused about why you're suggesting the only options are "work together for an entire week" or "don't keep anyone updated about what you're working on for a week".

There are a lot of ways to keep your team updated, but more importantly, it's frankly arrogant to think you can or even should tackle any problem on your own.

Joe is the expert on feature X. When we have a problem in X we ask Joe for help and he invariably provides the insight needed to solve the problem.

When Joe has a problem with X, he should go ask for help, even though he's the one best able to deal with it? Should he ask himself for help?

Can you see the problem with blanket statements like this?

I've been in this situation many times too, but I have to say it feels like a weakness. When a single person works on a problem I see improvements being left on the table compared to when two people effectively collaborate. I've experienced this in a wide range of skill/experience levels so I don't think that is the problem.

That said, I don't know how to change the situation if you have devs with skillsets that don't seem to overlap much, which seems inevitable for some companies

In general I agree, where possible and where it makes sense getting others involved early is a good thing. Somethings are more solo work however, at least for a while to get things oriented. Some times it takes time to gather enough context to even start to express a problem space to others. Not everything is just adding a button to a web page.

The problem is not giving the update. The problem is this update turning into an invitation to being micromanaged.

Thanks for this comment. It pretty much confirms my hunch that I would not be happy in a "developer" role. I have done quite a lot work that requires writing code. But often it has been projects with literally months before there has been anything that anyone might call functionality.

Please don't over-index on this comment. It's pretty out of touch with how the majority of the field works.

It's not, though, if you also believe the majority of the field attempts to be "agile", which is far and away the case in 2022.

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...

> ship functionality on the daily

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.

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.

Part of the problem here is broken incentives.

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.

I hope this is comment is made in irony.

There are engineers who can produce on a constance cadence, and there are engineers who need to let the pressure build until a dam breaks and the code comes rushing out. The latter engineers can still be good engineers. It all depends on how your brain works.

The systems supporting shipping daily should exist either way, though.