6 ms·

In The Mythical Man Month Fred Brooks said "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won

In The Mythical Man Month Fred Brooks said "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." I first read that on Guy Steele's site: http://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html http://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html

rjsw 6y ago
>I first read that on Guy Steele's site. It isn't Guy Steele's website. That page was written by him but the website is owned by Richard P Gabriel.
deleted 6y ago
[deleted]
monocasa 6y ago
Resaid by Linus with a bit more modern nomeclature (and Linus's trademark bluntness): > Bad programmers worry about the code. Good programmers worry about data structures and their relationships
- mgkimsal 6y ago
  > Bad programmers worry about the code And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules.
  - Koshkin 6y ago
    And that’s because it’s Bad Programmers who need help!
    - rapind 6y ago
      ... and "rules" for programming.
    - mgkimsal 6y ago
      but... they need help on data structures/relations and up front thinking about those issues, not where curly braces should go, or tabs-v-spaces.
      - wvenable 6y ago
        That stuff is hard! Better to just shove your data somewhere unstructured and then you don't have to worry about data structures and relations.
      - Benjammer 6y ago
        Right, because the hyper-focus on linting of the industry is the symptom here, it's not a misguided treatment for the underlying problem of bad programmers.
  - rumanator 6y ago
    > And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules. It seems to me that what you're actually seeing is an entire industry trying to eliminate all code-related issues, specially bike-shedding ones. This is patently obvious to anyone who was forced to waste their time in code review iterations discussing, say, where a brace should go and how many spaces someone should have added.
    - s17n 6y ago
      Nobody was ever "forced to waste their time" on this stuff. I have a simple rule - I don't comment on other people's style, and if people comment on my style, I just go with their suggestions. Problem solved.
      - ses1984 6y ago
        You've never been on a team with two people with opposing opinions I guess.
        Quekid5 6y ago
        Just out of morbid curiosity... have you actually experienced multiple 'seniors' giving conflicting code review comments about code style (of all things)? That sounds quite dysfunctional. (EDIT: Sure, nitpicks may differ, but...)
        ses1984 6y ago
        Style yes, formatting no. Worked with two developers who endlessly argued whether or not we should handle a certain bit of complexity in a certain layer or the next layer over, so we ended up handling it in both layers with the downsides of both.
        rumanator 6y ago
        > That sounds quite dysfunctional. No,it doesn't. It sounds like the expected outcome of not enforcing an established style with automated tools. All it takes is someone posting a merge request with a bracket out of place, or tabs instead of spaces which screws layout because yes IDEs have custom definitions and a dude happened to have opened a source file with an editor that wasn't properly configured. Boom, merge request receives two comments pointing out the bracket and how indentation is off. Congrats, about 20 minutes of your team's day are wasted because that's the time it takes to receive feedback from the merge request, be briefed on the remarks, go through the code and fix whitespaces, commit your change, push those changes, update the merge request, and wait for a team member to review your update. No drama. No dysfunctional team. No disagreement, even. But those 20 minutes of your life are lost forever.
  - burke 6y ago
    Bad programmers inflicting their worry upon the others.
  - deleted 6y ago
    [deleted]
  - furyofantares 6y ago
    > > Bad programmers worry about the code > And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules. I've come to a severe distaste for this good programmer/bad programmer mentality I've seen on the internet for, I guess decades now There is skill in programming, yes, obviously. But this simplistic divide seems to me to be more about putting one's own ego on the superior side. It leads to simplistic heuristics and flames rather than nuanced discussion In this case, in my opinion, linters/styling/rules help people to focus on what matters. And sure, with sufficient skill you might not need any of that to help you focus on what matters. But so what? It's better if we can make the trade more accessible, and can make it so people can focus on what matters with less experience
    - zekrioca 6y ago
      Couldn’t agree more. That’s the main reason why simple and accessible projects are praised most by general people.
  - Akronymus 6y ago
    I do like to use a linter to make it easier readable. But yeah, most of the architecture actually is based on how you store/structure your data. Code is just a result of how you implement the data.
screye 6y ago
as someone in ML, I see myself wanting the opposite. ML researchers drown their algorithms in huge tables of results, effectively spending time on "how well" rather than the "what". It often leads to things being added as long as they are better, with the conclusion of it being a gargantuan monster of models and hand-engineered changes. All with no one understanding how the whole things works as a single unit. Flow charts are incredibly effective as the top most layer of abstraction. Does the whole process, when viewed in an end-2-end manner, make sense ? We dive into the details only if it passes that sniff test of a flow chart. I might be missing the point being made here, but they can claw flowcharts from my cold dead hands.
- dllthomas 6y ago
  When Brooks says tables, I believe he means the internal data representation, rather than "tables of results".
- everybodyknows 6y ago
  "Flowchart" has historically, in Brook's time, meant "flow-of-control chart", and these usually degenerate into vast webs of minutia -- useless as abstractions. But perhaps you meant "flow-of-data between structures" -- in which case we have agreement on engineering, but a muddle on semantics.
mathattack 6y ago
An early mentor put it as “learn the data, which won’t change, before learning the fancy stuff on top, which will” That carried me very well.
- rumanator 6y ago
  Plenty of professional developers would benefit greatly if they read Domain-Driven Design.
  - mathattack 6y ago
    Interesting. What’s the best resource beyond the Wikipedia page?
    - bmaupin 6y ago
      "The term was coined by Eric Evans in his book of the same title." https://en.m.wikipedia.org/wiki/Domain-driven_design https://en.m.wikipedia.org/wiki/Domain-driven_design
nizmow 6y ago
I've recently started a job in a very complex business domain, but sadly they're using NoSQL for everything. I've known for a while about the technical tradeoffs of NoSQL, but until now I'd never experienced that the lack of expressiveness in the data store is a major obstacle to understanding what kind of data the code deals with and how it's related. The data's all there, but exploring it without a real schema is much more difficult.
vishnugupta 6y ago
> Show me your tables, and I won't usually need your flowchart A couple of years ago I spent quite some time trying to evaluate the tech stack (and general engineering culture) of merger/acquisition targets of my employer. It was quite a fun exercise, all said and done. I encountered all sorts; from a small team start up who had their tech sorted out more or less to a largish organisation who relied on IBM's ESB which exactly one person in their team knew how it worked!! I discovered this exact method during the third tech evaluation exercise. When the team began explaining various modules top-down and user-flows etc., I politely interrupted them and asked for DB schema. It was just on a whim because I was bored of typical one way session interrupted by me asking minor questions. Once I had a hang of their schema rest of the session was literally me telling them what their control and user flows were and them validating it. Since then it's become my magic wand to understand a new company or team. Just go directly to the schema and work backwards. Conversely, I've begun paying more attention to data modelling. Because once a data model is fixed it's very hard to change and once enough data accumulates the inertia just increases and instead if changing the data model (for the fear of data migration etc.,) the tendency is to beat the use cases to fit the data model. It's not your usual fail-fast-and-iterate thing.
- sova 6y ago
  Based on your experience it seems that #5 ought be first: "Data dominates"
- noisy_boy 6y ago
  I have learned to spend a good chuck on my effort and focus on data model - it is literally the heart of the application. Once that is done correctly, I've seen that the code almost just falls into place by itself.
gumby 6y ago
That’s Dick Gabriel’s site; he posted gls’s essay there with attribution (so you didn’t realize which site it is). He and quux are friends and collaborators.

rjsw 6y ago

>I first read that on Guy Steele's site. It isn't Guy Steele's website. That page was written by him but the website is owned by Richard P Gabriel.

deleted 6y ago

[deleted]

monocasa 6y ago

Resaid by Linus with a bit more modern nomeclature (and Linus's trademark bluntness): > Bad programmers worry about the code. Good programmers worry about data structures and their relationships

mgkimsal 6y ago
> Bad programmers worry about the code And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules.
- Koshkin 6y ago
  And that’s because it’s Bad Programmers who need help!
  - rapind 6y ago
    ... and "rules" for programming.
  - mgkimsal 6y ago
    but... they need help on data structures/relations and up front thinking about those issues, not where curly braces should go, or tabs-v-spaces.
    - wvenable 6y ago
      That stuff is hard! Better to just shove your data somewhere unstructured and then you don't have to worry about data structures and relations.
    - Benjammer 6y ago
      Right, because the hyper-focus on linting of the industry is the symptom here, it's not a misguided treatment for the underlying problem of bad programmers.
- rumanator 6y ago
  > And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules. It seems to me that what you're actually seeing is an entire industry trying to eliminate all code-related issues, specially bike-shedding ones. This is patently obvious to anyone who was forced to waste their time in code review iterations discussing, say, where a brace should go and how many spaces someone should have added.
  - s17n 6y ago
    Nobody was ever "forced to waste their time" on this stuff. I have a simple rule - I don't comment on other people's style, and if people comment on my style, I just go with their suggestions. Problem solved.
    - ses1984 6y ago
      You've never been on a team with two people with opposing opinions I guess.
      - Quekid5 6y ago
        Just out of morbid curiosity... have you actually experienced multiple 'seniors' giving conflicting code review comments about code style (of all things)? That sounds quite dysfunctional. (EDIT: Sure, nitpicks may differ, but...)
        ses1984 6y ago
        Style yes, formatting no. Worked with two developers who endlessly argued whether or not we should handle a certain bit of complexity in a certain layer or the next layer over, so we ended up handling it in both layers with the downsides of both.
        rumanator 6y ago
        > That sounds quite dysfunctional. No,it doesn't. It sounds like the expected outcome of not enforcing an established style with automated tools. All it takes is someone posting a merge request with a bracket out of place, or tabs instead of spaces which screws layout because yes IDEs have custom definitions and a dude happened to have opened a source file with an editor that wasn't properly configured. Boom, merge request receives two comments pointing out the bracket and how indentation is off. Congrats, about 20 minutes of your team's day are wasted because that's the time it takes to receive feedback from the merge request, be briefed on the remarks, go through the code and fix whitespaces, commit your change, push those changes, update the merge request, and wait for a team member to review your update. No drama. No dysfunctional team. No disagreement, even. But those 20 minutes of your life are lost forever.
- burke 6y ago
  Bad programmers inflicting their worry upon the others.
- deleted 6y ago
  [deleted]
- furyofantares 6y ago
  > > Bad programmers worry about the code > And yet, I see a whole swath of the industry hyper-focused on various linters/styling/rules. I've come to a severe distaste for this good programmer/bad programmer mentality I've seen on the internet for, I guess decades now There is skill in programming, yes, obviously. But this simplistic divide seems to me to be more about putting one's own ego on the superior side. It leads to simplistic heuristics and flames rather than nuanced discussion In this case, in my opinion, linters/styling/rules help people to focus on what matters. And sure, with sufficient skill you might not need any of that to help you focus on what matters. But so what? It's better if we can make the trade more accessible, and can make it so people can focus on what matters with less experience
  - zekrioca 6y ago
    Couldn’t agree more. That’s the main reason why simple and accessible projects are praised most by general people.
- Akronymus 6y ago
  I do like to use a linter to make it easier readable. But yeah, most of the architecture actually is based on how you store/structure your data. Code is just a result of how you implement the data.

screye 6y ago

as someone in ML, I see myself wanting the opposite. ML researchers drown their algorithms in huge tables of results, effectively spending time on "how well" rather than the "what". It often leads to things being added as long as they are better, with the conclusion of it being a gargantuan monster of models and hand-engineered changes. All with no one understanding how the whole things works as a single unit. Flow charts are incredibly effective as the top most layer of abstraction. Does the whole process, when viewed in an end-2-end manner, make sense ? We dive into the details only if it passes that sniff test of a flow chart. I might be missing the point being made here, but they can claw flowcharts from my cold dead hands.

dllthomas 6y ago
When Brooks says tables, I believe he means the internal data representation, rather than "tables of results".
everybodyknows 6y ago
"Flowchart" has historically, in Brook's time, meant "flow-of-control chart", and these usually degenerate into vast webs of minutia -- useless as abstractions. But perhaps you meant "flow-of-data between structures" -- in which case we have agreement on engineering, but a muddle on semantics.

mathattack 6y ago

An early mentor put it as “learn the data, which won’t change, before learning the fancy stuff on top, which will” That carried me very well.

rumanator 6y ago
Plenty of professional developers would benefit greatly if they read Domain-Driven Design.
- mathattack 6y ago
  Interesting. What’s the best resource beyond the Wikipedia page?
  - bmaupin 6y ago
    "The term was coined by Eric Evans in his book of the same title." https://en.m.wikipedia.org/wiki/Domain-driven_design https://en.m.wikipedia.org/wiki/Domain-driven_design

nizmow 6y ago

I've recently started a job in a very complex business domain, but sadly they're using NoSQL for everything. I've known for a while about the technical tradeoffs of NoSQL, but until now I'd never experienced that the lack of expressiveness in the data store is a major obstacle to understanding what kind of data the code deals with and how it's related. The data's all there, but exploring it without a real schema is much more difficult.

vishnugupta 6y ago

> Show me your tables, and I won't usually need your flowchart A couple of years ago I spent quite some time trying to evaluate the tech stack (and general engineering culture) of merger/acquisition targets of my employer. It was quite a fun exercise, all said and done. I encountered all sorts; from a small team start up who had their tech sorted out more or less to a largish organisation who relied on IBM's ESB which exactly one person in their team knew how it worked!! I discovered this exact method during the third tech evaluation exercise. When the team began explaining various modules top-down and user-flows etc., I politely interrupted them and asked for DB schema. It was just on a whim because I was bored of typical one way session interrupted by me asking minor questions. Once I had a hang of their schema rest of the session was literally me telling them what their control and user flows were and them validating it. Since then it's become my magic wand to understand a new company or team. Just go directly to the schema and work backwards. Conversely, I've begun paying more attention to data modelling. Because once a data model is fixed it's very hard to change and once enough data accumulates the inertia just increases and instead if changing the data model (for the fear of data migration etc.,) the tendency is to beat the use cases to fit the data model. It's not your usual fail-fast-and-iterate thing.

sova 6y ago
Based on your experience it seems that #5 ought be first: "Data dominates"
noisy_boy 6y ago
I have learned to spend a good chuck on my effort and focus on data model - it is literally the heart of the application. Once that is done correctly, I've seen that the code almost just falls into place by itself.

gumby 6y ago

That’s Dick Gabriel’s site; he posted gls’s essay there with attribution (so you didn’t realize which site it is). He and quux are friends and collaborators.