I think maybe it’s closer to the way computers think, maybe because we made them. It is very different to “model” anything without objects, all processes have state. But conversely there is no state not in process. I am relatively new to the functional paradigm, but it seems like it emphasizes the flow of data through a program in comparison to the state of the data. So the modules you add and what functions they contain have more to do with the way data is processed than what is being processed. It encourages spreading complexity out over transformations with relatively simple data being passed along at each step. Whereas OO encourage spreading complexity out through the state, with relatively short “distances” to travel before a data flow gets represented as state again. But each can be taken too far. The key to good engineering, “elegance” perhaps, is striking the proper balance. Bad OO projects, IMO, end up with either God objects or (arguably) superfluous objects like ThingThatDoesASoThatWeCanDoBNext, which seem like less of a threat in FP, but that doesn’t mean FP doesn’t have it’s own balance. I think I’m still too much of a beginner to define it as confidently though.
tfwright
NobbZ
In my opinion, the skill to understand huge and complex systems comes by trying to understand them.
In the first iterations there should be someone with you, explaining the compononts and how they interact together. Later on you will be able to get into those on your own.
There is a reason why we plan about a week for onboarding new devs into our comnpanies product. This week includes a shallow training in python and go (as we use those languages) as well as a brief tour of the components/services of the product, but without showing any code.
During daily business (which is sadly often enough unrelated to the product) there is usually found some time inbetween to get the new one into smaller issues in the product, they have to fix in a pairing session (only bug fixing, no feature adding!). After they have done this a couple of times and they feel proficient enough, they can access the ticketsystem freely and pick their tickets. And we are still open for questions.
Understanding complex systems is about how well they are explained/presented to you. You won’t be able to understand those on your own without putting in an amount of time that is close to the initial developing time.
Beeing able to zoom in and out during this introduction helps, but is not necessary if the system is documented well, or if its documented even better, then zooming happens without you even realizing, but I have seen such a documentation only once so far and that was for a system built at university solely for educational purpose.
mindok
This… if you can understand the difference between complexity inherent in the problem and accidental complexity introduced into the solution as a result of technical trade-offs (or more likely poor engineering), and become acutely aware of it in very technical decision you make (or any assessment you make of existing systems) you will go far. There’s almost an infinite amount of consulting work available to people willing to reverse accidental complexity out of existing systems.
One point on why applications won’t be built by AI in the short term related to this - complex real-world problems are often simplified to be represented by computer systems. Often this is for lack of available data (particularly in engineering / scientific systems), but also to keep the system simple enough for end-users to use. Joel Spolsky has a typically thought-provoking article on this - Choices – Joel on Software. Understanding what complexity to expose to the user, and what complexity to remove altogether and what the likely impact is, is something that is going to require human judgement for a long time yet.
zzyyxx
Beyond a CRUD app, there’s a lot of complexity to be tackled by gaining expertise in these topics:
- Beck’s Test-Driven Development
- Evans’ Domain-Driven Design
- Garsiel’s How browsers work
- Martin’s The System Design Primer
- Kleppmann’s Designing Data-Intensive Applications
- Kim & Humble & Debois & Willis’ The DevOps Handbook