Hacker Newsnew | past | comments | ask | show | jobs | submit | tony's commentslogin

Location: RGV, TX, USA (US citizen) Remote: Yes

Willing to relocate: No

Technologies: Python, TypeScript, React, AWS, Sentry, Terraform, GraphQL, Flask, Django, py.test, ruff, uv, biome, vite, vitest, asyncio

Résumé/CV: https://tony.cv (PDF: https://tony.cv/cv.pdf)

Email: tony [at] git-pull [dot] com

Hi, I'm Tony — a senior software engineer (2× YC companies, 2 acquihires).

I'm the open-source author of `tmuxp` and `libtmux`, both packaged across major Linux distros, FreeBSD, and Homebrew.

I work well on teams of any size and prefer startups using Python.

Available for roles aligned to U.S. or E.U. time zones.


Location: RGV, TX, USA (US citizen)

Remote: Yes

Willing to relocate: No

Technologies: Python, TypeScript, React, AWS, Sentry, Terraform, GraphQL, Flask, Django, py.test, ruff, uv, biome, vite, vitest, asyncio

Résumé/CV: https://tony.cv (PDF: https://tony.cv/cv.pdf)

Email: tony [at] git-pull [dot] com

Hi, I'm Tony — a senior software engineer (2× YC companies, 2 acquihires).

I'm the open-source author of `tmuxp` and `libtmux`, both packaged across major Linux distros, FreeBSD, and Homebrew.

I work well on teams of any size and prefer startups using Python.

Available for roles aligned to U.S. or E.U. time zones.


Location: RGV, TX, USA (US citizen)

Remote: Yes

Willing to relocate: No

Technologies: Python, TypeScript, React, AWS, Datadog, Sentry, LLMs (ChatGPT/Claude/Gemini)

Résumé/CV: https://tony.cv (PDF: https://tony.cv/cv.pdf)

Email: tony [at] git-pull [dot] com

Senior+ engineer — 2× YC, 2 acquihires. OSS maintainer of tmuxp/libtmux (packaged in major Linux distros, FreeBSD, Homebrew). Interested in AI/product work.


Location: RGV, Texas, USA (US Citizen)

Remote: Yes

Willing to Relocate: No

Technologies: Python, TypeScript, AWS, Datadog, Sentry, React, AI LLMs (ChatGPT, Claude, Gemini)

Résumé/CV: https://tony.cv, https://tony.cv/cv.pdf

Email: tony [at] git-pull [dot] com

Interested in AI oppurtunities, shoot me an email and let's say hi! Mission-oriented, senior+ software engineer. Veteran of 2 YC startups, 2 acquihires.

I've contributed to over 100 open source projects. Find my packages tmuxp and libtmux in major Linux distros, FreeBSD, and brew.


Chris Lattner also has a very good episode on Lex Fridman (Episode 381, June 2nd, 2023):

- https://www.youtube.com/watch?v=pdJQ8iVTwj8

- https://open.spotify.com/episode/6flH0XxwdIbayoXTHOgAfI

- https://podcasts.apple.com/us/podcast/381-chris-lattner-futu...

He has two other episodes on the show:

- https://www.youtube.com/watch?v=nWTvXbQHwWs (Episode 131, October 18th, 2020)

- https://www.youtube.com/watch?v=yCd3CzGSte8 (Episode 21, May 13th, 2019)


Location: RGV, Texas, USA (US Citizen)

Remote: Yes

Willing to Relocate: No

Technologies: Python, TypeScript, Any

Résumé/CV: https://tony.cv

Email: <hn_username> @ git-pull.com

Mission-oriented, accomplished software engineer. Veteran of 2 YC startups, 2 acquihires.

I've contributed to over 100 open source projects. Find my software packaged in major Linux distros, FreeBSD, and brew.


Look, at the end of the day, folks might initially give a `.so` or `.sh` the side-eye, questioning its credibility. But if you nail your branding and put real effort into building your reputation, that perception quickly fades away. Once people trust you and your offering, nobody’s going to care about the TLD - just look at Notion.so: everyone links to them, uses them internally, and doesn't bat an eye. In fact, they eventually upgraded to .com - so that door always remains open.

Remember, with any new domain, you're starting from zero anyway; you'll have to build trust from scratch, whether it's a fancy `.com` or a `.so`. Going with something like `.so` or `.sh` just means more choices when the usual suspects are already taken.


Keep files <1000 lines. If you can.

Keep chats <30 minutes, ideally 20-minute continuous segments.

Use a `notes/TODO.md` file to main a checklist of objectives between chats. You can have claude update it.

Commit to version control often, for code you supervised that _does_ look good. Squash later.

This glitch often begins to happen around the time you'd be seeing "Start a new chat for better results - New chat" on the bottom right.

If you don't supervise, you will get snagged, and if you miss it and continue, it'll continue writing code under the assumption the deletion was fine: potentially losing the very coverage you'd hope to have gained.

If it does happen, try to scroll up to the chat before it happened and "Restore checkpoint"

claude-3.7-sonnet-thinking, Cursor 1.96.2


A small note: 1.96.2 is the VSCode version, the Cursor version latest i think is 0.46.x.

I'll also say that "Restore checkpoint" often causes crashes or inconsistency in the indexed files. I've found using git and explicit full reindexing has solved more problems than the AI itself.


Nice tips! I'm working on a Cursor extension to automate checklist and project spec maintenance.

It improves the context that Cursor has and reduces hallucinations significantly. It's early, but 400 users say it's a lifesaver.

Shoot me an email? hi [at] nmn.gl or cal.com/namanyayg/giga


What if..

..I just code it myself?


You can.

...or you can tell the LLM "write me a go application that adds links from this JSON dump of wallabag.it to raindrop.io" and it's done in 10 minutes.

(It did use the wrong API for checking if a link already exists, that was an additional 5 minutes)

I've been doing this shit for a LONG time and it'd take me a way longer than 10 minutes to dig through the API docs and write the boilerplate required to poke the API with something relevant.

No, you can't have it solve the Florbargh Problem, but for 100% unoriginal boilerplate API glue it's a fantastic time saver.


How do you deal with LLM hallucinating api parameter or endpoints or using imaginary library?


You notice it and tell it what to use instead


Then I write it myself or tell it to correct itself. They tend to be confidently incorrect in many cases, but especially with the online ones you can tell them that "this bit is bullshit" and they'll try again with a different lib.

Works for common stuff, not so much for highly specialised things. An LLM can't know something it hasn't been "taught".


> Keep files <1000 lines. If you can.

> Keep chats <30 minutes, ideally 20-minute continuous segments.

> ...

Is it just me or does this sound like a standard coding/mentoring practice?


   Location: Rio Grande Valley, TX
   Remote: Yes
   Willing to relocate: No
   Technologies: Python and TypeScript
   Résumé/CV: https://tony.cv
   Email: <hn_username> at git-pull.com
Experienced IC (Python backend/TypeScript frontend). Active open source contributor—always happy to network over coffee.


Good article. This was 2015 (!)

A few years later, I released The Tao of tmux, available for free online: https://leanpub.com/the-tao-of-tmux/read.

Random: this is a lean, cross-platform program I've used in the status line for ages: https://github.com/thewtex/tmux-mem-cpu-load

tmux has been getting steady updates throughout the years: https://github.com/tmux/tmux/blob/master/CHANGES.

It's nice to see a program that does one thing well and gets such quality attention.


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

Search: