| This winter break I spent an embarrassing amount of time on Satisfactory on Steam, which is essentially a nicer (and probably easier) modern refresh of Factorio. While I played, I came to similar conclusions to the article. Building factories in this game is very very similar conceptually to building software. I ran into exactly the same problems that I ran while I build software like: - If I don't plan ahead enough the scope and layout of the factory, I end up with a spaghetti mess that is very difficult to rectify (technical debt) - If I plan too much ahead, I overwhelm myself without even starting. The amount over-engineering and over-preparation becomes counterproductive and demoralizing. - Starting new factories is fun. Maintaining and extending a factory that is starting to show serious design issues is a chore. I always tend to want to scrap the factory and start fresh. - While designing a factory, modularization is key. You can go with a "monolithic" factory where you provide all possible materials as input, and try to build everything as output. It is very efficient transportation wise, and can centralize all management, but it can and it will become an unmaintainable mess. You can also design factories as "microservices", where each factory is a very compact, clean and scoped. It will only produce nails, or rubber, or copper wire. When you need to increase production of that item, you just duplicate the module (horizontal scaling). It seems fantastic at first, but the issue is now transportation. Dozens of micro-factories have to communicate with themselves to combine and produce more complicated items. The physical distance makes planning transportation a logistic and construction nightmare. So you have to find the right compromise between monolithic and micro-services. I think I agree with the article that you can extract a lot of information about how good a person can be at software development by the way he plays Factorio/Satisfactory. Not so practical though :) |