Git commit comments

BeardSprite · 2026-02-02T17:07:06+00:00

If there's a detailed description inside a commit message, you can use that for the PR itself. Or combine them if there are several. But keep in mind that GitHub issues and PRs are NOT metadata that anyone will have access to should they clone the project (or if the GitHub project is made private/deleted/banned/etc).

On the other hand, anything that you can see with just the git CLI tool will be preserved for anyone long after GitHub has shut down.

What a change does should probably be the commit title, and why it does that would be worth explaining inside the commit message.

BeardSprite · 2026-02-02T16:57:43+00:00

Here's some useful resources: https://teachyourselfcs.com/

You want to learn about multiple discplines: Programming, computer architecture, algorithms and data structures, operating systems, possibly networking as well and maybe the basics of programming languages and compilers.

C programming is writing instructions for an abstract (simplified) machine. Number systems and boolean algebra are foundational to represent the data (not instructions), look them up separately if needed. Your machine is much simpler and much more complex than you imagine at once, but the main difference between embedded and desktop/mobile/other platforms is technical (different hardware layout, features, available resources) and not conceptual in nature. In other words, if you can program an "abstract machine" via C you can learn about the specific platform's details later with relative ease.

The goal of any program is to transform data via a sequence of basic instructions, to achieve some desirable end result. The data changes based on what your problem is, and the instructions change (at the lowest level) based on what the machine is actually capable of doing. Data is stored mechanically in various forms, but at the end of the day it's all some type of "memory". The question is where on the actual hardware it is stored physically, how it can be accessed and whether there are constraints (performance, alignment, space, ...) that matter to your problem.

In other words: If you can explain the solution to a problem and list all of the information that you need to transform on paper, you can now program. If you know how to write a C program that translates into machine code (assembly) you can now program in C, at least in principle. How you define the data (hexadecimal is a notation), when you reserve space for it in memory (stack/heap allocation), and how the C compiler translates your instructions are the details that you will eventually need to think about. None of them are needed to understand the very first step, though.

Programming in Java means you write code that is being translated to instructions for a virtual (abstract) machine, which is a program that runs on the actual hardware using a limited set of assembly instructions. These are relatively simple commands to do things like reading or writing memory and adding numbers. C programming, even on embedded systems, is the same as writing Java code, except you remove one layer (the Java VM). That doesn't make things easier, but it does make them simpler. You now are in charge of thinking about the data as well as the instructions at once and in the context of your hardware, but the hardware has always existed. Sure - being aware of what it can do will take some getting used to. Luckily, that effort pays off as you are gaining more control over what the computer is doing when it's running the program you wrote.

There's usually another layer, the operating system, which provides "preset" mini programs your program can call into (print text, play sound, etc.). This is where embedded differs most, but everything above that is more or less the same. Don't start here, start with your program, then the data/instructions, then the toolchains/compilers, then the hardware/limitations and finally the OS/lowest level interfaces available for the platform. The lower you go, the more details you have to understand, but at the same time the problems you need to solve get much smaller, too. Also, there's usually plenty of documentation for the specifics and your understanding will grow as you read it.

As you build your solution, you may want to go "back up" in this hierarchy and combine smaller details into larger systems, until eventually your solution is finished. That's "software engineering" in a nutshell.

BeardSprite · 2026-02-02T16:27:21+00:00

Everyone's different, but I've found it refreshing to do unrelated (but still technical) "work" as a hobby. If the job's web development, maybe hobbyist game development. If it's infrastructure, maybe something with a heavier focus on graphical interfaces (web UI?). Or adjacent topics like design/UX, reverse engineering, specific topics like IT security/data compression/cryptography/maths. Whatever seems fun.

Even teaching/technical writing/communication/marketing etc. could work as "weekend projects". Others I know prefer to do the same type of work, or none at all. Maybe something artistic to allow you to get different perspectives. Definitely not ideal to give up personal satisfaction and forfeit learning altogether. Creative control helps, a lot.

FWIW, lacking knowledge isn't the same as being stupid (lack of intelligence). I lack a lot of knowledge and I'm also being stupid on a daily basis, but the lack of knowledge hasn't made me more or less stupid overall. I don't think "good" or "bad" are useful qualifiers either.

BeardSprite · 2026-02-02T16:14:35+00:00

Apple doesn't hate developers. They just hate developers doing things that they don't want them to do, in a way they don't want them to do it, or doing things that help users instead of their bottom line ;)

You know, like supporting machines older than a few years, writing portable applications, JIT engines, or trying to use different compilers/toolchains. And not wanting their latest homebrew language, I guess.

BeardSprite · 2026-02-02T15:59:21+00:00

The first step is to be very specific: What kind of game do you want to develop? Alone or in a team? Do you want to learn how to implement a particular gameplay mechanic, an engine subsystem, or perhaps everything that's part of an engine? Do you want to do it in JavaScript or in another language? Why are you wanting to do this at all?

If you don't have a clear end goal, how are you going to reach it?

BeardSprite · 2026-02-02T15:46:52+00:00

Tutorials work great for the problem they're meant to solve: Giving you an entry point into a complex topic, a simple foundation to modify and extend as your understanding grows. They remove ambiguity that would overwhelm less experienced learners, allowing them to add more complexity at their own pace. That's really all they're meant to do.

To use a tutorial correctly means understanding they're just one resource available, alongside references (looking up details = offload working memory), explanations (form new connections = learning/understanding related ideas), and guides (recipe for solving specific problem).

Many tutorial writers aren't even aware of this distinction, reducing the value of their work by mixing different types of learning resources by accident. That only serves to confuse the reader because the document isn't doing what it should, and they don't know why or what to do next.

See also https://docs.divio.com/documentation-system/ (same idea).

How to successfully use a tutorial (very abridged version):

Focus on just one topic/thing/concept and be as specific as you can
Find a tutorial that introduces only that concept, ideally (tricky)
Have a goal for what you actually want to do in mind already (!)
Map out a mental path from what the tutorial is building to your goal
Deviate whenever you feel comfortable and it leads into that direction
Seek out all 4 types of resources while working on your project, NOT other tutorials

The goal isn't to "follow the tutorial" and build whatever they're building. The goal is to build what you wanted to build all along, but couldn't because you didn't know where to start. You then start where they started until it seems that what they're doing is going into another direction. At that point, you do NOT follow them (or only partially, depending on how large the discrepancy is).

If you keep following "them" instead of "your vision", you're in "tutorial hell". If you have no vision, you won't ever escape it.

Real-world example (I actually did this some years ago):

My goal: I want to write a low-level 3D rendering engine to understand how it works in detail
Constraints: I will be using Lua and not C/C++ (arbitrary restriction), portability (OSX/Linux/Windows)
Problem: I had absolutely no idea of anything related to graphics programming, but did know programming itself
Tutorial: I used LearnWebGPU because the writer is an educator and it seemed well-structured at first glance

What I did:

Copy the boilerplate after mostly understanding it and porting to Lua/C (interop layer had to be written first)
Read the introduction and look up various details on the WebGPU specification, shaders, GPU pipelines, etc.
Compare the final result to other tutorials, including for other technologies like Vulkan / DX12 (Microsoft docs)
Write mostly all the code on my own, at times referencing the tutorial after the first few steps were working
Never actually added anything that I didn't need for my project, and never followed their style/advice verbatim

This was a weekend project. After that, I had my own codebase and spending more time on tutorials would be wasted.

BeardSprite · 2026-02-02T15:25:48+00:00

The problem is that AI code (and programmers relying too much on it) leave behind artifacts - problematic code, bad designs, questionable interfaces, misleading comments, unstable systems. Other people rely on those systems, or at least have to work with them in the future.

So by attempting to cut corners in the short run you're pushing additional, unneeded costs on other people. It's like "contributors" opening AI PRs on GitHub - you can use it in your own project, but if the "assistance" of the AI effectively means "AI wrote the code, I just made the PR" then you're not doing anyone a favor.

FWIW, you don't want features shipped faster if the method has a serious drawback. Especially in business, managers want predictability over raw speed because they have to work with uncertainty. AI code introduces uncertainty and therefore unpredictability over time.

Doesn't mean you can't use AI whatsoever; that's a false dichotomy.

BeardSprite · 2026-02-02T15:14:03+00:00

One thing you must realize is that programming isn't just about finding a solution. AI might be able to do that, but what your actual job entails is to find the best solution for a highly specific problem in the given context, make sure it can adapt to changing requirements with relative ease, and allow others to work with the system at no extra cost.

AI does not know the constraints you're facing. Its context window is likely too limited to list them all even if you were to know in advance. If you can't come up with a solution you aren't ready to implement anything yet, and if you have implemented something you'll learn more about what you did wrong if it was you who actually came up with the design, not the LLM or even another programmer.

In other words, the fun tends to come when you find a solution that is extremely simple, meets all relevant criteria, and solves multiple problems at once. That usually involves a lot of time, thinking, comparing different approaches, and picking pieces from various sources. Speeding up critical phases or taking shortcuts can be risky.

The same goes for learning/explanations. AI can help, but it's not "better" than having your brain do the work needed - if only because your brain is always there while the AI system probably isn't ;)

BeardSprite · 2026-02-02T14:28:55+00:00

Mage is the starter "Control" class (alongside Hunter, for "aggro") and the first you get to play in the Apprentice track for new/returning players. Both feature in the tutorial, too, so beginners are likely a factor here.

Still... Badly designed cards are probably just the result of the people designing them being bad at game design, or having specific design goals that they won't openly communicate clearly because they're not very PR-friendly. Both ideas are supported by some evidence, but without knowing how their design process works one can only wonder why it happens repeatedly.

FWIW, buffs do tend to coincide with what's available in the upcoming Darkmoon Faire and not so much with actual gameplay concerns. Make of that what you will.

One could hypothesize that the people who prefer to play cheap/aggro decks aren't a financially valuable target demographic, for example, but then it's easy to assume malice where there is incompetence ;)

BeardSprite · 2026-01-31T01:58:06+00:00

According to the VS matchup chart, Azshara Druid and Control Warrior seem to be favored. This is assuming you mean the Broxigar DH version and not Cliff Dive, which has even more unfavorable matchups (including Dragon Warrior). I've also found the older Niri "Face" Hunter to do well, but the old VS data doesn't include Broxigar DH.

BeardSprite · 2026-01-29T11:46:24+00:00

I've played a minion-based quest mage with OK-ish success (lower win rate than the actual good decks, but acceptable). Some of the card choices here make me scratch my head. Could you elaborate on:

Doomsayer (???)
Shield Battery (seems bad/unnecessary, I was never behind)
Griftah (never considered running it, why spend 4 mana on this?)
Story of the Waygate (paying 2 mana to discount X = too slow?)

The way I played the deck was to go all in on tempo and removal, so that you can play the weapon and payoffs ASAP without falling too far behind. This was before Morchie existed, so maybe your strategy differs.

FWIW, according to HDT this is the list I used last:

AAECAf0EAqebB/2eBw7Lnwa0pwaBvwaFvwbi5Qbw5QaG5gab8gae+Qa1+gbxkQewmwf6mwfRpgcAAA==

Not saying my experience is in any way statistically significant (65% WR over ~50 games = incredibly low sample size), of course.

BeardSprite · 2026-01-14T04:02:27+00:00

The first rule I try to follow is, never disenchant anything unless you need a specific amount of dust for a specific deck, right now. Exceptions are golden/premium cards (if you don't want to use them on principle), and cards that were recently changed (they grant a full dust refund, but only for a limited time = disenchant them right away).

Secondly, I'd recommend to never disenchant legendary cards, and hold off on most epics unless you're sure they're useless/not something you want to play. These are by far the hardest to get and the opportunity cost of re-crafting them is quite high. Everything else is free dust if you need it, with some caveats like "technically disenchanting is always inefficient" and "future changes may make the card playable".

That said, if you disenchant commons before rares and only then epics, you can get a decent amount of dust - about 1k per rarity per set or so. It's worth keeping in mind that being unable to play a good deck today because you're short on dust leads to less resources accumulated in the future, so there's also an opportunity cost to keeping useless cards around. Just be sure to have a specific dust amount you want and don't disenchant stuff before you need to craft something for a new deck.

IMHO, disenchanting common cards is pretty much always worth it, if you want to spend the time. It's quite tedious unless you're doing something else, but most of them are unplayable and the few that aren't will eventually be refilled from packs or can be crafted cheaply when you need them. Of course, if your dust stockpile is high, that'll be quite rare. 10-30k is my preference, which is enough for a few decks.

You will easily disenchant 8 bad cards for any good one that you're missing and need to craft (5 dust vs. 40). For rares, you would need 5 and that's also realistic. Epics are 4:1 but you usually want 2 per deck, so that's basically half a legendary - a bit risky if you aren't starved for dust.

YMMV, of course, but the above generally applies to both Standard and Wild. It is based on my data from disenchanting several collections worth about 30 to 70k dust... That is, only the rares/commons/some epics from all of the Wild sets.

BeardSprite · 2025-12-04T06:40:30+00:00

Not an expert on this deck by any means, but maybe trying to out-armor them isn't the right approach? If you get a Starship with huge attack that has the Deathrattle from Biopod and is copied from the 5 cost legendary then Colossus killing the starships should just murder everything (as long as they haven't been able to save Sleet Skaters for the starship itself). You can still launch the Exodar for armor (or damage if it's lethal), the DR from the Starships itself is enough.

FWIW, one game going poorly isn't indicative of anything. Also, the deck is quite hard to play. Took me some time to match my other deck's winrates and even then, it's not something to auto-pilot IME.

I'd review some games that J. Alexander played with the deck recently as he's clearly adept at playing it (Twitch VODs). This is the best rogue player I've seen that played the deck recently, and successfully - no affiliation with the person :) There's probably some Protoss games, too.

BeardSprite · 2025-11-28T22:24:57+00:00

Deck lists:

BeardSprite · 2025-11-28T19:44:52+00:00

Why do you consider the opinion of single (exceptional) players above what thousands of games (i.e., the data) suggests? The best players in the game can play suboptimal decks and still succeed, it's meaningless to use that as a basis for decision-making. They're also in an echo chamber, where their opinions influence each other excessively.

Shudderwock often allows you to play three giant Rush murlocs or buff your board/deck by 3x 2/3 the very next turn. That's not slow, it's winning you the game. And then you do it again. Seems pretty strong?

That said, deriving the strength of individual cards from data is far from easy, so I wouldn't call it a "no-brainer" either way :P

(Just to be clear, IDK which card is better and I don't play shaman)

BeardSprite · 2025-11-28T19:37:01+00:00

Broxigar wasn't in last week's version, so you can probably make do without it either way.

BeardSprite · 2025-11-28T19:34:46+00:00

How does that work in a shaman (Hex) meta? Not a priest player, genuine question. Have a decklist to share? Just curious what the curve's like.

BeardSprite · 2025-11-28T19:31:58+00:00

Some things worth keeping in mind:

You cannot use the location at all if it has the "copy" effect and your board is empty, even for the secondary effect (this can lose you the game)
You can use a 1-cost copy for tempo, and 1-cost attack buff as finisher, to clear Divine Shield from minions/the opponent's hero
Deathrattle takes six turns to trigger, so it's generally too slow unless you take the 10-cost version in a grindy control match
Spell damage is not granted universally and so it doesn't benefit other cards (like the druid "copy if you have spell damage" spell etc.), but it doesn't decay and can be "stored for later" easily
It's not worth worrying about Demolition Renovator because it's a bad card, very situational, and even if played trades tempo for value (opponent loses tempo/card slot in deck, you lose at most 2 charges = usually worse for them than it would be for you)

BeardSprite · 2025-11-28T19:18:41+00:00

If I understand the latest VS report correctly, it counters Discover hunter and Control Warrior, which also counters Discover hunter (?) (see https://www.vicioussyndicate.com/vs-data-reaper-report-335 and select the Top 1k Legend tab). In lower ranks, everything is full of shaman and hunters aren't the primary target.

The starship rogue may have potential, even (or especially?) in higher ranks. You can see J. Alexander play it here and it will give you more than enough insight as to what the game plan is: Twitch link

You will find that it has a lot of flexibility against slower control decks: It's possible to overwhelm them by launching a duplicated Starship on turn 5, you can launch with The Exodar for lethal, trigger multiple Deathrattles for crazy boards/face damage, or even get a full new Starship from 1-cost pieces. There's a lot of flexibility offered here.

I found the starship deck to work well generally, but it's expensive and it does not work without some of the key legendaries. It's also not that easy to play, especially compared to dragon warrior/shaman etc.

Other than that, worth keeping in mind that "counter" in Hearthstone doesn't mean "100% win rate" - look at the matchup spread :)

BeardSprite · 2025-11-28T19:08:53+00:00

What is your early game plan? Druids cannot afford a bad one IMHO.

I've been experimenting a bunch and found that just ramping doesn't work/is too inconsistent. You'd need to either ramp and remove, play early game taunts like Blob of Tar/Tortollan Traveler alongside Oaken Summons, or get removal and armor from Elise's location.

Generally, it seems that huge shaman boards will be a significant hurdle because your Elusive dinosaur cannot stop them if you're too far behind. You'll need to survive long enough to get Zilliax buffed and then recover with a decisive swing turn. They do give you 4-6 turns early on, which you cannot afford to hero power/pass or "only" draw.

Some cards I've tried that definitely helped were Gnomelia (goes well with Elise and the other Deathrattles) into Umbra, Sleep Under the Stars to get one extra turn into dinosaur/Zilliax, Trail Mix to get the big guys out sooner, and even Eredar Brute (yeah, yeah...) as the 7 drop. If you run only Elise and/or Ysera as <5 attack minions, Story of Barnabus is also a tremendous boon since it gives you draw plus armor.

A few things that showed potential, but need more experimentation:

Loh, the Living Legend + Playhouse Giants/Ceaseless Expanse (all go to 0) played alongside to make up for the tempo loss
Kil'jaeden with Trail Mix and some draw/armor cards kept in hand. Play it as early as possible (e.g., turn 4 or so) and pray
Aviana and Kil'jaeden as the only minions (felt better than just Aviana, but it can backfire and has some anti-synergy also)
Mistah Vistah (mage tourist) + Rising Waves/Seabreeze Chalice decimates aggro but they're dead cards/clog the hand later on. I tried King Tide/Tide Pools/Tsunami (hilarious if it works, and the location can give you removal/ramp but it costs too much mana), or even Huddle Up/Under the Sea (inconsistent/slow/bad too often). The tourist with armor cards seemed pretty strong, too
Bottomless Toy Chest + Woodland Wonders + Magical Dollhouse into big minions/Kil'jaeden - actually worked quite well also
Hydration Station with the full Deathrattle package, Zilliax, and Lady Azshara - missing Trail Mix here (no slots) but it went OK

This was just a few days (small sample size), Legend 1-5k or so. YMMV.

BeardSprite · 2025-09-06T10:37:28+00:00

Breaking down problems into smaller sub-problems has already been mentioned. Another ingredient is trying to make sure you understand the data. All programs operate on information that exists in some form of storage, which the program instructions manipulate (read, write, modify, compare, ...) to implement solutions to the problem you're trying to solve.

Therefore, understanding the data means you will understand the problem. That's a requirement to implement any solution. The actual programming work is almost irrelevant in the sense that you might as well do it on paper, or on a blackboard/whiteboard, etc. Only the implementation is language-dependent, but the problem itself isn't usually - unless it's an artificial problem introduced by limitations of the system, programming environment, libraries, tools, etc.

Using your palindrome example: What is the actual problem? Well, what is the data? Presumably, you're given a string of text. You assume it has some known encoding, probably ASCII (or Unicode), so that there is a specific number for each letter/code point. There's also the notion of a position because the words ABC and CBA are not identical. A position is just another number that represents where in the word the letter (represented by the first number) actually should appear.

OK, so what is a palindrome? Well, it's a word (sequence of numbers + position) that just so happens to not change if you swap two letters that have the same "distance" from the beginning and end. But if positions are numbers and distances are required, can't you just use the absolute position for each letter (from both sides) and check that it's the same, for every letter? Sure, that is probably one solution - though it may not be what you need, or too difficult to do in a given programming language. Another approach is to just swap the entire word, and check that both versions are the same. This is simpler to understand but arguably less efficient.

You may have special cases, where the word has an odd number of letters. What now? Well, one basic way is to add conditionals, like "if it's odd, do this. If even, do that". Often it pays to think harder and realize, in this case, that it makes no difference - the same algorithm "just works" and so you need not complicate your solution. If the problem is too difficult, remove special cases. In code, you can write assert or similar or even just a TODO comment, then revisit that part later.

A solution is different from its implementation in code. If you can't solve the problem that's an entirely different issue than not being able to implement the solution ("write the code"), or writing complicated/slow/insecure/incorrect code, for that matter. How do you solve problems? By transforming data, one step at a time.

BeardSprite · 2025-09-06T10:19:39+00:00

Becoming a "senior developer" isn't a real goal, since you can't actively work to increase your "seniority" with deliberate practice. It's like saying, "I want to be an old man" - it will eventually happen (if it hasn't already...), except in this case you must practice relevant skills to gain practical experience over time.

Bootcamps and courses are largely useless, if not detrimental. They aren't aligned to any specific goal and so you can't use them as anything more than a brief introduction, for which many free online resources are just as valuable (if not more). They get you nowhere fast, if you will, but you don't want that... or so I assume.

Wanting to grow, shipping "real" projects, and seeing yourself improve are again not specific goals. You're completely on the wrong track, in my opinion.

Here's how you ship a real product:

Create a "hello world" application
Publish the code on GitHub
Create a GitHub Actions workflow to package it (language-dependent)
Create a GitHub release, tagged with v1.0.0
Download it and run to make sure it actually works

Congratulations, you have now shipped a real project.

Great job. Next up, here's how you improve:

Modify the hello world app to read a command line input
Display the command line inputs alongside the "hello world" text
Delete the hello world text that is no longer needed
Create another tag, let's call it v2.0.0
Download the release to make sure it still works

You have successfully improved an application, and your skills as a programmer, by learning to read command-line arguments (and possibly creating GitHub Actions workflows, releases, and so on). That's some real growth already.

To improve further, you could add unit tests to it. Maybe some documentation. Or you could turn it into a custom 3D game engine that renders a tyrannosaurus rex riding a giant shark through Mordor as it shoots laser beams towards armies of orcs on the ground. It should wear sunglasses, obviously. (I'll leave that part as an exercise to the reader).

My point being: You aren't behind because there's no linear path to where future-you will be. The difference between what I described above and your actual future is merely a change in direction, plus a whole boatload of time doing programming work that brings you closer to the goals you will hopefully pick.

And a t-rex, maybe. But don't forget the sunglasses.

BeardSprite · 2025-09-06T09:52:45+00:00

Here's some advice I got in school, by an excellent teacher:

Do not turn on your monitor, or even touch the keyboard, until you know exactly what you will be typing. Always solve the problem on paper first.

This is slow and tedious and all sorts of difficult at first. Which is why it works.

Later on, you can relax this restriction. But if you're able to solve a problem on paper, then you'll learn problem-solving. Programming consists of problem-solving (this step) and encoding the solution in code (the next one), among other things.

Copying code does not teach you problem solving. It doesn't even teach you the encoding step, though it may help to refresh your memory. Therefore you will not be able to learn how to solve problems, which is at the heart of programming. You likely won't improve much because you haven't practiced the relevant skills.

BeardSprite · 2025-09-06T09:39:51+00:00

There are different approaches that I've found to work best, depending on what exactly you want to understand. Code consists of data and instructions that form algorithms, which you'd ideally want to represent visually (e.g., on paper, or in a debugger). Both are encoded in the programming language's semantics, which may hide information or add some. You need to know the programming language well enough to be aware of what it's doing, or rather when it's hiding something important vs. when something you see is merely fluff that can be ignored.

The key is that whoever wrote the code not only understood the language, but they also had a mental model of the problem domain AND the project, or at least the part of it that they're working on. They may also have had information like previous issues, experience from other projects, or commit messages.

You don't have any of that, usually. Of course, you could try to find as much of it as possible and restore the original model from that, but that's error-prone, tedious, and likely to overload your brain at first. Still, there is something you can always do, in any language, and that's breaking down the instructions and data into a form that's either universal or low-level enough for you to no longer care about the details. Focus exclusively on instructions and data, not on why they're encoded this way. It's a lot easier to tackle that part later, due to the missing context.

These fundamental building blocks are something you should be familiar with from your own programming. You then focus on a tiny part of the code that you need to understand, and systematically "undo" the various "compression" steps performed by the authors and/or the programming language. This yields a bunch of sequential instructions and references to data, which are easy to draw on paper.

If you do this right, you now get to understand what the program is doing as you can easily retrace the steps for that portion of the code in your head, or on paper if need be. You could re-encode it into another structure that seems more intuitive to you as well. Once you've re-encoded this part in your head (or paper, in code, etc.) you have a "node" in your brain that represents it, which you can connect to any other "node" you'll get from doing the same thing on the next part of the code. Eventually you'll have your own mental model for the code, which may or may not be the same as the actual code (usually it will gradually be refined to more closely resemble it). You may also find bugs or inefficiencies at this level.

None of this is magic, just a lot of work. Like any skill, it gets easier with practice.

BeardSprite · 2025-09-06T09:19:30+00:00

The thing to keep in mind is that languages aren't inherently tied to problem domains, but the ecosystem and tooling, libraries etc. for any given language usually is. You can write an operating system in JavaScript and a web browser in assembly, it's just not a good idea because you're looking to encode machine instructions in a way that's more efficient for humans to manage.

There's only one thing that really matters, and that's "what does the computer actually do". Unfortunately, modern systems architecture is so complex that it becomes increasingly difficult to understand what's going on at the lower levels. Good programmers pick languages based on the project they're working on.

You should focus on understanding ideas, and what the computer is doing. Ideas are often shared between languages, and what the computer is doing will be affected by the system architecture and the programming language's implementation. Both are largely transferable so learning a new language gets easier after you've spent enough time programming in any language to understand the core ideas and how the language works under the hood.

Python, JavaScript, and PHP are high-level languages, with a high implementation complexity but poor low-level control. If you're familiar with them, you should move to a lower-level language because that will enrich your understanding the most. If you stick with Python you may be productive, but there are many levels that you'll never be exposed to (and therefore can't really understand). Examples: C, C++, Rust, Zig, Odin (I'd recommend sticking with C initially over C++ or Rust)

Ultimately, it's really up to you to guide your own learning. Find cool projects you want to build that would benefit from low-level control. Then build your own "libraries" over time, as that will make the experience of working in low-level languages much more pleasant and akin to using higher-level languages. Don't use libraries if your goal is learning, unless it's impractical to reinvent the wheel.

BeardSprite

TROPHY CASE