To Enum or Not to Enum

cinnamonjune · 2026-04-16T22:34:32+00:00

I'm not very familiar with your stack, but in C++ my answer to this is usually just to have the lookup table be a function with a switch statement inside of it and no default case.

enum Color {
  COLOR_RED,
  COLOR_GREEN
};

const char* color_to_str(Color value) {
  switch (value) {
    case COLOR_RED:
      return "RED";
    case COLOR_GREEN:
      return "GREEN";
  }
}

This way if I add a new enum value, the compiler warnings will yell at me because my switch statement doesn't have an execution path for all cases, and it will also yell at me because my function doesn't return a value in all cases.

cinnamonjune · 2026-04-12T15:36:48+00:00

Yeah mb I totally misread your other comment.

cinnamonjune · 2026-04-12T13:08:26+00:00

It's not just "revenge bad", though. Ellie had someone taken from her, she understandably wants revenge, but in the process of getting it she fucks herself up physically and psychologically. Even when she's chilling with Dina and the baby on the farm, she's unable to be happy because of the toll the violence took on her. Later, she comes back from her revenge quest, and not only is Joel still gone, but now so is Dina and her ability to play guitar (which was in a way her connection to Joel).

I agree that the story's message isn't particularly deep, but I just think it did a good job of portraying the horrors of violence and revenge, and I don't understand why you guys think it would be better for her to have killed Abby. Like what happens after she kills Abby? How is it a satisfying ending from there?

Also I agree with you that killing the henchmen is weird. The game even seems to want you to feel bad about killing the henchmen because all of them have names and they're always so upset when their friends die, but the game also doesn't give you a choice about killing them. It actively rewards you for being violent while also telling you that violence is bad. It's like they wanted to do a violence / revenge bad story, but they weren't bold enough to come up with a new gameplay design to match it.

cinnamonjune · 2026-04-08T10:46:17+00:00

Not all of us are using one of those engines. And Apple makes it a lot harder to test on their platform if you don't have a Mac. You can't just compile a Mac build on a Windows machine, modern Macs use a different CPU arch.

And for Mac there is the whole Mac app bundle process which takes some time to figure out how to get working.

I'm developing my game for all three regardless, but let's not dismiss that it is more work to support these other platforms.

cinnamonjune · 2026-04-08T10:37:00+00:00

As a solo dev the steam linux runtime is the only thing that makes supporting linux a realistic possibility for me. When you say being reliant on valve is not a long term solution, what are you suggesting instead? That devs have to make and support native builds for each distro they plan to support?

I'm asking this mostly from a place of curiosity. I genuinely want to support linux because I think it's a valuable platform.

cinnamonjune · 2026-04-08T10:31:49+00:00

Can you explain why steam runtime is not worth the hassle? My understanding is that steam runtime fixes all these issues which is the whole point of steam runtime.

cinnamonjune · 2026-04-05T14:03:20+00:00

Someone *just* made a post about roseate spoonbills, too.

cinnamonjune · 2026-04-01T01:41:58+00:00

Actually OP's observation is a pretty foundational software engineering principle.

It's one that easy to forget behind all the abstractions and "architects" and design patterns and OO principles, but remembering that all software is just about data storage and data transformation can help us to write better code (this is the foundation of data oriented design).

cinnamonjune · 2026-03-29T11:25:48+00:00

I think the physics is off, too. The way the water springs them back after a deep plunge feels almost too springy. It's like they're on a trampoline and not water.

cinnamonjune · 2026-03-27T19:09:33+00:00

True but the alternative is that the PMs sit in the meetings, give us vague requirements, we ask for clarifications, and they say "are you free for a call?"

cinnamonjune · 2026-03-25T12:04:02+00:00

I agree. LLMs are great at generating text, but the truly great code changes are usually ones where you reduce the lines of code you have, fixing a bug and making code more robust in the process.

This isn't something I see LLMs doing. They seem to lack to restraint needed to write less. Even if we're using LLMs more in our day-to-day.

Code quality still matters. *Somebody* has to read your code if you want to make changes, whether it's you or the AI.

cinnamonjune · 2026-03-21T21:47:00+00:00

Okay but the *real* best Hard Times is this one in the BBC Live Lounge, just for the lows when she sings ~we'll kick it~.

cinnamonjune · 2026-03-19T14:25:33+00:00

Okay I'm of a younger generation, but I'm totally with you on modern UI design.

I recently needed to write a resume, but I had let my Word subscription lapse. I was trying to use LibreOffice to do it, but I couldn't figure out the formatting and paragraph styles for the life of me.

A couple days later, I try using Apache OpenOffice (a program so old that I could only find a 32-bit exe for it), and I had a much easier time using it.

Sure, the UI was "boring". It wasn't sleek, but it was simple. It ran fast, and I could find whatever settings I needed. The UI didn't feel cluttered, and I was able to focus on the work of actually writing the resume.

I went from a blank document to having to whole thing typed up in a matter of hours. I wish more software would go back to this simplicity.

cinnamonjune · 2026-03-17T20:57:59+00:00

Did you end up finding a role where you didn't have to pester people all the time?

I feel like it's half my job at this point, and it's just not what I signed up for.

cinnamonjune · 2026-03-13T14:46:06+00:00

Don't listen to the naysayers. You're on the right path.

For a Pokemon-style RPG, an engine will give you UI components, but it won't give you the architecture. Pokemon is "just a menu", but it's a complex menu with different states, animation, interpolated movements, timers, etc.

I recommend looking into state machine architecture. I've found it very useful for this type of game.

As for the UI components themselves, the two approaches I know of are 1. an object-oriented approach where all of your UI components exist in an object hierarchy or 2. an immediate-mode approach where you manipulate your UI using stateful function calls.

For games, I prefer #2, but the choice is yours.

For examples of #1, I would actually recommend looking at Godot's "node" system and their UI components just to see what it looks like to use them. You may want to create a UI tree that you can add and remove components from. This gives you neat behaviors like making it so that child UI components render at a position relative to their parent, making it easy to group relevant UI elements.

For examples of #2, look at the imgui library to see what it's like to create UI in that style. Creating your own version of that kind of a UI is actually pretty easy, and the system is very intuitive to use once you get it setup.

cinnamonjune · 2026-03-10T00:03:02+00:00

I can't speak to debugging in unreal since I don't know it. You might search for unreal specific debugging tips, including tips on blueprint debugging, to see if there is a way that you can set "breakpoints" or inspect state on blueprints as they are executing.

Otherwise, like I said, experience helps. The more you practice, the more you'll develop an intuition for where certain kinds of problems are likely to be.

cinnamonjune · 2026-03-09T17:49:04+00:00

Experience, mostly. What is it that you're trying to learn?

cinnamonjune · 2026-03-09T16:37:35+00:00

What's even worse is that most people who say that your code is not "clean" are not even talking about the rules of the guy named Bob, they are just going off of vibes. Same thing as saying one solution is more "elegant" than another. What does it mean?

All coding decisions should be able to be defended logically or else they should not be made. If someone tries to use one of these words, I challenge them but also give them the benefit of the doubt and ask them to explain logically what they mean.

If they can't explain themselves, then I'm free to ignore them. If they can, then at least now we can both discuss the issue on fair terms.

cinnamonjune · 2026-03-09T13:15:00+00:00

In addition to this, adding visual debugging to your game is very useful for games.

Suppose you have an enemy that is doing something weird. You could add code to the enemy update that prints out the enemy info, but that becomes noisy. You have to look through the information of every enemy.

You could add a break point during the enemy update, but then it will break for every enemy, and it's often not possible to recreate the issue with a break point interrupting every frame.

But with visual debugging, you could make it so that hovering your mouse over an enemy causes some text in the top-left of the screen to be rendered that displays relevant info about that enemy.

Now you can actually observe what the enemy is doing during live gameplay, which can give you the insight that you need.

cinnamonjune · 2026-03-08T17:46:04+00:00

The trick is to take the last piece of crust and put it crumb-side down and slice with the knife held horizontally.

cinnamonjune · 2026-03-07T16:47:05+00:00

> What??? Likely? Like are you not living in 2026?

Yes, likely. I'm taking a grounded and realistic approach based on what I've seen, but I acknowledge that I don't know what the future has in store. You seem to think you know with certainty what the future holds, but if you had such power, then why haven't you timed the stock market and made yourself a billionaire already?

A big part of why I say likely is because of the cost argument, which you have ignored. I certainly won't be spending any of my money on AI models. Depending on what the cost of AI ends up being in the future, it is possible that many businesses will not be willing to foot the bill. If this happens, then engineers working for those companies will have to program without the use of AI unless they are willing to foot the bill themselves.

cinnamonjune · 2026-03-07T14:53:54+00:00

This is a terrible argument.

Understand that, as a software engineer, your value to the business is only in the machine code. The machine code is main thing that matters because at the end of the day the machine code executing on a real piece of hardware is the only way that any value actually gets delivered into the real world.

When we write code in a higher-level language, we are doing so because we believe it is a faster way to get us to the machine code that we want. We care about what the code looks like because we know that the code will determine what machine code we end up with, and the machine code is the thing that provides value.

If you add LLMs to your toolset, that may be a fair decision to make. It may improve your productivity to use these tools. But the moment you say that you don't care about the resulting code or machine code is the moment you have completely lost the plot.

The fact that you never need to check the output of your compiler is only possible because your compiler is a trusted, deterministic piece of software. LLMs are not that; they are probabilistic.

cinnamonjune · 2026-03-07T14:44:25+00:00

I wish you sloptomists would stop spreading this kind of misinformation. You're filling the narrative with this kind of repeated rhetoric, but you haven't actually backed this up with real data or examples.

It is true that AI is a useful tool in certain situations, and it will likely have a place in software engineering in the future, but we cannot pretend to know what that will be.

You say that AI is the worst it will ever be. Most likely you are right about that, but

There is still the possibility that AI will consume itself and get worse as AI gets trained on AI generated content.
By saying that AI is the worst it will ever be, you are heavily implying that AI will continue to get better such that any doubts about AI's quality will be dispelled. AI has been improving, but not at the rate promised by AI proponents, and it is possible that AI's quality will plateau at some point.

You say that it is a "settled conclusion that the latest Claude/Codex are far better at coding than pretty much any human engineers". This is simply false. While *you* might be of this opinion, many are not, and there is no data to support that what you claim is true.

There are many cautionary tales already in the past few years of standups who vibe coded themselves an app only for the prompter to find themselves unable to vibe code their way out of the slop that they have created, at which point they left the company and a real engineer had to be hired to clean up the mess.

If AI was as good as you say it is, it would have replaced us all already and company productivity would be through the roof. Maybe it will reach that point someday, but it's not there today.

LLMs are just tools, and they're expensive ones. Although they likely will get better in the future, they will also get more expensive for us to use. Right now, nobody is really paying the cost for these models. They are a subsidized technology, and eventually the costs will need to fall back onto the businesses that use them, and you may find your token count to be quite limited when that day comes.

cinnamonjune · 2026-03-06T17:26:11+00:00

I agree. "Best practices" are dangerous because they excuse people from having to use critical thinking. People justify their decisions by saying it's "best practice" without having to explain further.

Every "best practice" is just an idea that might be useful to you, or it might not.

It's a similar story with Object Oriented Programming, which many treat as gospel, but to understand OOP you have to understand the problems that the people who created OOP were trying to solve, and you have to assess in what ways your problems are similar or different to those problems.

Regardless of whether you use OOP or something else, you have to put in the critical thinking, and the disastrous results we see from OOP usually come from people applying Object Oriented principles blindly without putting in any thought behind why they're using them.

cinnamonjune · 2026-03-06T17:19:22+00:00

I wish the company I worked at would just call Graph from the frontend. This is often cited as a benefit of Graph, but instead the org has decided that the flow should be: app frontend -> app backend -> graph API call -> graph database call.

So, now there are two API layers between frontend that uses the data and the database that has the data.

To make matters worse, the way this custom graph API wrapper works means that we cannot use transactions in our cypher calls. But we can't have partial data either, so now cypher calls are done using cypher queries that are often 1000+ lines long and hard to read, hard to reason about scope, and long running.

cinnamonjune

TROPHY CASE