I agree with you. The hard part for most (myself included) is the mental shift it takes to think in terms of events. Many of us are conditioned to think about the data structures first. Things I've heard (and for many years accepted as truth).
"Write down a sentence and underline the nouns. Those are your data structures."
This is hearing but not listening, devs. The verbs are probably more important. Things come and go, but it is how they are connected that makes them interesting. I don't care about the ball. I care that the ball broke my window.
"Allow the user to just edit data, and the program can do anything they want it to."
They will probably also hate themselves while they use it. Literally. Rules have to be developed among users of such a program in order to prevent chaos. Those rules are mostly in the user's head through an arduous trial-and-error process. The user knows if they just edit things "right", it would work properly. So any mistake they take as a personal failure, and using such an app is a constant threat/reminder of failure.
"Get the data structures right, and the code will write itself."
This has a ring of truth, especially in event-driven system. But it leads people to just focus on data structures. When in fact data structures are constantly shifting within a business. It is far more valuable to have a source of truth that is independent of the just today's representation of data, like an event. Sure, data in events may increase over time, but if I'm a sales shop, then OrderPlaced will probably be a thing from day 1 to day N. And I can easily make new representations of whatever I can dig out of OrderPlaced to answer questions that come up.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I agree with you. The hard part for most (myself included) is the mental shift it takes to think in terms of events. Many of us are conditioned to think about the data structures first. Things I've heard (and for many years accepted as truth).
This is hearing but not listening, devs. The verbs are probably more important. Things come and go, but it is how they are connected that makes them interesting. I don't care about the ball. I care that the ball broke my window.
They will probably also hate themselves while they use it. Literally. Rules have to be developed among users of such a program in order to prevent chaos. Those rules are mostly in the user's head through an arduous trial-and-error process. The user knows if they just edit things "right", it would work properly. So any mistake they take as a personal failure, and using such an app is a constant threat/reminder of failure.
This has a ring of truth, especially in event-driven system. But it leads people to just focus on data structures. When in fact data structures are constantly shifting within a business. It is far more valuable to have a source of truth that is independent of the just today's representation of data, like an event. Sure, data in events may increase over time, but if I'm a sales shop, then OrderPlaced will probably be a thing from day 1 to day N. And I can easily make new representations of whatever I can dig out of OrderPlaced to answer questions that come up.