The OP built the React Native mobile app - not the entire platform / company. Some folks commenting like they built the company. Just a point of clarification.

Great work! Keep building OP!

The OP title seems a bit misleading notwithstanding this caveat.

I think there's ambiguity. An app built for a platform that does xyz. Does the app do xyz, the platform, or both? If I build an app that takes you straight to idk a Treasury department website, have I built an app for a platform that transacts trillions of dollars?

I thought that at first too, but then I figured it's pretty impressive that the app is processing $6M/month even though the financial platform pre-existed.

It’s the same BS that people have at LinkedIn - leading a $250B initiative or increased revenue by $100B

OpenAI’s executive claiming - made one of the top visited websites :-)

Did you read the article? :)

Uh.... Caught me red handed.

Ok, gonna go read it.

(Hmm. The author says "Follow Scrum, Lean / Kanban, or eXtreme Programming to the letter, and let your team focus on the product."

I disagree - quite vehmently. I guess that's obvious, given that I'm calling out the various capital-A agile methodoliges, and the parasitical industry around them, as harmful/bloated/mostly pointless. But how did you figure out I hadn't read the blog post from that? Now I have, I just think he's wrong).

The author pretty clearly states that Agile works well and we should stick to it without deviating too much with our own processes. Your point was related to the parent post but contradicting the article and didn’t acknowledge the contradiction or why your opinion about Agile might be more correct than the author - that’s basically it.

The industry around it makes total sense - often bloated and misusing terms, but the process itself can work well as a starting point. I get the impression many engineers never attempt it because of bad experiences named Agile sometimes. Understandable of course.

Makes sense, fair enough.

> as a starting point

Even you disagree with the author :) But yeah, a team with the power to change its own processes, rather than have Agile imposed on it, isn't a team that's cargo-culting an Agile Brand).

(Last couple of months I've been introduced to "retrospective story points"; we're supposed to fill in how many points the ticket actually took after we've done it. I haven't yet found the words to express how pointless I think this is).

> as a starting point

That's the thing... Agile processes do position themselves as a starting point, and suggest that once the team understands it by living it (but not sooner!) they might adapt it and customize it.

From The Art of Agile Development, 2nd Edition by James Shore et al. (the most recent eXtreme Programming book, if you will):

> As a result, although it’s tempting to customize your Agile method from the beginning, it’s best to start with a by-the-book approach. The practices that are the least familiar are the ones that are most tempting to cut, but they’re the ones you need most, if you’re really going to be Agile. They’re the ones that involve the biggest change in philosophy.

> Mastering the art of Agile development requires real-world experience using a specific, well-defined Agile method. Start with a by-the-book approach. Put it into practice—the whole thing—and spend several months refining your usage and understanding why it works. Then customize. Choose one of the rough edges, make an educated guess about what happens, and repeat.

From The Scrum Book by Jeff Sutherland et al.:

> It’s important to understand the rules, and it’s even useful to follow them most of the time. But reading the rulebook of chess won’t make you a great chess player. After learning the rules, the player then learns about common strategies for the game; the player may also learn basic techniques at this level. Next is learning how to combine strategies you learn from others while maybe adding some of your own. Ultimately, one can transcend any formalism and proceed from the cues one receives from one’s center, from one’s instinct. [...]

> Some day, long from now, you may even outgrow these patterns as you evolve them and define your own. There are no points for doing Scrum, and these patterns are the gate through which a highly driven team passes on the road to the top echelons of performance.

But have you tried any of that, in a team that has had "follow Agile to the letter" imposed upon it? I'm trying to distinguish between the Manifesto and the Industry here.

DM-first is an extremely frustrating culture. That kind of operation tells me that that folks are too risk averse and political to discuss things openly. Typically this is led by panicky managers that are worried about involving too many people or having to explain things to folks they don’t want to deal with, and it escalates from there and gums up ALL the things. It makes Slack basically useless.

The same people DMing however will also extol the virtues of posting in public and lament why there is not more conversation happening in the open.

Sure, but this ends up poisoning any sort of culture and creating all sorts of in-group nonsense which is almost impossible to undo.

It’d be like using Blind as your company chat - nobody goes on there to say how great their experience has been, and the tone infects everything else.

But maybe I’m just not very fun at parties…

This should be avoided at all costs by creating a culture that is receptive to people’s concerns and doesn’t do stupid things without explanation - but I get how difficult that is in reality and most orgs end up messing this up.

Maybe I'm a bit unfair to you but to me your comment basically reads as wishing employees would be good little cogs in your machinery rather than people. Like making friends is natural human behavior. Forming friend groups is natural human behavior. It's not nice to disrupt this except that of course everyone has to be able to work together when needed.

Making friends is great. Talking about work with friends is good and healthy.

Moving all of your work related chats off-platform so you can “say whatever you want” about work and eventually making it into a defacto team chat is what I’m talking about here. This isn’t chatting with friends, this is creating team divisions and huge gaps in context for the rest of your team. This approach is being a poor colleague in my opinion.

You can do both things - they’re not mutually exclusive.

You can’t do both things. Humans want to engage in certain kinds of conversation that companies try to prevent happening.

Sometimes you just want to vent and call your boss a fuckhead and it only takes one time in a persons life to see HR punishing/firing/admonishing someone for conduct on company communication channels that would have been perfectly fine in any other setting, for that person to never trust in the “company culture”

There is no environment where messy human beings fit into the perfect set of rules and behavior that companies demand

The problem in my opinion is that folks afraid of posting treat chat channels like email and official record instead of a conversation. I like to post ideas, brainstorm, engage if I have a minute to respond to someone with a thought - kinda like being in an office - whereas many others seem to use it to blast out information after a lot of polish and they form a culture of announcements and no engagement, and get stressed whenever someone asks a question or actually replies.

Use tools for what they are good for and create a culture that makes each tool work best for your organization.

> The problem in my opinion is that folks afraid of posting treat chat channels like email and official record instead of a conversation.

They would be right: HR will get access to everything you ever posted in a company chat if they have a reason to check. Some people don’t care, some… do.

Fair point. It’s a record, but should not be treated as formally. Just because you are having a conversation doesn’t mean you have to breach HR guidelines.

My comment was related more to the _overhead_ required before posting. Either way best not post anything that would be an HR issue in any format. (Also your private chats will be available in discovery as well if found out)

Maybe I’m not the best to opine on this as I’ve been wildly successful at building community at companies but I’ve also been burned by this. I suppose I’m privileged enough that I’d like to work somewhere that I can still collaborate with low friction remotely - and if the company doesn’t like it then I’m not a good fit.

It's written communication on company infrastructure, tied to your real identity and org chart, and subject to retention policy.

Yes it absolutely is formal communication. Microsoft makes this painfully clear with how they market teams.

> they form a culture of announcements and no engagement, and get stressed whenever someone asks a question or actually replies.

I agree, but this may mostly be pointing out they are not very good/qualified at whatever they are doing tbh.

I stay buckled and I’m just a “normie” not afraid of flying that understands turbulence doesn’t always happen in a bell curve with some notice. Not sure if that makes you feel any better? :)

Having an understanding of the bell curve of turbulence makes you a bit more advanced than a normie on the aviation knowledge bell curve imo :)

Perhaps this bit is a second cheaper LLM call that ignores your global settings and tries to generate follow-on actions for adoption.

This is an excellent article and source. Thank you.

It’s a mystery to me why companies that know they’re pushing a line of fair use or regulation are suddenly “surprised” when they get sued.

They could’ve asked permission. They could have worked with content providers instead of scraping. But they didn’t - and they knew what could happen.

FA (with fair use boundaries) and FO