Yeah hate to say it but by the time this golden age ends with valve I’ll prob either not be gaming as much anyway or to your point have enough that I won’t really care about the newer games.

I really wanted to like the first one but felt like the puzzles and movement were so tedious.

To be fair I generally play videogames stoned, which generally I always find enjoyable even on cerebral puzzle games like talos principle. in fact, I like being high cuz it makes it harder.

But senuas first game trying to walk around and match the pattern against the environment was absolutely miserable to do high, and I’m pretty sure I wouldn’t have enjoyed it sober either.

I loved the combat, but that was so infrequent it didn’t keep me engaged. Finally after dying and having to restart and do a puzzle section all over again I said fuck it and uninstalled.

deleted by creator

I was expecting something more profound. Isn’t this just the concept of using variables to keep code readable? Not a new concept and likely one most devs learn early on.

Well there’s also just a lot more games now, and even retro games that have been around are competing (I’m playing RE1 for example, bought it recently cuz I’ve never played it before)

So I don’t think it’s intrinsically due to other life costs being high. When you have games like battlebit and palworld and lots of ftp games just saturating the market it’s hard to justify charging so much. People literally don’t have the lifespan to play all the games that exist and will continue to be created over time.

So that you can self host I think

• TDD (red-green-refactor)
• Dependency injection
• Focusing/skipping tests
• Minimize stubbing (only stub when you have to, and stub closest to the edge of the system)
• Use rollback or other data cleanup strategy. Ensure tests don’t leave data leftovers.
• Test the behavior, not the implementation. Don’t stub and spy so much that refractors to the source code with an equivalent implementation break the test or require extensive refractors to pass again.

Gaming journalism is dead tho. This is a good example.

As a full stack I feel capable of serving as an architect on a team. I am not sure if I could feel that way if I only honed in on one area.

So I think at least one full stack (architect) kind of person on a team is certainly beneficial.

As far as an entire team of full stacks? I’m sure that would be effective but it may cost a lot of money to have all that talent, where perhaps some tasks could have been done by a non-FS. Also there is the issue where specialization is needed in a certain area, and FS usually don’t offer that.

So I don’t think it would be a mistake, but it may not be as optimal as having a mixed bag where you have a handful of full stacks and then some dedicated FE and BE folks.

To answer your questions:

Do they work: yes

My experience: I’m biased, but I prefer working with full stacks because they get the “big picture” more often. This does translate to a smoother development flow most of the time.

Team size/xp: yes. I work with 2 other full stacks, and then we have some dedicated data engineers, a dedicated FE, and a dedicated data analyst.

Increase/decrease in quality: almost certainly there is a decrease on the FE side because full stacks are thinking about everything. Oftentimes the FE will get “good enough” and we’ll move on. I’ve seen dedicated FE people put a lot more care and attention than I would. However, for the BE I haven’t noticed any decrease in quality vs a dedicated BE.

Actually to address the FE quality issue we’ve arrived at a process whereby the FS builds the full experience and gets it looking mostly good and completely functional, then we pass it off to our dedicated FE person to polish. The polish involves making things look better, responsive, accessible, and ensure legibility. These are things I could do as a FS, but I prefer to lean on the dedicated FE person so I can move onto other things. It’s a system that works really well tbh because the FE person doesn’t have to start from scratch or think about the programming as much, and the FS can still get the FE development done without time sinking the nitty gritty. It’s a win-win.

Increase/decrease in product cohesion: full stacks intrinsically keep the stack cohesive, and that to me is part of the main benefit (see earlier statement regarding the architect role). This translates to the product as features are developed. Often we get a more maintainable system than if a BE and FE got together to agree on an API interface, both may be making concessions to the other that a full stack could work through in their own head and sort out quickly and more effectively.