2,313 karma · joined January 14, 2013
Ryan Guill
ryanguill+hn at gmail.com
@ryanguill
https://www.linkedin.com/in/ryan-guill-92034a1/Remote: Yes (Only)
Willing to Relocate: No
https://www.linkedin.com/in/ryan-guill-92034a1/
CV: https://ryanguill.com/resume/
I am an experienced, driven, motivated engineer who is looking for high-agency, high-impact problems to solve. Bonus points for roles that are a positive impact on society.
Looking for remote roles in majority remote teams. I'm comfortable in startups and large corporations, I just want to ship fast on things that matter.
Postgres/Snowflake/DuckDB, Typescript, Python, AWS, Docker, LLMs and related tech - but I love learning new languages. I ask a lot of questions, and think in terms of processes and systems. I use and build agents and love a good SQL query.
email: ryanguill+hn@gmail.com
You shouldnt put things in AGENTS.md that it could discover on its own, you shouldnt make it any larger than it has to be, but you should use it to tell it things it couldnt discover on its own, including basically a system prompt of instructions you want it to know about and always follow. You don't really have any other way to do those things besides telling it every time manually.
I don't think im in terrible shape right now, but looking ahead 10 to 20 years, without medical intervention I probably would be.
I believe for some of us its purely genetic.
This is true to an extent for sure and they will go much longer than most engineers without getting "tired", but I've def seen both sonnet and opus give up multiple times. They've updated code to skip tests they couldn't get to pass, given up on bugs they couldn't track down, etc. I literally had it ask "could we work on something else and come back to this"
Buildings with higher people/sqft could already take advantage of indoor co2 scrubbers today.
The hard part is capture and disposal.
Theres a lot of network effects as well. The more people were using it, the more people will use it.
Data should be data, queryable, relational. So often I have had to change enums into lookup tables - or worse, duplicate them into lookup tables - because now we need other information attached to the values. Labels, descriptions, colors, etc.
My biggest recommendation though is that if you have a lookup table like this, make the value you would have made an enum not just unique, but _the primary key_. Now all the places that you would be putting an ID have the value just like they would with an enum, and oftentimes you wont need to join. The FK makes sure its valid. The other information is a join away if you need it.
I do wish though that there were more ways to denote certain tables as configuration data vs domain data, besides naming conventions or schemas.
Edit to add: I will say there is one places where I have begrudgingly used enums and thats where we have used something like prisma to get typescript types from the schema. It is useful to have types generated for these values. Of course you can do your own generation of those values based on data, but there is a fundamental difference there between "schema" and "data".
Did you consider making this a view instead? Just curious if there is a reason why you couldn't.
So if youre building your own agent, this would be a directory of markdown documents with headers that you tell the agent to scan so that its aware of them, and then if it thinks they could be useful it can choose to read all the instructions into its context? Is it any more than that?
I guess I dont understand how this isnt just RAG with an index you make the agent aware of?
Maybe my complaint is that I wish vscode had more features like intellij, or that intellij was the open source baseline a lot of other things could be built on.
Intellij is not without its cruft and problems, dont get me wrong. But its git integration, search, navigation, database tools - I could go on - all of these features are just so much nicer than what vscode offers.
I have no doubt that there are great scientist spending their entire careers trying to improve these rulers and measurements, but I also know that there are great scientists spending their entire careers basing everything on the best rulers they have...
We needed to do something similar one time with 5 large touchscreen tvs that were arranged as a table, where each side needed to be a separate touchscreen application with them all playing a synchronized video in the background but users could interact with things flowing from one end to the other and could send objects from their other apps in any direction to other apps, like users sending things they found to the person on the other side of the table.
We ended up with a trashcan mac pro (thats about all we could find in budget that could drive all the screens at the same time) with apps that were synchronized using redis (I wrote that part). It worked really well, though I didnt get to see the finished product before I left that company. But we always really wanted to have separate computers that were synchronized. We just couldnt get that to be reliable enough - it worked for a while but then various things would throw it out of sync, meaning we would have to restart the applications periodically which wouldnt work.
Something I have always wished we had, since the very early days of PCs was the ability to network devices together in such a way that they could share their resources and collaborate more. Imagine being able to take advantage of all of the computers in an office to do a task like a supercomputer. Of course thats a very hard problem, applications and OSs would need to be designed for it and we would need new algorithms (look how long it took us just to take advantage of multiple processors in the same machine on the same board), but there were some projects out there like seti@home and folding@home that did it somewhat, but I always hoped it would be something that the computers themselves would support.