frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

LegalArgumentException: From Courtrooms to Clojure – Sen [video]

https://www.youtube.com/watch?v=cmMQbsOTX-o
1•adityaathalye•1m ago•0 comments

US moves to deport 5-year-old detained in Minnesota

https://www.reuters.com/legal/government/us-moves-deport-5-year-old-detained-minnesota-2026-02-06/
1•petethomas•4m ago•0 comments

If you lose your passport in Austria, head for McDonald's Golden Arches

https://www.cbsnews.com/news/us-embassy-mcdonalds-restaurants-austria-hotline-americans-consular-...
1•thunderbong•9m ago•0 comments

Show HN: Mermaid Formatter – CLI and library to auto-format Mermaid diagrams

https://github.com/chenyanchen/mermaid-formatter
1•astm•24m ago•0 comments

RFCs vs. READMEs: The Evolution of Protocols

https://h3manth.com/scribe/rfcs-vs-readmes/
2•init0•31m ago•1 comments

Kanchipuram Saris and Thinking Machines

https://altermag.com/articles/kanchipuram-saris-and-thinking-machines
1•trojanalert•31m ago•0 comments

Chinese chemical supplier causes global baby formula recall

https://www.reuters.com/business/healthcare-pharmaceuticals/nestle-widens-french-infant-formula-r...
1•fkdk•34m ago•0 comments

I've used AI to write 100% of my code for a year as an engineer

https://old.reddit.com/r/ClaudeCode/comments/1qxvobt/ive_used_ai_to_write_100_of_my_code_for_1_ye...
1•ukuina•36m ago•1 comments

Looking for 4 Autistic Co-Founders for AI Startup (Equity-Based)

1•au-ai-aisl•46m ago•1 comments

AI-native capabilities, a new API Catalog, and updated plans and pricing

https://blog.postman.com/new-capabilities-march-2026/
1•thunderbong•47m ago•0 comments

What changed in tech from 2010 to 2020?

https://www.tedsanders.com/what-changed-in-tech-from-2010-to-2020/
2•endorphine•52m ago•0 comments

From Human Ergonomics to Agent Ergonomics

https://wesmckinney.com/blog/agent-ergonomics/
1•Anon84•55m ago•0 comments

Advanced Inertial Reference Sphere

https://en.wikipedia.org/wiki/Advanced_Inertial_Reference_Sphere
1•cyanf•57m ago•0 comments

Toyota Developing a Console-Grade, Open-Source Game Engine with Flutter and Dart

https://www.phoronix.com/news/Fluorite-Toyota-Game-Engine
1•computer23•59m ago•0 comments

Typing for Love or Money: The Hidden Labor Behind Modern Literary Masterpieces

https://publicdomainreview.org/essay/typing-for-love-or-money/
1•prismatic•1h ago•0 comments

Show HN: A longitudinal health record built from fragmented medical data

https://myaether.live
1•takmak007•1h ago•0 comments

CoreWeave's $30B Bet on GPU Market Infrastructure

https://davefriedman.substack.com/p/coreweaves-30-billion-bet-on-gpu
1•gmays•1h ago•0 comments

Creating and Hosting a Static Website on Cloudflare for Free

https://benjaminsmallwood.com/blog/creating-and-hosting-a-static-website-on-cloudflare-for-free/
1•bensmallwood•1h ago•1 comments

"The Stanford scam proves America is becoming a nation of grifters"

https://www.thetimes.com/us/news-today/article/students-stanford-grifters-ivy-league-w2g5z768z
4•cwwc•1h ago•0 comments

Elon Musk on Space GPUs, AI, Optimus, and His Manufacturing Method

https://cheekypint.substack.com/p/elon-musk-on-space-gpus-ai-optimus
2•simonebrunozzi•1h ago•0 comments

X (Twitter) is back with a new X API Pay-Per-Use model

https://developer.x.com/
3•eeko_systems•1h ago•0 comments

Zlob.h 100% POSIX and glibc compatible globbing lib that is faste and better

https://github.com/dmtrKovalenko/zlob
3•neogoose•1h ago•1 comments

Show HN: Deterministic signal triangulation using a fixed .72% variance constant

https://github.com/mabrucker85-prog/Project_Lance_Core
2•mav5431•1h ago•1 comments

Scientists Discover Levitating Time Crystals You Can Hold, Defy Newton’s 3rd Law

https://phys.org/news/2026-02-scientists-levitating-crystals.html
3•sizzle•1h ago•0 comments

When Michelangelo Met Titian

https://www.wsj.com/arts-culture/books/michelangelo-titian-review-the-renaissances-odd-couple-e34...
1•keiferski•1h ago•0 comments

Solving NYT Pips with DLX

https://github.com/DonoG/NYTPips4Processing
1•impossiblecode•1h ago•1 comments

Baldur's Gate to be turned into TV series – without the game's developers

https://www.bbc.com/news/articles/c24g457y534o
3•vunderba•1h ago•0 comments

Interview with 'Just use a VPS' bro (OpenClaw version) [video]

https://www.youtube.com/watch?v=40SnEd1RWUU
2•dangtony98•1h ago•0 comments

EchoJEPA: Latent Predictive Foundation Model for Echocardiography

https://github.com/bowang-lab/EchoJEPA
1•euvin•1h ago•0 comments

Disablling Go Telemetry

https://go.dev/doc/telemetry
2•1vuio0pswjnm7•2h ago•0 comments
Open in hackernews

Ask HN: Do you think switching between apps hurts your productivity?

7•PaulShin•7mo ago
Founder here currently building a product to address a problem I’ve seen repeatedly in modern teams.

We use Slack to talk. Notion to document. Jira or Asana to plan. But every time a decision is made in chat, someone has to manually copy, summarize, or “translate” it into another system. Context gets lost. Work slows down.

I'm starting to wonder: is it the tools themselves, or the gaps between them, that hurt our productivity the most? I’m not here to pitch anything, just trying to learn from your workflows.

"How do you and your team deal with this?" "Is switching between apps a real friction point for you?" "Have you found any habits or tools that reduce this friction?"

Would love to hear from you.

Comments

fewbenefit•7mo ago
Switching apps isn't the root problem, switching contexts is.

If tools are well-integrated and mentally compartmentalized (e.g., Slack for fast input, Notion for synthesis, Jira for logistics), switching shouldn't feel painful. But when decisions get scattered and nothing enforces consolidation, yeah, it becomes chaos by slow erosion.

Ironically, the more we try to unify everything into one tool, the worse the mental clutter gets. The problem isn't that we have too many tools, it's that we try to make each one do more than it's supposed to.

So, It's not app switching that kills productivity. It's app misusing.

PaulShin•7mo ago
Great point context switching hurts more than app switching when the tools don’t enforce a single source of truth.

Role clarity: Slack = capture, Notion = synthesize, Jira = track.

Reality: Decisions still leak out of channels, tasks lose owners, docs go stale.

Unifying everything in one mega-app can create new clutter, unless the app itself preserves context automatically. That’s the angle we’re exploring: keep roles clear, but let the hand-off happen inside the flow so people don’t have to think about it.

Curious how does your team make sure a Slack decision doesn’t die before it reaches Jira? Any workflow tricks that actually stick?

P.S. We’re prototyping a tool that tries this “context-in one flow” idea (still private beta). If anyone’s curious—or has horror stories about chat→task hand-offs—happy to swap notes. DM or reply here.

sherdil2022•7mo ago
My contrarian view is that if someone wants to get stuff done, they will get it done or find a way to get it done. Or else there will always be one excuse or another. Of course, there might be some legitimate blockers or onorous processes, but you don’t need a reason to do stuff and one can come up with thousands of reasons to not do.
PaulShin•7mo ago
Fair point no tool can manufacture intrinsic motivation. At the same time, even highly motivated people hit friction: digging through chat history, duplicating context, or chasing down “who owns this.”

The goal of what we’re building isn’t to make someone work; it’s to strip away the overhead that slows down people who already want to.

Think of it like version control: Git doesn’t write code for you, but it removes enough coordination pain that good engineers ship more often. We’re aiming for the same effect between conversation and execution—same motivation, less drag.

From our side, the north-star is a radically simple answer: let a single chat thread end all that visible complexity. One place, one flow, nothing to copy or sync. That’s the product we’re building toward.

Curious have you seen lightweight workflows that actually cut this friction without adding new layers?

brudgers•7mo ago
Git was dog fooded by a community of programmers.

Has a user interface only Linux kernel developers could tolerate.

And was written by one programmer in ten days.

It was not a product and in accord with the Unix philosophy, only does one thing.

PaulShin•7mo ago
You've absolutely nailed the history and ethos of Git, and it's a crucial distinction. Thank you for the clarification. You're right, it wasn't a "product" in the modern sense.

My analogy wasn't intended to be about the UI or its 'one thing well' philosophy, but about the category of friction it eliminated.

Before Git, the coordination overhead for code was immense think manual patches and diffs. Git didn't write the code for anyone, but it automated away that specific, painful "collaboration tax," freeing developers to focus on the actual programming.

I see a parallel today, but the "collaboration tax" has moved. It's now the manual, repetitive work of translating team conversations into structured tasks. We believe that specific friction can also be automated away, freeing teams to focus on the actual execution.

So, you've helped me refine the analogy: It's not about building a product like Git, but about tackling a problem in the same way Git did by automating a specific, painful type of coordination overhead.

brudgers•7mo ago
Before Git

SCM was a solved technical problem.

The Linux kernel team used Bitkeeper for Source Code Management.

The problem was Bitkeeper’s license.

Github built a business on top of git by making the existing tool easier to use. They did not build an SCM.

PaulShin•7mo ago
That's an even more precise and insightful framing. You're absolutely right—the catalyst was licensing, and the technical problem of SCM was, in a sense, already "solved." Thank you for sharpening the point further.

You've actually given me the perfect "Part 2" of the analogy "the relationship between Git and GitHub."

Yeah, Git is the powerful, low-level engine. Technically brilliant, but with a notoriously steep learning curve. The real explosion in adoption came when GitHub wrapped it in a user-friendly product with a clear workflow (pull requests, issues, etc.). GitHub didn't reinvent SCM; it reinvented the collaboration workflow on top of it.

That's exactly how we see the problem we're tackling. The "protocols" of modern work already exist: real time chat, task lists, documents. But they exist as separate, low-level primitives, like Git commands. The "collaboration tax" comes from users having to manually act as the interface between them.

Our goal is to be the "GitHub for general collaboration." To take those existing primitives and build a seamless, opinionated workflow on top where the connections are automated. The user shouldn't have to think about the "protocol"; they should just be able to work.

So, your point is well taken and helps clarify our position. We're not trying to build the "Git" (the core primitive). We're trying to build the "GitHub" (the intuitive workflow layer that makes the primitives powerful for everyone).

And that philosophy is baked right into our name. The reason we're called Markhub is because we're building a central "Hub" where every "Mark" a team makes a message, a decision, a task, a document can live together in a single, seamless flow.

brudgers•7mo ago
Of course it does.

There is no silver bullet.

https://en.m.wikipedia.org/wiki/No_Silver_Bullet

But there is Zawiski’s Law.

https://en.m.wikipedia.org/wiki/Jamie_Zawinski#Zawinski's_La...

And the reward for good work is more work.

https://youtube.com/shorts/SUu1R0Sdfy8?si=ZrXy7uYRMV08WNP3

Good luck.

PaulShin•7mo ago
Thanks for the links—Brooks and Zawinski are exactly the guard-rails we keep taped to the monitor.

No Silver Bullet: We’re not chasing a “one tool to rule them all.” The essential complexity—humans aligning on what to do can’t be deleted; we’re only trying to strip away the accidental part (manual copy-pasting).

Zawinski’s Law: Instead of cramming every feature into one bloated app, we’re limiting scope to a single object model:

A message, a task, and a doc are the same object, just rendered in different views.

Chat ≠ Task Manager ≠ Wiki, but they sit on the same data layer, so hand-offs happen automatically rather than by re-typing.

Anything beyond that (CRM, billing, email) stays as integrations no temptation to rebuild an Outlook clone.

So the direction is “context cohesion without feature creep.” If we can kill the copy-paste tax and still keep each tool honest to its purpose, we think that’s the sweet spot.

Curious where you’ve seen this approach succeed or crash and burn in real teams.

brudgers•7mo ago
My advice:

One ring to rule them all is a fiction…

…and did not work out well for anyone anyway.

PaulShin•7mo ago
Haha, wise words indeed. We’re definitely aiming to be the Council of Elrond, not Sauron. The goal is alignment, not domination.
brudgers•7mo ago
The elves left Middle Earth shortly thereafter.
PaulShin•7mo ago
Haha, touché. You're sharp.

But they left some of the palantíri behind for the new age to communicate. We're just trying to build a less treacherous version.

v5v3•7mo ago
>We use Slack to talk. Notion to document. Jira or Asana to plan. But every time a decision is made in chat, someone has to manually copy, summarize, or “translate” it into another system. Context gets lost. Work slows down.

Have you got multiple monitors or ultra wide monitor?

As switching between Apps is much easier if you are only moving your eyes and everything mostly stays where it is.

I have email/slack on one monitor, then main ide on wide monitor taking up 70% width and other things split vertically in remaining 30%.

Same with laptop, went for 16" as again screen size is key for me.

PaulShin•7mo ago
Multiple monitors definitely make window switching easier—totally agree. The snag we keep hitting isn’t the physical hop, but the cognitive hop:

- A decision lives in Slack, - its rationale hides in Notion, - the actual task ends up in Jira.

Even with three screens, someone still has to copy-paste and re-explain. That’s the part we’re trying to erase: let a Slack message turn itself into a task/doc record without leaving the thread.

If that hand-off were automatic, would you still feel the need for so much screen real-estate, or is multi-monitor workflow a must for you regardless?

Side note We’re prototyping this idea right now. If you’re curious and willing to give feedback, drop me a note at (admin@markhub.ink) and I’ll send over a private link.

Appreciate your take!