4 ms·

Beyond the problem-solving and planning aspects, I think Factorio helps a lot in learning programming concepts. No theory, just experiments with visual and env

Beyond the problem-solving and planning aspects, I think Factorio helps a lot in learning programming concepts. No theory, just experiments with visual and environmental feedback. * backpressure: your belts fill up * optimization problems: there's always at least one bottleneck, it just shifts elsewhere * deadlocks: a circular universal/sushi belt will block if not properly managed * parallelism: extending a branch off your main bus * locks: chained signals for shared train sections And then, you have combinators

Ancapistani 5y ago
> backpressure: your belts fill up This is a very good point, and one that I hadn't considered. I'm playing Satisfactory at the moment (very similar game) and for the first few dozen hours I played it I used building efficiency as my metric. For instance, let's say I have a simple factory chain: miner (iron ore), smelter (iron ingots), constructor (iron plates). I would start at the output side and make sure each building was operating at 100% efficiency. This works fine on a small scale and can produce optimal results in the early game. Later, I noticed that my conveyors moved at a set pace, and that I could easily find bottlenecks in my design by observing where the conveyors were either only partially filled or were stopping as inputs exceeded needs. As you progress, your factories get much larger. Checking each building takes time, and changes to the system mean you have to check each building after the changes propagate to be sure you've not messed something else up. It turns out that once you've reached a certain point of complexity, your bottleneck is more often input, not efficiency. Watching your conveyors gives you much faster feedback, and you can tell at a glance if you need to increase resource input into a factory "module" or if you need to modify your design at some point within than module. This is mirrored very well in managing a team of software engineers: you can watch individual productivity metrics, hours spent working on problems, story points delivered, etc. - but at some point, watching the inputs become a more comprehensive metric. Instead of exclusively monitoring your team's velocity (output), you should watch the size of your backlog over time (input). By extension, that means you should ensure that sufficient time is spent grooming and prioritizing backlog issues to ensure that you don't have things in your work queue that are no longer valid tasks (make sure you're not moving things that don't need to be moved anymore). If your backlog is steadily growing, it's time to talk about increasing your team's capacity. Often that means hiring more people (adding more buildings), which is the most direct solution. If payroll costs (power generation) are your containing factor, though, then your effort should be focused on tracking and optimizing individual and subteam productivity (individual building efficiency).

Ancapistani 5y ago

> backpressure: your belts fill up This is a very good point, and one that I hadn't considered. I'm playing Satisfactory at the moment (very similar game) and for the first few dozen hours I played it I used building efficiency as my metric. For instance, let's say I have a simple factory chain: miner (iron ore), smelter (iron ingots), constructor (iron plates). I would start at the output side and make sure each building was operating at 100% efficiency. This works fine on a small scale and can produce optimal results in the early game. Later, I noticed that my conveyors moved at a set pace, and that I could easily find bottlenecks in my design by observing where the conveyors were either only partially filled or were stopping as inputs exceeded needs. As you progress, your factories get much larger. Checking each building takes time, and changes to the system mean you have to check each building after the changes propagate to be sure you've not messed something else up. It turns out that once you've reached a certain point of complexity, your bottleneck is more often input, not efficiency. Watching your conveyors gives you much faster feedback, and you can tell at a glance if you need to increase resource input into a factory "module" or if you need to modify your design at some point within than module. This is mirrored very well in managing a team of software engineers: you can watch individual productivity metrics, hours spent working on problems, story points delivered, etc. - but at some point, watching the inputs become a more comprehensive metric. Instead of exclusively monitoring your team's velocity (output), you should watch the size of your backlog over time (input). By extension, that means you should ensure that sufficient time is spent grooming and prioritizing backlog issues to ensure that you don't have things in your work queue that are no longer valid tasks (make sure you're not moving things that don't need to be moved anymore). If your backlog is steadily growing, it's time to talk about increasing your team's capacity. Often that means hiring more people (adding more buildings), which is the most direct solution. If payroll costs (power generation) are your containing factor, though, then your effort should be focused on tracking and optimizing individual and subteam productivity (individual building efficiency).