a pattern I think I’m noticing is that - if you’re results-oriented as a developer then the best move is to use something very big and complex to do a lot of the work for you. like a web framework, a GUI framework, a game engine, an SPA framework, etc.

and because of that, getting hired to write code generally also involves learning (at least on a surface level) several of these Big Complicated Things. because corpos are very results-oriented of course

what I’d expect is that amateur* programmers avoid Big Complicated Things because learning them takes a long time and none of that time is fun for them. but actually it seems like amateur programmers are more split on whether they use BCTs or not. and I find that interesting. I wonder if:

• some amateur programmers enjoy the process of learning BCTs
• some amateur programmers enjoy getting results faster than if they didn’t use BCTs
• a third reason?

* amateur: doing something out of pure passion and love - with no need to be paid for it

anyway I’m thinking about this a lot as I force-feed myself Unity and C# - two things (one of which is a BCT) that I do not want to learn, but might possibly be paid to use at some point in the future

what I’m also noticing is that as a developer I’m only comfortable learning things from the bottom up (starting with the small details and expanding my knowledge from there)

but BCTs seem to invariably be taught from the top down (starting by building a broad and vague understanding of everything, then getting less vague over time) and that completely makes sense, because the point of a BCT is to get your code working quickly and having a broad, vague understanding of the BCT is perfect for that. if you tried to learn a BCT from the bottom up, you would probably be learning for a very very long time until you could make something practical with it

but I’m Extremely Uncomfortable working with a BCT that I only understand in very vague terms. so that’s very not fun to me

in fact I think I’m just very uncomfortable with vagueness in general. that’s probably an autism thing but I have a hard time and tend to get frustrated when people speak to me in overly vague terms

even just giving me a high-level overview of code that uses language like “each game entity has components that are processed through a data pipeline” is difficult and frustrating for me because:

• the intended takeaway from that sentence is a very vague high-level understanding of how the code is organized
• and I have that vague understanding - it was successfully communicated to me
• but it feels like I have no understanding at all
• I feel like one of those raccoons trying to wash cotton candy like there’s nothing there? what was I supposed to get?

and yet it’s a genuinely valuable form of communication - maybe even an important one for collaborating with other programmers. but it frustrates me anyway lol

@kasdeya "each game entity has components that are processed through a data pipeline" by itself is a code speak. Not programming code, just a code. You may see a phrase "data pipeline" which is two words and sounds simple, but it's a code for very defined pattern you have to learn first hard. It's frustrating dissonance. Or "processed". Or...

@foxysen yeah… I do think I want to learn this so I can collaborate, because it seems important, but I hate it so far lol

it does seem like there are a lot of patterns to learn - and also a lot of terms that are used for their specific meaning in programming. maybe I need to see some code and compare it to the terms to really understand

@kasdeya@cryptid.cafe I'm an ameteur and my ideal is no frameworks and if I can (without a big effort) nothing outside the standard library either. But next year I do plan a more complicated program. Will be using external libraries for sure then.

@kasdeya https://gameprogrammingpatterns.com/

It's bideogames but you can skim it and find something interesting

@foxysen oohh thank you! I’m trying to learn Unity so this will be really helpful

@kasdeya ok tgen this should be good. Web version at bottom is fully free and complete.

@kasdeya tbh we relate a lot . . . whenever we've learned frameworks we start digging in and trying to satisfy a curiosity about how it works and how we could write something similar ourselves. sometimes this curiosity leads to us going "yeah okay it's more worth it to use the existing thing" and sometimes . . . well now we have a half-baked, nixos+password-manager secret flow; our own rust sql query utility we may or may not ever publish; and several partially-finished react-a-likes just because they're fun

@kasdeya we wouldn't say we *have* to learn bottom-up, but if we start from the top we have a strong itch to start digging

@tempest that’s interesting! to be honest I was wondering about y’all as I was writing some of this because you seem dramatically more comfortable with BCTs than I am. but I wonder if a lot of that is because you needed to learn them for work. it also sounds like you’re just more comfortable learning about them than I am

also it’s so cool that you’re able to make your own things using the same principles as the BCTs you’re copying

@kasdeya yeah the biggest framework we're comfortable with is probably react/nextjs, but when we first started learning both of them we were digging into the code a lot more — pre-hooks react was a lot easier to reason about what it was doing (there was less magic), and then when hooks were introduced we did a lot of digging into the code to see how they were pulling off the trickery (and we even did an experimental re-implementation of something similar for a game jam thing we never finished in probably like mid-2019)

with nextjs we similarly did a lot more digging into the code when it was simpler — we admittedly don't understand modern next nearly as much, but because the broader concepts and goals have stayed similar we're more okay with that as we've convinced ourselves we understand *a way* to do it even if we don't entirely understand the current way it works

tbh this motivation probably comes less from uncertainty and fear that we don't understand what we're relying on, and more like . . . a fear of missing out on learning all the cool things a tool might be doing behind the scenes. that desire to go poking around is very much proportional to how much we like the thing to start with, so we're usually fine to leave alone tools that we have to use for other reasons but don't actually like

@kasdeya although i get increasingly uncomfortable with vagueness and high-level concepts as i approach the point of implementation, i find it extremely valuable to know what something is supposed do to before i invest a bunch of time trying to figure it out from its low-level details. too many times have i been left with some horrible api docs just to figure out what the fuck an application is supposed to do

in one sense, i think of high-level architectural descriptions as contracts for how the low-level implementations will operate. it doesn’t tell me exactly what it does line-by-line, or even function-by-function, but it does set my expectations. sometimes the implementation details don’t matter (“will i use a dictionary or an array?”, “should these be int32 or int64? or maybe float32?”) and i just need to know broadly how something works (“it returns a collection of numbers”). this is useful when i don’t want to box myself into thinking about specific optimizations or anything else like that.

each game entity has components that are processed through a data pipeline

what i get from this is that it follows some type of component-based pattern. “that are processed through a data pipeline” doesn’t communicate terribly much to me aside from “entities are handled in some multi-step fashion where they are progressively transformed into something else.” i would want to know more about the data pipelines – do i set them up? are they configurable?

thinking in broad strokes before jumping into a sea of complexity helps me figure out at a glance if something will work for me or not. it gives me an impressionist painting of what working with the software will be like.

@kasdeya i don’t think of myself as a programmer in the sense that i enjoy the process of writing code or even thinking about the specifics of computer science, i do get a roundabout joy from it especially as it serves my other passions. i think i fall into your definition of amateur. but i’m probably also results-driven in that any joy i derive from programming is mostly supported by how much it will help me achieve what it is i’m trying to do. that could be “this code isn’t horrible to look at” or “i’ve abstracted away something really nasty so i can focus on what matters.” i don’t derive any joy from the abstractions themselves, only how they serve me. so i guess keep that in mind for the rest of this post?

i don’t see bcts as substantially different from using an external module, package, or even code-snippet from a random github gist. the only fundamental difference to me is how much i’m taking which i find very important in terms of cognitive load. when i take a 10-line function from stack overflow, i can generally understand it exactly as it is, it requires very little work from me to figure out how to incorporate it into what i’m working on.

however, as i borrow something more substantial it becomes imperative that i can efficiently understand what it is and how i’ll use it. in many cases, reading line-by-line would be overwhelming and unnecessary. what i really need is to understand how i can use it to solve the problem i’ve selected it to solve. if this is a little library that gives me a single data structure or two, that just means i need to know what the methods do and its general purpose. though, in the case of something much larger in scope, i may need to understand it in broader terms and digest the details as i get to them. “oh, so this is an ephemeral nosql database with a focus on performance” lets me know that it’s probably used for caching or something. if i want to store and persist my game’s data while making relationships between all of it, i know to skip this database.

and then of course, bcts like Unity or Blender. these are often meant to do more than just hang off the side of your app – they’re so substantial that it dwarfs whatever code i’m going to write, so it makes sense to architect my code around it instead. it’s not necessarily that i want to use it, but if i have an idea for a game that requires any significant amount of complexity, i’m going to need to learn a lot of stuff to pull it off. and this is more than just replacing unity with a bunch of libraries which roughly sum to the same feature set – i also need to have the knowledge on how to orchestrate them to get what i want.

@kasdeya i guess if i had to answer “why do i use complicated solutions” it’s because the problem i’m trying to solve is complicated. when making a game, i’m not interested in solving how to make a render graph, or how to make camera which utilizes that render graph, or how to make a renderer which supports multiple cameras and multiple rendering stages. i want to make a game, not an audio system that can be used in a game, so i try to pick the right tool for the job. in some cases, the problem i’m trying to solve is trivial enough that writing it myself will be the best option, but sometimes the problem is so broad and complicated that trying to do it myself would simply result in me giving up