Unity has a store with a ton of useful user made libraries, frameworks and utilities most of which are generally not worth the time spent implementing it yourself when you can get the thing for something like 20 bucks.

Also, for gamedev shops which already have a lot of Unity experience in-house, it’s probably worth it to stay with Unity, though Unity so frequently changes their engine is profound ways, that existing Unity experience is less valuable than otherwise.

That’s mainly it.

Most people don’t actually know what they need until the see it, and the only ones who might are those who already have a process in place (hence know it in detail) and just want it or parts of it automated.

People often do think they know what they want, but it’s a very general and fuzzy view, with little in the way of details and which seldom considers what should happen outside the most thread path of their process (i.e. things like error situations such as “what if somebody enters the wrong data in this form” or after the fact responsibility tracing in the form of usage logs and reports).

It is actually a bit of an art to tease the details of the requirement from the stakeholders in a consistent and thorough way and also spot and get requirements for those “outside the main process path” elements and, frankly, in my career I’ve met very few people - even amongst business analysts - who are actually good at it.

That said, what maybe the main advantage of Agile when done properly (with proper use cases and the actual end users trying the implementation of those requirements out) is exactly that it’s an interactive process to refine the requirements by cycling back and forth between requirements gathering, feature development and result evaluation to fill in missing details and tease out further requirements. IMHO, this is actually were Agile shines the most when compared to Waterfall, but as I said you need to do the requirements gathering and results evaluation parts of Agile (so the parts involving interacting with actual users bot upfront in making use cases and at the end of the cycle in evaluating the fitness for what they need of what was implemented) to get those gains, and most “Agile” teams out there seem to only do the fashionable parts of Agile like the “standup meeting” which aren’t what makes it most valuable as a process.

Well, seniority helps on the deadlines front: you can spot managers trying to force too short deadlines on you a mile away and throw it back at them (“I’m am the specialist, so I’m the one who knows best how long it will take”) and if they just try and impose deadlines you can bluntly state “that isn’t possible” and if they somehow have the authority to push them you make sure everybody (especially other managers, ideally the managers above them) knows that you’ve informed them upfront that such deadlines were impossible so when it inevitably fails, said manager can’t shove the blame your way.

As for obtaining things from other teams, that’s a two part thing:

• First make it painfully obvious in your estimates that a dependency on something from an outside teams exists. When inquired about progress, constantly point out that it will only happen “if that team provides us what we need to progress”. Keep reminding people that those deliverables are a conditional for yours - “they’re late our project is late”.
• Second, start pushing them for delivering to you what you need well before you need it. It’s there, in your planning, so you know you need it and have some idea of when. The bigger the project the earlier you start pestering them. Persist on asking them for it, escalate to upper management if no movement is visible on their side. Make sure the groundwork is set so that if they’re late they get the blame on project deadlines being missed. It depends on the country culture but generally most people aren’t really impeccable professionals at time and priority management (and yeah, that includes managers) and tend to prioritize addressing “what’s burning harder” in their pile, hence why you need to start pestering them early, do it often and with more urgency the closer it gets to the point you need it (to make sure it’s perceive as an urgent need and rises to the top of their priority pile) and make sure the groundwork is set for them to be blame if your own deadline is missed because they were late and, more importantly, that THEY know they will get the blame (this generally at mid/upper manager level), so that from their point of view it’s “burning” (i.e. they’ll suffer if that doesn’t get picked up on time)

Of course, all this requires competent management since they’re the ones supposed to do it and if your managers are trying to impose deadlines on you or using slimy trickery to get people to commit to shorter deadlines, they’re NOT competent managers - that kind of shit invariably yields death marches and bug-riddled results that in the mid and long term end up wasting far more time that it was shave by those shorter deadlines.

Kinda sad that one has to play such games. Welcome to Mankind.

I would describe it as “insufficiently thinking about and researching the problems space”.

From what I’ve seen that’s very common because developers have a tendency to want to be hands-on rather than merely researching, myself include.

Even for the sake of figuring out inconsistent requirements or even just big gaps in the requirements, it’s a good idea to really think about it and cross check things.

Personally, the more I advanced in my career and the more complex and larger problems I had to tackle, the bigger the fraction of preparation time vs the fraction of coding time and I believe most very senior devs have the same experience.

I think you’re confusing doing analysis before coding with doing all analysis before coding.

If you do Agile properly (so including Use Cases with user prioritization and User feedback - so the whole system, not just doing the fashionable bits like stand up meetings and then claiming “we do Agile development”) you do analysis before development as part of evaluating how long it will take to implement the requirements contained in each Use Case. In fact this part of Agile actually pushes people to properly think through the problem - i.e. do the fucking analysis - before they start coding, just in bit-sized easy to endure blocks.

Further, in determining which Use Cases depend on which Use Cases you’re doing a form of overall, system-level analysis.

Also you definitelly need some level of overall upfront analysis no matter what: have a go at developing a mission critical high performance system on top of a gigantic dataset by taking a purist “we only look at uses cases individually and ignore the system-level overview” approach (thus, ignoring the general project technical needs that are derived from the size of the data, data integrity and performance requirements) and let me know how well it goes when half way down the project you figure out your system architecture of a single application instance with a database that can’t handle distributed transactions can’t actually deliver on those requirements.

You can refactor code and low level design in a reasonable amount of time, but refactoring system level design is a whole different story.

Of course, in my experience only a handful of shops out there do proper Agile for large projects: most just do the kiddie version - follow the herd by doing famous “agile practices” without actually understanding the process, how it all fits in it and which business and development environments is it appropriate to use in and which it is not.

I could write a fucking treatise about people thinking they’re “doing Agile” whilst in fact they’re just doing a Theatre Of Agile were all they do is play at it by acting the most famous bits.

IMHO, most people’s time usage perception tends to be heavilly skewed toward weighing higher the time taken in the main task - say, creating the code of a program - rather than the secondary (but, none the less, required before completion) tasks like fixing the code.

Notice how so many coders won’t do the proper level of analysis and preparation before actually starting coding - they want to feel like they’re “doing the work” which for them is the coding part, whilst the analysis doesn’t feel like “doing the work” for a dev, so they prematurelly dive into coding and end up screwed with things like going down a non-viable implementation route or missing in the implementation some important requirement detail with huge implications on the rest that would have been detected during analysis.

(I also think that’s the reason why even without AI people will do stupid “time savers” in the main task like using short variable names that then screw them in secondary tasks like bug-fixing or adding new requirements to the program later because it makes it far harder to figure out what the code is doing)

AI speeds up what people feel is the main task - creating the code - but that’s de facto more than offset by time lost on supposedly secondary work that doesn’t feel as much as “doing the work” so doesn’t get counted the same.

This is why when it actually gets measured independently and properly by people who aren’t just trusting their own feeling of “how long did it took” (or people who, thanks to experience, actually do properly measure the total time taken including in support activities, rather than just trusting their own subjective perception) it turns out that, at least in software development, AI actually slightly reduces productivity.

Doesn’t Windows 11 in practice require even more memory than Windows 10 to operate with decent performance?

Meanwhile my Linux gaming PC seems to actually use less memory than back when it was a Windows machine.

Isn’t that the red one? At least there’s no excuse for not being able to find it.

At times that shit is pretty much the opposite of what should be done.

Fail Fast is generally a much better way to handle certain risks, especially those around parts of the code which have certain expectations and the code upstream calling it (or even other systems sending it data) gets changed and breaks those expectations: it’s much better to just get “BAAM, error + stack trace” the first time you run the code with those upstream changes than have stuff silently fail to work properly and you only find out about it when the database in Production starts getting junk stored in certain fields or some other high impact problem.

You don’t want to silently suppress error reporting unless the errors are expected and properly dealt with as part of the process (say, network errors), you want to actually have the code validate early certain things coming in from the outside (be it other code or, even more importantly, other systems) for meeting certain expectations (say, check that a list of things which should never be empty is in fact not empty) and immediatly complain about it.

I’ve lost count how many times following this strategy has saved me from a small stupid bug (sometimes not even in my system) snowballing into something much worse because of the code silently ignoring that something is not as it’s supposed to be.

I’ve been pretty much upgrading my own desktop PC regularly since the 90s (though I did buy a brand new one 6 years ago).

In my experience the upgrade that’s more likelly to improve it the cheapest is RAM, then a graphics card if you’re a gamer.

Upgrading the CPU has always been something that happens less often and also it doesn’t help that the CPU can only be upgrade up to a point without having to replace the motherboard (which then forces replacing the RAM and possibly even the PC box).

However there were two transition periods were the best upgrade by far was something else: the first was back in the day when hardware 3D accelerator boards were invented (Quake with a 3dfx was night and day compared to software rendering) and the other one was the transition for HDD to SSD, both being massive jumps in performance.

Exactly.

A background of tinkering with stuff without fear of the consequences of breaking it (which is a common mindset mainly amongst kids and teens) is the difference between a tool-maker and a tool-user, IMHO, and thinkering is far more natural to start doing and to do much further with an open system than with a closed system.

The idea of “both-siderism” is anchored on 2D politics: you can’t have “both-siderism” where there are more than 2 sides, hence my point about viewing politics as 2D.

You’re living inside a box and only seeing what’s in that box, hence hyper-aware of the difference between those because they’re all that you know, whilst I’m outside the box and pointing out that compared to the rest of the Universe what’s inside that box you live in isn’t actually very different.

It’s like I’m talking about “the landscapes of the World” with an Eskimo - you keep insisting that “this icy landscape is very different from that icy landscape” (which I’m sure they are in the eyes of a person who has only ever known those landscapes and nothing else) even whilst I point out that they’re both icy landscapes and thus very similar to each other when compared to other kinds of landscapes that do exist in the rest of the World, such as sandy beaches or tropical forests.

Worse, your persistence in closing your eyes to the point I’ve made repeatedly that there are more sides than just two, leaves me with the feeling that I’m talking to a particularly provincial and simple minded Eskimo who thinks that those differences they’re so hyper-aware off between different kinds of icy landscapes are far more important differences that the vastly larger differences between those and the rest of the landscapes that actually exist outside the place they live in.

As a fraction of the total it’s still a small percentage, unless things changed a lot in the 5 years since I moved out of there.

I was thinking that the joke part was about the ciggie rather than the coffee.

Whilst you’re kind of joking (I hope!) on the health benefits, I would say that deriving some enjoyment from all manner of small pleasures is a pretty good way to keep one’s mental sanity.

In my experience that very much depends on the part of Europe you’re in: the “expresso in the morning” thing is mostly common in Southern Europe and France and back in the day when smoking was much more common and was actually allowed indoors in public venues, people having a ciggy and a morning coffee at a cafe was a pretty common sight.

Places in Europe without the whole tradition of coffee places serving expressos never really had this kind of “breakfast”.

On the “Europeans” side that’s at least 2 decades out of date.

The expresso coffee part is still true in a good part of Europe, but pretty much everywhere in it nowadays only a small fraction of people smoke and even those who do can’t actually do it inside a coffee shop because they’re not allowed to smoke there anymore, which spoils a great deal of the enjoyment of having a morning coffee.

Funnilly enough plenty (if not most) games which won’t at all run in a more recent Windows like Windows 10 and Windows 11 run just fine in Linux via Wine.

All in all if we consider the full or near full timeframe for “windows games” (say, all the way back to Win95) I wouldn’t be surprised if it turns out that a present day Linux distro can run more “windows games” as Windows 11.

One of the more entertaining (though hardly unexpected) discoveries for me when I moved from Windows to Linux on my gaming machine was that several of the games I owned which I could not get to run in Windows, worked fine in Linux.

You own post:

This bothsiderism is pretty thoughtless.

Your post starts with a sloganeering, hyper-reductive take of what I wrote.

As I wrote in response, “This is Politics, it’s not 1D or 2D”!

It is true that both contribute to a surveillance state but to equate both is to just ignore all policy differences, actions and more to pretend to be nuanced while painting everything as the same shade of grey, which is a downgrade to even black and white thinking.

In case you’re unware of it, two forests can be the same kind of forest even when the trees in each are different: demanding for others to focus on the details of the trees in each (otherwise they’re “painting everything as the same shade of grey”) is just a way to try to avoid that people look at the forest as a whole.

That said, you’re right. The details are different and I didn’t address that in my original post were I only talked about the main policy direction on these domains.

The broad policy direction on this subject is the same and the outcomes have been very similar and over time progressed in the same direction during the time in power of both parties, but things worsened in different domains at different speeds with different parties in power.

This is not even what many Americans call “the ratchet effect”, it’s actually worse because in this case it’s not one pushing in a certain direction and the other refusing to revert it, it’s actually both pushing in the same direction, with just some difference in details here and there which didn’t add up to much difference in outcomes.

So yeah, my point stands that in this domain both US parties are shit and my second point also stands that you’re trying to move the conversation away from criticizing parties for doing this shit by claiming that subtle differences in each party’s shit are more important that the overall shitty nature of their actions in this.

This is Politics, it’s not 1D or 2D, it’s N-Dimensional (with a very, very large N): it’s not just possible but pretty much a Mathematical certainty than in a country were there are only 2 parties they will match perfectly on some dimensions, even whilst not at all matching in others.

Trying to dismiss away that aspect of Reality (which is incoveninent for tribalists) with sloganeering like “bothsiderism” is just parroting propaganda meant for simpletons who see reality as having just one dimension where there is nothing more than 2 sides.

It’s pretty evident by their actual policies that strengthenning of police powers and the surveillance state are things in which both sides of the power duopoly in the US agree in the most, and it the face of both of those parties being shit on that domain your “yeah, but <tiny difference>” discourse is really just trying to distract away from the most nasty aspects of both of those taking big fat dumps on the face of every American, by talking about subtle details in the shape and consistency of each one’s shit.

Now, if you favorite party did start to diverge in that, you would have reason to celebrate, but it ain’t hapenning and discourse such as yours makes it even harder that it will ever happen - why would the tribe’s leadership change their ways when there’s a veritable army of tribalist peons going “yeah, but, bothsiderism” at any criticism of what they do, even those parts which are undeniably shit.