Hacker News new | past | comments | ask | show | jobs | submit | darylteo's comments login

Agreed. For more detail, I trust Thor@PirateSoftware https://www.youtube.com/watch?v=PTxyu_p1qkc

In this model of "managers know what their reports are doing" how does one gain insight into overall engineering health from a high enough level (say, engineering manager / CTO)

How does a engineering manager know what their managers are up to in order to get an understanding of what their manager's team members are up to? Even worse if you have a large enough organisation where you may have managers managing leads who manage teams?


Mayhaps the CTO would deign to do their work and ask their direct reports about the status, then compile a report with the desired information? The direct reports would obviously ask their reports, and so forth, until you get to the lowest rung on the ladder.


I've been lightly using ollama on the m1 max and 64gb RAM. Not a power user but enough for code completions.


The solution here creates Orders, not Pizzas. Therefore the lifecycle of the delivery is captured by Order itself.


Nope... just Chatt Testaweg


I understood that reference, nice.


I think it was in reference to the "possible tortious interference with Automatticc's contracts" and "We have screenshots and archives of all these tweets including when they were posted" messages in one of the screenshots.

You don't mention "contracts" or that you're putting things "on the record" on a whim.


True.

That's a pretty mild "threat" though.

I would say reminding someone that they might be involved in committing a breach of contract and what the indications of the breach are is reasonable.

Otherwise, nobody could remind anybody to stick to a contract without being accused of threatening behavior.


In this context I would disagree... the "act" in question has allegedly already occurred, as such there is no way for the recipient of a "reminder" to make any changes to avoid a breach.


So if someone punched you, there is no ethical way to tell them that it is not ok and that you have the ability to counter?


... when did ethics come into this?

"I'm warning you"

"Hey! Back off!"

--

My disagreement in the previous comment had nothing to do with the alleged "threat" or the ethics of... it was the idea that it was simply a "reminder".


nothing mild about it


Actually it reads like someone with a tiktok level of legal knowledge trying to substatitate an empty and shallow threat - on a whim.

A proper (legal) threat takes the form of a piece of paper with a letterhead of some person who gets paid $5,000 an hour to make people question their life choices and shit their pants for a living.


Well I guess I should post the obligatory

> Some people, when confronted with a problem, think

> “I know, I’ll use regular expressions.”

> Now they have two problems.


I posit that there are multiple disparate teams involved.

--

Team 1 tells Team 2 that the schema is updating.

Team 2 updates their schema.

Team 2 tests against updated schema (which would be a test file)

All green in test.

Team 1 doesn't actually follow the schema.

Deployment fails.


It’s worse than that. They updated the schema, and tested it with previous data that does not exercise the new parameter. Tests are passing. When they go and actually use the new parameter, it crashes.

The new schema was improperly tested (among a list of other failures).


> When I make a change to some code or config, I'll run it locally to make sure that the change has the effect that I want.

It's not uncommon for devs to be working against outdated databases / config dumps. Certainly bad practice but when devs have the option of being lazy vs doing chores, they will pick the path of less resistance.

> But what I can't understand is that the human who initiated this change decided not to see if it actually did what they wanted it to do.

We're assuming that the person who changed the code also made the choice to initiate the rollout. They are 2 separate actions which can be made by separate individuals and could also involve many multiple steps in between, each undertaken by a separate individual as well.

Distance from Prod does introduce a sense of malaise and complacency, I've found.


The whole thing smells of silo'ed teams syndrome.

Team 1 tells Team 2 that the schema is updating.

Team 2 updates their schema.

Team 2 tests against updated schema

All green in test.

Team 1 doesn't actually follow the schema.

Deployment fails.

---

It's really hard to assign blame, but I'd put more blame on Team 2 for not being defensive with their inputs enough.

As we all know there are greater issues with their deployment pipelines (lack of canaries, phased rollouts etc.) but no point going over those in this context.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: