So an engineer, a physicist, and a mathematician move in to a new place together.
Their first night, a fire starts in the house. The engineer wakes up, sees it, douses it in buckets of water, puts it out, and goes to sleep.
The second night, another fire starts. This time, the physicist wakes up, sees it, calculates exactly how much water to use to put out the fire, pours exactly that much water on the fire (plus or minus experimental margin of error), puts it out, and goes to sleep.
The third night they decide to search for fires before bed.
The engineer does a quick sweep of the house, convinces themself there are no fires, and goes to sleep.
The physicist searches a while longer, convinces themself there are no fires, goes to sleep.
The mathematician searches and searches, but can't prove there are no fires, and so can't go to sleep. After some thought, they set their own fire and go to sleep, thus reducing it to an already solved problem!
The man below says, "You must work in Management."
"I do," replies the balloonist, "But how did you know?"
"Well," says the man, "You don't know where you are, or where you're going, but you expect me to be able to help. You're in the same position you were before we met, but now it's my fault."
Surprisingly, I think the parent's answer is totally helpful, and never thought he "is a mathematician".
"How can a post hit frontpage with no comments?" "Because people upvoted it without leaving a comment." - I actually find the answer very enlightening.
A thing I've discovered (at least for me but YMMV) -- these tools seem attractive because of how they mimic how our real brains work - but that's exactly why they're not that useful. Your brain is better at what they do than these tools.
"but that's exactly why they're not that useful. Your brain is better at what they do than these tools."
It is still easier to parse diagramms, than it is to parse text. The real problem seems to be the extra work of creating the diagrams amd keeping them up to date.
>It is still easier to parse diagramms, than it is to parse text.
for you, for me it's not. As I must assume that I am not unique this means there are also others for whom diagrams are not useful and difficult to parse and for whom text is useful and easy to parse.
I think you could make an argument that this is objectively false; otherwise the human race would have "evolved" the written word into something "diagrammy."
It's one thing to have a diagram in your head, quite another to transmit that diagram to someone else's head -- or even to your own a month from now. That's where writing things down helps.
In my experience (UML) diagrams have 3 good applications:
1. As a visual aid during project planning meetings. Basically, in the stage where most initial requirements are on the table, it can really help focus a discussion on which architecture components to build, and how these should interact.
2. As a teaching aid for junior devs. The tough part is thinking of a viable architecture, and making UML diagrams is probably half the work a senior dev would put into actually writing the code. It is however really useful for teaching junior devs, because you can give them a direction while letting them figure out a lot of the details themselves.
3. In documentation, I think few things are as useful as having diagrams explain the components, behavior, data flow, chronology etc. They also look pretty and can "ease up" reading difficult documentations.
That said, except for point 3, and I think a tool like mermaid.js, which enables programmers to write diagrams fast and with little learning effort is much more appropriate.
In the last ten years (ever since The Incident) I can think of exactly one problem that seemed to require an arrows-and-boxes picture. It's the dependency graph for a project. I generate the picture from a Makefile.
Nobody actually uses the picture. We only work on one program in that system at a time, and all we need to know are its local inputs and outputs. The Makefile ensures there are no cycles.
It is admittedly somewhat unsatisfying to be unable to grok the whole thing at once. But that's the nature of almost everything in life.
21 comments
[ 3.4 ms ] story [ 58.3 ms ] threadI'm confused, and I love everything in the title...
https://unijokes.com/joke-6757/
I have no idea how an ad got upvoted so much. Don't look at me!
Their first night, a fire starts in the house. The engineer wakes up, sees it, douses it in buckets of water, puts it out, and goes to sleep.
The second night, another fire starts. This time, the physicist wakes up, sees it, calculates exactly how much water to use to put out the fire, pours exactly that much water on the fire (plus or minus experimental margin of error), puts it out, and goes to sleep.
The third night they decide to search for fires before bed.
The engineer does a quick sweep of the house, convinces themself there are no fires, and goes to sleep.
The physicist searches a while longer, convinces themself there are no fires, goes to sleep.
The mathematician searches and searches, but can't prove there are no fires, and so can't go to sleep. After some thought, they set their own fire and go to sleep, thus reducing it to an already solved problem!
"I do," replies the balloonist, "But how did you know?"
"Well," says the man, "You don't know where you are, or where you're going, but you expect me to be able to help. You're in the same position you were before we met, but now it's my fault."
"How can a post hit frontpage with no comments?" "Because people upvoted it without leaving a comment." - I actually find the answer very enlightening.
It is still easier to parse diagramms, than it is to parse text. The real problem seems to be the extra work of creating the diagrams amd keeping them up to date.
for you, for me it's not. As I must assume that I am not unique this means there are also others for whom diagrams are not useful and difficult to parse and for whom text is useful and easy to parse.
[1]: https://beta.plectica.com
1. As a visual aid during project planning meetings. Basically, in the stage where most initial requirements are on the table, it can really help focus a discussion on which architecture components to build, and how these should interact.
2. As a teaching aid for junior devs. The tough part is thinking of a viable architecture, and making UML diagrams is probably half the work a senior dev would put into actually writing the code. It is however really useful for teaching junior devs, because you can give them a direction while letting them figure out a lot of the details themselves.
3. In documentation, I think few things are as useful as having diagrams explain the components, behavior, data flow, chronology etc. They also look pretty and can "ease up" reading difficult documentations.
That said, except for point 3, and I think a tool like mermaid.js, which enables programmers to write diagrams fast and with little learning effort is much more appropriate.
Nobody actually uses the picture. We only work on one program in that system at a time, and all we need to know are its local inputs and outputs. The Makefile ensures there are no cycles.
It is admittedly somewhat unsatisfying to be unable to grok the whole thing at once. But that's the nature of almost everything in life.