Doesn’t know the lyrics. Just goes meow meow meow.
If you actually want to finish a game on your own, writing it in C or C++ is terrible advice imho. Just pick a friendly game engine and stand on their shoulders. Oh and for the love of God don’t write your own physics engine. Also why are you even mentioning machine learning?
Anyways for a healthy dose of gamedev wisdom from a grey beard at the trenches, Jeff Vogel’s blog is nice.
First rule for any kind of technologist is to ignore the gurus. Critical judgment is, well, critical. All the programming languages are fine, old and new. You’re not supposed to marry one.
Runs away from doomscrolling
Lands on this beauty: https://longdogechallenge.com/
I don’t see the contradiction. If you’re doing CRUD operations on 10,000 points, I’m sure you’re doing what’s possible to send it to storage in one fell swoop. You most probably get out of those loops any operation that doesn’t need to be repeated as well.
There’s some simple rules of thumb that can be inferred from Big O notation. For example, I try to be careful with what I do in nested loops whose number of repetitions will grow with application usage. I might be stepping into O(n^2) territory, this is not the place for database queries.
We’re definitely lightyears away from that cursed era of building layouts with float.
I’m old ahem experienced too and I went from no app development to having a basic native app on my Android phone in a few days with Flutter/dart. The language is easy to pick up, there’s plenty of documentation and it’s pretty polyvalent since it can build for mobile, desktop or web.
I’ve worked in a small org with very few devs. I was the only one for a while. I think the most important in this sort of environment is to care.
I’ve found it useful to pay attention to the org’s goals and strategy as well as being interested in how operations work. This is because you may end up taking a ton of microdecisions during development and you want them to align. As your understanding grows and you slowly take your place, you may be consulted as well for all sorts of things.
You’ll need to take your personal technical growth into your own hands. The org should be expecting you to do so and they may even grow interested in what exciting new stuff you’ve learned.
Also if you have plenty of non technical colleagues, translating your technical reality into layman’s terms and in actual impact is key. It’s important to build that bridge.
It can be a super rewarding experience! The fact you love the place and you’re already wary not to stagnate makes me think you’re a good fit.
More generally, the more you have a flexible editor in the app, the worst it gets. This is the use case where I ran into trouble.
News flash: your snark makes you an unpleasant person. Read my comment again. I said tree shaking fixes this… unless you don’t know what content you’ll display and what classes you’ll need at build time. Not all sites are static.
Tailwind only really makes sense in a precise use case that absolutely does not cover everything web based and I wish the makers where clearer about it.
First off, the abstraction problem: since you give up on defining custom classes at length, elements will often receive more than a dozen utility classes. This is fine IF you use a component based framework like Vue and you break down your app into components with a small granularity.
Second, the stylesheet problem: even minified and compressed, a stylesheet containing all of Tailwind’s utility classes is multiple Megabytes. The issue will not come from where you’d expect; downloading may take a while on the first page load, but all page loads will suffer from taking into account such a massive set of rules. Tree shaking makes this fine IF your content is already known at the moment of building the app.
In the end I feel that Tailwind implements ideas on top of tech it is incompatible with and the abstractions it create are seriously leaking.
Yeah I don’t agree with “bulldozer code” bit. Splitting a long function into smaller parts doesn’t have to be about reuse. It’s useful to do it for clarity. As a single function grows, the number of local variable often grows as well and eventually you end up juggling tons of variables and the slightest change ripples three hundred lines further down. Break it down into a handful of steps with a number of arguments you can count on your fingers and it suddenly becomes so simple. Same about deep nesting of loops/conditions.
Rule of thumb is a function needs to fit in my head - so if I stick my face on the screen and the function’s code can still be partly seen, it’s time to break it down.
This is total speculation, best is to ask them why it matters to them. I’ve seen two things:
Basically they may just be in the process of discussing internally what position to adopt and they don’t want someone totally clueless or uninterested onboard.
Exactly, the Internet is still a thing! “Oh but it’s cool for code snippets.” Have you heard of our Lord and Savior StackOverflow?
The replacement theory brings up this weird conundrum where the LLMs need to consume human work to train themselves, the very work they seek to replace. So once the plan succeeds, how does it progress further?
Thanks for reminding me of that. We’re content creators ourselves, so respecting copyright is a big deal.
(It’s OK guys! This isn’t about cryptocurrency, it’s about cryptography!)
Cryptography is FUN. The kind of fun that gives you headaches and keeps you up at night. (No /s, I mean it.)
I wasn’t aware of this site at all. I’ll keep it bookmarked since I enjoyed cryptography in university way more than I had expected to.
I agree with everything said so far. Just wanna add that starting a little big and then shrinking resources can be less stressful if you value user experience more then some extra expense at launch.