The 16 pings a minute. The 6 hours of meetings a day because people aren't getting the information they need organically each day. The "hey, can I call?"'s during what I thought would be my free half hour in the afternoon. This is definitely not what it was like in the office.

Unfortunately, I recognize this doesn't change unless an org goes 100% back onsite.

> The "hey, can I call?"'s during what I thought would be my free half hour in the afternoon.

This happens in the office more. Someone just coming to you with whatever they need in the moment.

> The 6 hours of meetings a day because people aren't getting the information they need organically each day.

That is excessive amount of meetings. But also, that organic getting information was still a meeting, you just did not considered it one.

Why wouldn't it work with 2 or 3 unified days onsite and 2 or 3 days wfh, with a no-meetings, minimal-interruptions directive on wfh days? I think this structure, if well managed, would work even better than the old 5-days-in-office.

I agree that this would work, and be ideal. I think it only scales to a certain size organization though. At my company, I'd guess we have over a thousand developers across hundreds of teams, and more supporting staff. There's no possibility of getting everyone in at once.

The JS examples don't seem too demonstrative to me. Especially for someone not very familiar with RxJS. Any time you're wrapping something with `from` or `of`, I raise an eyebrow

  export function pipeline(in$: Observable<Product>): 
  Observable<string> {
      return in$.pipe(
          mergeMap(product => from(product.Images)),
      );
  }

Why use mergeMap at all here? Why not not just

  return in$.pipe(
    map(product => product.Images),
  );

I get that this is a toy example, not trying to be pedantic.

The former pipeline takes in products, splits the images, and processes each one.

The latter pipeline would releases batches/arrays of images.

This is my question. If your flags are in your repo, what is functionally the difference from just having them be variables in your code somewhere.

"Feature Flags that live inside your code" - That's just variables, no?

Feature flag state is still served dynamically through Flipt. Your code doesn’t have to redeploy for the changes to “become live”. That’s the main benefit.

Means you can experiment and target different cohorts with variants of your app without restarting processes everywhere.

Thank you. I guess I was imagining that the flags lived in your source code repo, and required a commit and push to update, thus triggering some CD build and redeploying your app anyways.

You're not wrong there at all. That is a very reasonable assumption and I think the default behaviour with most early CD pipelines. Every commit leads to a deploy event.

However, this can be changed, so that not all commits/pushes are treated equally during CD. Either by using rules to ignore changes to certain sub-directories / files or through having reproducible builds and skipping the process restarting parts when the resulting artefacts between two commits haven't changed (e.g. the digest of a docker image not changing from one commit to the next).

This is often an optimisation though, and takes time/effort to put in place.

This is peak Hacker News response

If this is downvoted the comment it’s responding to also should be.

I mean really… “have you thought about moving to another country that speaks a different language and is a 20 hour flight from anyone you know?”

I interpreted the parent comment in the inverse. A poor economy means people will stay in unhappy situations longer than otherwise.

I've always been unsure where this stuff fits in. Do you make it before your system is built, when its unclear how where all the cards will fall? Or after your system is made and in production and all the warts of reality are present and your graph is not so nice and neat anymore. This seems like an architects picture of things. Close enough to give people the false confidence to think they understand things, but not close enough to be of use to anyone actually working in the salt mines.

This is the second comment I've seen in this thread comparing "Gitflow" to what was typical in SVN. Having been there when SVN was in vogue, I can assure you that our process looked nothing like Gitflow. SVN encourages what we now refer to as "trunk based development". The default branch was even called "trunk".

I was used to SVN too, and you’re right about the trunk bit. I’m mainly talking about SVN’s nicely linear revision numbers and how it was unambiguous that r23 came after r22. That’s the part that GitFlow adherents wanted to simulate.

My experience was that older VCS's (SVN in my case) leaned in heavily to the trunk based paradigm. I don't know what you're talking about with prod branches. The default branch in SVN was called - trunk.

I think that's what they're saying. People think that when they switch to git they have to use prod and other, newer workflows. But you can keep doing the same thing you did in SVN, using trunk primarily in git, with easier merges.

This one blog post resulted in so much pain for so many. I'm glad it has been addended, but the damage was done.

For the record, I don't think it's the authors fault.

doesn't is suffice to say that functions meet all the prerequisites of a vector space?

f + g = g + f

f + (g + h) = (f + g) + h

f + -f = 0

(a * b) * f = a * bf

a (f + g) = af + ag

(a + b) * f = af + bf