abcde777666

Whilst I do like having shows and movies on to the side as I code... it's on the condition they're actually interesting and have good writing. Otherwise I just can't bring myself to be interested.

A lot of these types of books and posts only deal with the low hanging fruits of software design difficulty, such as the provided discount service example.

The trouble is that kind of thing's pretty much software development common sense - only the inexperienced don't know it.

The true difficulties of software development are often must gnarlier in my experience.

For instance, making architectural choices for large and dynamic software systems, such as say a cutting edge game engine - that can be really hard to get right, and there's not always a lot of sage advice out there for how to navigate it - and not just for game engines but for any equally or more complex software.

I guess my point being - I'd love to see more effort into addressing the hard design stuff, and less repetition of what's already been established.

Short version: good refactoring = improve maintainability, brevity and usability without compromising functionality.

Basically, make it simpler without breaking it or actually making it not simpler.

There are many pillars of our own intelligence that we tend to gloss over. For instance - awareness and the ability to direct attention. Or something as simple as lifting your hand and moving some fingers at will. Those things impress me far more than the noises we produce with our mouths!

"There is no such thing as death at all for this body. The only death is the end of the illusion, the end of the fear, the end of the knowledge that we have about ourselves and the world around us."

"There is no such thing as permanence at all. Everything is constantly changing. Everything is in flux."

I've found it quite easy to build and deploy to Linux, also curious what challenges you've run into.

My instinct is that this is probably on the naive side. For instance, we use separation of concerns in our systems because we're too cognitively limited to create and manage deeply integrated systems. Nature doesn't have that problem.

For instance, the idea that we can neatly have the emotion system separate from the motor control system. Emotions are a cacophony of chemicals and signals traversing the entire body - they're not an enum of happy/angry/sad - we just interpret them as such. So you probably don't get to isolate them off in a corner.

Basically I think it's very tempting to severely underestimate the complexity of a problem when we're still only in theory land.

Our brain is a face reading machine. We're very attuned to inferring emotion and inner state based on subtle facial movements.

Most of uncanny valley is down to the face moving in a way that sends disturbing emotional signals.

Not too different to how you feel when seeing the weird stare of a Zuckerberg or Elizabeth Holmes for instance.

Body language and movement would be the same, albeit simpler.

Game dev is one of the most unconstrained software domains. On the one hand it's what makes it exciting and endlessly interesting, but it's also what can make it a nightmare. Perhaps most simply because computers are really not up to the task of simulating worlds, and so much hackery and smoke and mirrors are required.

It's easy to make something lean when you can start from scratch. Backwards compatibility and large user bases resistant to change are overlooked as primary causal factors of the modern state of affairs, imo.

Anecdotally, looking at code written by someone else always goes to 'unfamiliar' territory. I can only read code I'm very familiar with like a book.

Another reason this unfortunately wouldn't be viable is latency - a video feed has no client side prediction.

The standards have gone up a lot over time. Your average player now knows who the tops teams are and watches them play. Vastly different from the early 2000s when just knowing to aim at heads set you apart.

Even to be a top 10% player these days you need to either be a veteran or to practice for long hours.

Must be hell for anyone new who wants to try the game!

Feels like one of those 'neat on paper, bad in practice' kinds of ideas. I can imagine it being pretty bad for code readability if not used judiciously, and it adds an extra layer of complexity and troubleshooting when things go wrong.

Maybe I'm just a purist.