Hacker News Reader

Comment by twawaaay | Hacker News Reader

> Asynchronous first

Umm... as an engineer I know the ins and outs of async.

The fact is that synchronous is so much more efficient when it is practical.

You can exchange mails with the other person for 3 weeks to get details of something nailed or get the meeting room with a whiteboard for 2 hours and get out with the complete solution without wasting time typing all those emails.

Asynchronous is for when you can't get that other person/persons in the room and expect to get the thing done in reasonable time.

There is a reason why you don't do standups asynchronously.

View on HN

Get me in a whiteboard session, and you get responses that I've spent 15 seconds tops thinking about. Send me an email and you'll get responses that I've spent an hour or two thinking about.

There'll also be a written record of the exchange for future reference. The time spent writing the email isn't wasted. It's time saved putting together documentation.

I think the huge gap between the parent and grandparent shows that async vs. sync optimality is heavily dependent on the work being done, the people doing it, and the team/company where it's being done.

An example on the async side... I worked with a couple of fantastic engineers who would come back with amazing solutions if you let them go away and think about it in depth. That worked particularly well for problems which one person could get their head around with deep focus. If you asked those two for a solution in a meeting or at a whiteboard they'd literally say "I won't answer you in real time." I've seen a lot of solid foundational infrastructure created this way.

On the sync side, I worked on a team that needed relatively senior software engineering knowledge (e.g., stream processing of many MBs/second of data before their were decent open source solutions) and PhD+ level math knowledge. The most valuable tradeoffs tended to be across the software engineering / math boundary (e.g., we could use much simpler math if we could process the data faster or process much less data if the math were a little more sophisticated). But it's very rare to find people who are experts at both. Put experts from each side who are good at interactive communication at a whiteboard and tons of value pours out in an hour or two as they leverage each other's knowledge. I saw one such discussion lead directly to 3,500 LOC in one subsystem being replaced with 500 lines of much simpler code and the math being reduced from graduate level to undergraduate level at the same time.

Or do both:

- have a meeting where you discuss and build a shared intuition for the problem

- tomorrow (or next week or…), have a meeting where you solve the problem

This is closer to what large data processing does:

Synchronize the data, distribute tasks to work, synchronize and compile the results.

Curious to hear more about the team/problem. (I’m a mathematician in the middle of trying to convince companies that I’m useful)

On the off chance you see this... I don't want to get too close to describing things as I'm trying to keep this account relatively anonymous so I feel more comfortable being very honest about things. That being said...

The problem was analogous to pricing at Uber or Lyft. The product was very different - not related to transportation in any way. But trying to balance supply and demand through pricing. Supply and demand could vary wildly by the minute and pricing was per customer, so that involved adjusting ~1M prices dozens of times per day. We used control theory, game theory, time series predictions, and lots of other things to understand / control the dynamics of the market and the competition within subsets of the market. I'm convinced the onset of the pandemic would have crushed the company's revenue if this dynamic pricing was not in place. Instead, we merely needed to add some new boundaries to contain what the system was doing (boundaries that were unheard of pre-pandemic like entire sectors of the world economy closing down).

As a software engineer with a BS in Math, I did the first version of this out of intuition without knowing anything about the fields I mentioned above. I was accidentally trying to reinvent control theory without knowing it existed (knowing to do a web search for "control theory" would have helped a lot!).

As time went by and we hired some people with more applicable math knowledge, they were some combination of impressed and amused at what I'd done. And they were able to take it to the next level. Seeing this, and having become the team's manager, I started to hire people with much more advanced math and stats knowledge. Advanced stats people came last and they should have been earlier. It turned out we had shipped multiple experiments that we shouldn't have because we didn't understand that we weren't measuring what we thought we were. As the system got better and better, measuring the impact of our system on indirect market effects became the hardest part of the problem. For example, a change will favor some competitors in the market - is that positive overall? If you think there's a simple-ish answer to that question (like I did at one point), you probably aren't qualified to design / analyze these experiments. wink

Where this eventually led, before I moved on, was the realization that we didn't just need a software architecture, but also a math architecture that helped keep the mathematical dynamics sane and possible to reason about. And it required a lot of effort to help the non-math people in senior management understand this wasn't black magic, but something that needed to be reasoned through by people who understood mathematical rigor (i.e., we needed to continue hiring mathematicians). That's a tough sell given that it's really hard to understand the value of mathematical rigor when you don't have it yourself. We weren't formally proving anything, but when things get complicated, it's really important to understand exactly what assumptions are necessary and when that gets difficult, it's hard to avoid the need for people who know mathematical rigor.

> Send me an email and you'll get responses that I've spent an hour or two thinking about.

Realistically, quite a lot of emails are ignored until engineer really really need to answer and then he quick writes something hard to interpret.

Synchronous is fantastic when applied appropriately.

The common failing I see isn't with synchronous meetings. It's with arbitrarily scheduled synchronous meetings.

Scheduling a recurring meeting for a team is a fantastic way to communicate to everyone that they should wait for that recurring meeting to communicate with the team.

The least productive points in my career have been characterized by recurring meetings. Once a company gets to the point where recurring meetings drive everything, the meetings themselves become the output for a large number of people. Getting work done is secondary, so long as you have something to talk about in the meetings.

Synchronous communication applied judiciously on an as-needed basis is very effective, though. It just shouldn't be the first tool that everyone reaches for for simple problems, nor should it be forced into recurring schedules for the sake of filling up calendars.

My experience is that people are very good at identifying meetings that could have been emails and terrible at identifying month long email threads that could have been a 30 minute meeting.

I push for async stand ups because they’re just such a waste of time. Look at the frigging board if you want to know what’s going on. Blockers should be brought up as soon as they occur.

Depends on how long your standups are and how disciplined the team is. I try to keep standups under 5 minutes after which most people can get back to whatever they are doing.

The goal is to increase return on investment by reducing the investment while preserving most of the return.

It requires that people are able to show on time, though.

What kind of useful team conversation is taking place in under five minutes?

Not a conversation. There is an information exchange that may also lead to a conversation. If this is the case, the conversation happens after standup proper.

The usefulness of people telling what they will be doing or what problems they are facing at the moment is that they might not know there is somebody else in the team that can help them solve this problem very quickly. Or sometimes people find they are working on same or similar thing.

I also like to think it puts a little bit of pressure on people to get something done so they can show some progress on the next standup.

> he usefulness of people telling what they will be doing or what problems they are facing at the moment is that they might not know there is somebody else in the team that can help them solve this problem very quickly.

I have worked on teams of chickens running around with their heads cut off before. While that is one way to try and rein them in, would you not be better served by moving away from making and instead towards engineering?

> I also like to think it puts a little bit of pressure on people to get something done so they can show some progress on the next standup.

From experience, initially it does. But soon you realize that when you're racing the clock you end up taking shortcuts (introducing bugs, making poor design decisions, not properly documenting your work, etc.) that will harm you and your team later.

Appearances aren't worth sacrificing the company over. It is far better to be seen as a poor employee than to be seen as the superhero of a failed business.

>happens after standup proper

This comment will get flagged and deleted shortly. However. Have you considered not using pretentious “grammar”.

The “puts pressure on people” piece is a huge alarm bell of poor people skills.

I’d quit shortly after interacting with you… proper.

Not sure what your beef is.

A month ago I signed up for a marathon that is in the fall. I then told my family, friends and coworkers. This puts a bit of pressure on me to get results. I did not strictly have to do this but, in my experience ,it makes it more likely I will complete my training.

See, most people need a little pressure to be successful because we are naturally lazy. And yes, this includes me.

If you want to work in an environment that puts absolutely no pressure on you, sure, do your own thing. There are places where nobody cares for results.

But ask anybody who knows anything and they will tell you these are not good places for people who want to be successful.

Some pressure and some stress are beneficial. They push as past our own expectations. They make focusing easier, because we have to.

Too little, or too much, of either is the problem to avoid.

None of what you said made any sense. “Reducing the investment” in what. “Preserving the return” of what.

Reducing the time of standups, while maintaining what is useful about them.

> async stand ups because they’re just such a waste of time

But bosses love them as a submission/compliance ritual, a surveillance practice, and another flavor of presenteeism.

And I don't mind them as it is an officially blessed "we don't need you to work right now" period, giving me some time to work on personal projects while others drone on about nothing.

Which, indeed, is another reason why bosses love them. With less time working, more workers are needed to get an equivalent amount of work done, increasing the headcount under their watch. As a boss' worth is measured by how many people he leads, it is in his best interest to waste as much time as he can without losing his own job.

> There is a reason why you don't do standups asynchronously.

There are plenty of teams that do standups async. I dont need to know what everyone else is working on on a daily basis. Not to mention a 15 min recurring meeting to start the day is soul sucking, especially when you hear the words ‘I have a blocker’ and it becomes a 30 min meeting

We’ve been doing async standups and it’s been fine. The thing that really requires synchrony is if there’s a blocker which we deal with as they occur on an ad-hoc basis.

The important thing about stand-ups is that you are standing up, and not comfortable in your chair. They should probably be renamed to stand on one foots to emphasize that the point is to get them over with so you can get back to work.

Thats all fine and good, but the context needs to be communicated async first.

This allows everyone to investigate, think, prepare questions and organize ideas/approaches.

Without that sync time is wasted explaining the basic premise

Reply on news.ycombinator.com