1,306 karma · joined June 13, 2016
For CD Project the move to Unreal might make sense just from labour market perspective - it’s easier to hire programmers for Unreal than to train programmers to learn and develop your own in-house engine. Larger community and support already exists for Unreal etc. That move will affect their bottom line on their next games though. 5% is nothing to scoff at for a big product from a big company.
In any case, I’d advise caution to companies relying entirely on a single platform for their business. To echo my previous statement choosing only between Android and iOS for mobile is an illusion of choice. If you’re a mobile game dev your entire business relies on two relatively hostile companies.
With that said most big AAA companies still use their proprietary game engines and I don't see that changing. General purpose engines like Unreal/Unity/Godot have their place of course, but to use the full set of features of Unreal you need a big team anyways, so comparing it to Unity and Godot doesn't seem right to me at least. Godot is slowly eating Unity's lunch though. Especially given the direction that Unity has taken after their IPO they might be in trouble in the near future.
Also there are some crazy people (like me) that just write their own engines for the projects they are doing and here's hoping that in time our number will actually grow. It would be very sad if the game engine world ends up like the OS or browser world for example.
Perhaps. I don't agree with everything he says all the time, however, from my own experience on working on distributed enterprise software I can say that following patterns blindly is an actual problem that impedes a good working solution designed for the specific problem(s) a lot of the time. Devs are pushed by DM's and PO's to have a working product ASAP and what might be a good idea for MVP prototype ends up being a burden down the line because now the entire system is built on top of that decision made in a moment in time without serious thought. Then some time passes and the whole thing crashes down. Then a rewrite happens in the exact same way and the wheel keeps on spinning.
My 0.02c are that I think we should build things more sustainably and expect software to work longer. We should hold ourselves to a higher standard.
And I agree with him. Things like SOLID and "Clean Code" really are just buzzwords nowadays that don't mean anything.
My original comment was targeting the two supposed problems that the article is framing and the supposed convoluted (and possibly dangerous) solution with git reset.
I haven't used DynamoDB in a couple of years, so I'd be curious to know how querying compares if anyone can share some light that has used both Cosmos and Dynamo recently.
Yes, that's true. My original point still stands though. That commit will have a PR associated with it. You can go to it and see the details of all commits that were used for the merge commit that went into master. Not really a lot of extra work to go to the PR if you're investigating that deep.
> Even if the original branch is still floating around somewhere, that would still be an extra hassle.
If the branch deletion setting when merging a PR is selected, then only the origin branch will be deleted. If you're the one doing the PR and you don't delete your local branches you'll be able to see it locally. In the other case where is someone else's then it becomes harder, and I agree it's an extra hassle.
In my work I try to mandate PR's to be as small as possible, but not smaller. Big PR's do happen, but that and resorting to git blame or bisect happens maybe 2-3 times a year. I think the general rules for source control followed by the team are more important than the implementation details and git magic.
That will solve your problems if you're the messy type.
From my experience people that are good programmers are people that like to tinker with things. The logical part of programming can be learned by any intelligent person reasonably fast. It's not about variables, statements, expressions, ifs, loops etc. It's about having a conversation with the machine and trying things out. The tools, languages, frameworks are just extensions of this.
Computers and the way they work are fundamentally alien to our human way of thinking about things. You need patience and dedication. One approach might work for person A, but not for person B. At the end with time just like everything else in life you forge a meaningful "relationship" where you understand each other and can work together with the machine.
No.
I don't agree with Casey Muratori on a lot of things, but he hits the nail on the head about that statement in this video (around 23:00, but I'd suggest you watch the whole thing for context) - https://www.youtube.com/watch?v=7YpFGkG-u1w
I've walked out of interviews (politely) because I was asked to recite some buzzword bullshit like SOLID.