If his admissions are true. your statement is more misleading than his. He wrote it. AI edited it. Right?

I wonder if under the covers it uses your word choices to infer your Myers-Briggs personality type and you are INTJ so it calls you "The Architect"?? Crazy thought but conceivable...

Possible :) GPT 5.1-thinking, Sonnet 4.5-thinking, and Grok 4.1 don't make up names like that.

“If you want to go fast, go alone; if you want to go far, go together”

This apparently is an old African proverb coopted by the modern managerial class.

For those thinking about this issue, there are tech-specific related arguments similar to and contrary to the above. I heard the phrase from a Microsoft leader in early 2010s:

* "Heroism doesn't scale" (similar)

While I'm not sure it is completely true, there are respects in which it is deeply true (e.g. ops). It's a double-edged sword I think though; if you take the "Heroism doesn't scale" too seriously, you can suffocate out other key success drivers -- vision, innovation, motivation, design clarity/consistency, etc.

There's also (Fred) Brooks's Law (from Mythical Man Month):

* "Adding manpower to a late software project makes it later." (contrary)

I.e. there are limits to how many people "going far, going together" works for fundamental communication/coordination reasons.

P.S. There are also similar debates about optimal authority/responsibility/coordination across various military cultures, e.g. search for "military command".

I agree with your comment that getting feedback is different to making the final decision.

But I'm not sure the real problem fits solely in your two buckets.

I've been in recent situations where there is a less-technical person charged with making the "final decision" and a lot of other senior people in the room who don't all /have/ to agree. But the degree of "why not do it this way?" questioning+discussion will grow with the number of meeting participants (and/or worse, the # of meetings before a decision is made if it is not settled in one meeting and then new stakeholders arrive and have their own thrashing out to do.) And even with one final decider, you can end up a bit still with "Design By Committee" decisions when the final decider goes along with the group consensus or doesn't have a strong point of view on an issue.

Sounds much cooler than what my management likes to call it. RACI or RASCI for every key project.

Perhaps a prior promise to someone else?

Or you know... just the definition of a FIFO Queue. I mean, using a FILO Stack to organize your work would certainly be a choice...

Definitionally if they're "pushing it near the top" they're not only using FIFO, there's a priority ordering involved...

My guess is there's stuff in progress and maybe they need to arrange access to or setup the readers for a tape that old and of potentially unknown format.

Yes it's probably better to finish in progress stuff first.

So much of this is old and potentially delicate and they don't have unlimited space to work in so they'd have to pack up some other in progress digitization project to setup the tape flux digitizer and maybe have to arrange to get the correct one for this type of tape too.

I want MPP HTAP where SQL inserts/COPYs store data in three(!) formats: - row-based (low latency insert, fast row-based indexed query for single-row OLTP) - columnar-based (slow inserts/updates, fast aggregates/projections) - iceberg-columnar-based (better OLAP price/performance and less lockin than native columnar) And for SELECTs the query engine picks which storage engine satisfies the query using some SQL extension like DB2 "WAITFORDATA" or TiDB @@tidb_read_staleness or MemSQL columnstore_latency and/or similar signalling for performance-vs-cost preference.

And a common permissioning/datasharing layer so I can share data to external and internal parties who can in turn bring their own compute to make their own latency choices.

This is a good thing.

We really really Really should Not define as our success function for AI (our future-overlords?) the ability of computers to deceive humans about what they are.

The Turing Test was a clever twist on (avoiding) defining intelligence 80 years ago.

Going forward, valuing it should be discarded post-haste by any serious researcher or engineer or message-board-philosopher, if not for ethical reasons then for not-promoting spam/slop reasons.

Err, the only thing that matters is that you get the other person talking and you listen.

Good point, thanks.

Been there. Two tips:

Set an alarm on your phone for when you should take your meds. Snooze if you must, but don't turn off /accept the alarm until you take them.

Put daily meds in cheap plastic pillbox container labelled Sunday-Saturday (which you refill weekly). The box will help you notice if you skipped a day or can't remember if you took them or not today. Seeing pills not taken from past days also serves to alert you if/that your "remember-to-take-them" system is broken and you need to make conscious adjustmemts to it.