matthewkayin (u/matthewkayin)

matthewkayin commented on Try and ygdp.yale.edu/phenomena/t... · Posted by u/treetalker

nyeah · 13 days ago

Yeah, maybe it's regional. I hear "tryan get some peace and quiet" about the same as "tryta get some piece and quiet. Maybe the former is more confident. But tone of voice probably matters more than the words.

FWIW I grew up mostly in the Northeast.

matthewkayin · 13 days ago

I'm surprised there was no mention of accent. For their example "It’s tough when you’re trying and finish(ing) an assignment under pressure.", I can't help but hear "It's tough when you're tryna finish an assignment under pressure.", which really is more like "trying to" than "trying and finishing".

matthewkayin commented on Testing a Robust Netcode with Godot studios.ptilouk.net/littl... · Posted by u/smig0

matthewkayin · 2 months ago

I noticed you have your game on Steam. Did you end up using any of the Steam networking features via Steam SDK and Godot Steamworks?

I'm using ENet for my RTS project and found that Steam's networking code offers many of the same features offered by ENet (including the reliable, in-order delivery of packets, which is invaluable for an RTS Game). I was able to abstract things out so that my game uses ENet on LAN games and Steam networking for online games, and the rest of the game code is none the wiser.

matthewkayin commented on In praise of “normal” engineers charity.wtf/2025/06/19/in... · Posted by u/zdw

tikhonj · 2 months ago

> The smallest unit of software ownership and delivery is the engineering team.

I see where this is coming from, but it's also pretty sad. In my experience, it tends to create environments where engineers are second-class citizens compared to managers or product: we're just responsible for "delivery", but can't independently make any real decisions beyond a tiny scope. Our timespan of discretion becomes measured in days or weeks, while, on the best teams I've seen, it's measured in months, quarters or years.

It's counterintuitive, but you absolutely can have real individual owernship for engineers without creating single points of failure or brittle systems. It's a matter of having other sources of slack, encouraging quality work, and giving people a lot of room to fluidly adjust what they're working on when. Folks still have real ownership and can make longer-term decisions on their own, but they also collaborate in ad hoc ways and share tacit knowledge, so that somebody else can jump in, help out or even take over in a pinch. I'm being a bit vague, but all I can say is that I've seen this before, and I'll know it when I see it again.

In practice, the model I saw did end up with more rewriting than a normal team—but we were still way more productive overall, even accounting for the rewrites! Turns out that rewriting systems incrementally, in self-contained chunks, is an amazing way to both evolve the design and to build up instutitional knowledge and capacity. It looks like waste, but it's actually slack that is crucial to making your system as a whole more flexible, adaptable and resilient. (In fact, that's true of a lot of the "waste" top-down management systems try to reduce—I'm incresingly convinced that anybody trying to optimize software team "utilization" is actively sabotaging the work!)

matthewkayin · 2 months ago

I think that rewrites are an important part of how software is written, and it's an important part of being "agile", in the sense that you can go in and write a prototype that's coded very simply without much regard for long-term architecture, knowing that requirements likely will change and that you likely won't get the design right on the first go anyways.

Coding is like writing, in the sense that it's often faster to write a sloppy first draft followed by a better second draft than it is to agonize over getting the first draft right on the first go. The first draft is generative. Its purpose is not to be good but instead to let you get something built quickly and to let you explore the problem, so that you know what edge cases you'll need to account for in your final architecture.

But this still of working will never get through management because the moment you show them a working product, they'll tell you to ship it and won't give you a chance to rewrite.

I think the best way to solve this is to flatten the hierarchy. Get rid of the notion of managers who rule over engineers and give ownership of the code back to the engineers. Have the engineers and product "owners" make decisions together in a democratic fashion.

matthewkayin commented on Now might be the best time to learn software development substack.com/home/post/p-... · Posted by u/nathanfig

endymion-light · 2 months ago

Well my individualized version of google is filled with medium articles and useless bull, i'd pay good money to switch to this magic working search engine

matthewkayin · 2 months ago

If you're serious, I've heard Kagi is an actually good, paid search engine. Haven't tried it myself, though.

matthewkayin commented on First thoughts on o3 pro latent.space/p/o3-pro... · Posted by u/aratahikaru5

atleastoptimal · 2 months ago

This is gonna keep happening with every AI advance until humans are an absolute bottleneck in every domain. May take a bit of time for some professions, but the writing is on the wall. This will be the greatest shift in human history, and I think a lot of people will have trouble grappling with it because its not fun to think about being made irrelevant.

The only thing that will slow AI down is massive universal international regulation. Human intelligence really isn’t the be all end all to intelligence in general, it’s just a stepping stone. I feel many on this site don’t want to accept this because their intelligence has been such a valuable tool and source of personal pride/identity for them for so long.

matthewkayin · 2 months ago

What is all of this for if the result is that human beings are "made irrelevant"? If these LLMs truly become as game changing as so many say they will be, then can we agree that it's time to stop thinking that a person's worth equals their economic output?

matthewkayin commented on Ask HN: Do you still use search engines? · Posted by u/davidkuennen

dowager_dan99 · 5 months ago

but the AI responses from google that dominate the screen real estate are terrible. When you repeat the exact same query and get changing (but all wrong) answers, something is broken. I've resorted to including profanity in all my searches to prevent the AI responses, which is suboptimal at work...

matthewkayin · 5 months ago

If you're using google you can just specify "-ai" at the end of your search, which I've started doing ever since Google's AI tried to tell me that the American Civil War was that time when the North and South fought over gold in California.

DuckDuckGo also has an option where you can turn off the AI search so that you don't have to specify every time. I've found DDG sometimes gives me better results than Google and sometimes doesn't.

matthewkayin commented on I genuinely don't understand why some people are still bullish about LLMs twitter.com/skdh/status/1... · Posted by u/ksec

gilbetron · 5 months ago

I get so confused on this. I play around, test, and mess with LLMs all the time and they are miraculous. Just amazing, doing things we dreamed about for decades. I mean, I can ask for obscure things with subtle nuance where I misspell words and mess up my question and it figures it out. It talks to me like a person. It generates really cool images. It helps me write code. And just tons of other stuff that astounds me.

And people just sit around, unimpressed, and complain that ... what ... it isn't a perfect superintelligence that understands everything perfectly? This is the most amazing technology I've experienced as a 50+ year old nerd that has been sitting deep in tech for basically my whole life. This is the stuff of science fiction, and while there totally are limitations, the speed at which it is progressing is insane. And people are like, "Wah, it can't write code like a Senior engineer with 20 years of experience!"

Crazy.

matthewkayin · 5 months ago

My issue with higher ups pushing LLMs is that what slows me down at work is not having to write the code. I can write the code. If all I had to do was sit down and write code, then I would be incredibly productive because I'm a good programmer.

But instead, my productivity is hampered by issues with org communication, structure, siloed knowledge, lack of documentation, tech debt, and stale repos.

I have for years tried to provide feedback and get leadership to do something about these issues, but they do nothing and instead ask "How have you used AI to improve your productivity?"

matthewkayin commented on My first game with Carimbo, my homemade engine nullonerror.org/2024/10/0... · Posted by u/delduca

samiv · a year ago

To anyone thinking about writing a game engine.

I've been cranking on a 2D engine for over 4 years and have put thousands of hours of work into it.

My summary:

If you want to write a game, just write a game. Don't start with your own engine since this will suck all your time and you'll end up spending 90% on engine and very little getting the game game done. Especially so in the beginning when you have no features and doing anything in the game requires engine work.

If you choose to create your own engine it's a compelling and fantastic domain where problems come in all shapes and sizes and you can and get to work with physics, maths, linear algebra, audio, rendering, graphics APIs, system level programming, most likely native programming AND scripting, game content, technical art etc.

But finally the real work is not the engine but the tooling and the editor around the engine.

If (when) you rely on free assets from (for example opengameart) you can expect no consistency. Not just the art style but just the technical part too, like your models are all inconsistent in shapes and sizes and axis, 2D content such as textures are by default without any meta data etc. So you really need to create a ton of tooling so that you can have sensible workflows and you can extract and consume the usable and interesting parts of any content package easily.

This inevitably leads to the concept of "editor" which easily comes with a ton of work by itself that has nothing to do with game or game engine per se. For example the concept of "Project", windows, resource management, basic editing functionality for creating content, undo/redo/ etc. A lot of this is not really related to the game or the engine in anyway but you really sort of "must have it" if you want to create something that is actually usable.

The feature creep is real! But once you get the over a lot of the boiler plate and you can actually use your own editor to stuff content into your own engine and have it running it's really a nice feeling even if nobody else cares!

On the technical side my advice is really to be able to do first principles type of thinking. It's of utmost importance to be able to break things apart into self contained features and pieces that the game can then combine to create bigger constructs.

If you can have your materials scroll textures vertically, when you combine that with shapes that are layered and place textures onto those shapes that scroll at various multiples of your "characters" speed then you've just created "parallax scrolling" essentially.

-----

https://github.com/ensisoft/detonator

matthewkayin · a year ago

I often hear the advice to "make games, not game engines", and it's refreshing to hear it from someone who is actually working on an engine themselves, because usually when I hear this advice it's from devs who use Unity/Godot/Unreal, and the implication I get is that if you're not using one of those engines, you're wasting your time and won't ever make a game.

But I'd say there's a middle ground between using an existing engine and making your own general-purpose engine from scratch. I've been making a 2D RTS using C++/SDL, and it's taken me longer to write it this way than if I had used an existing engine, but in only a few months I've reached the point where I have a prototype and have had multiple playtests and am iterating the prototype based on feedback from those playtests.

So, while the advice "make games, not game engines" is still definitely true, it doesn't mean that if you code "from scratch" that your game will necessarily be a long 4-year engine project (unless you want it to be!). The trick is to keep the code specific to the game you're working on and to avoid the urge to abstract everything / make everything general-purpose.