I first read that on Guy Steele's site: http://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html
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.
> Bad programmers worry about the code. Good programmers worry about data structures and their relationships
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.
(If multiple people are arguing back and forth in code review -- when following the WIR rule -- tell them about the WIR rule and that should settle it. If not, you have bigger problems in your team.)
That sounds quite dysfunctional.
(EDIT: Sure, nitpicks may differ, but...)
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.
Unfortunately those also have significant downsides around large-scale refactoring.
What I always do (and advise other code reviewers to do) is to just ask themselves: Does this code follow the local style in the file being edited?
That simplifies things greatly, IME.
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.
Why though? I am not going to go with suggestions if they make the code less readable for me!
Just make decision and get on with your lives. Have some kind of linter check for inconsistencies before any human review.
If an organization cannot make a decision on inconsequential bike-shedding it is dysfunctional.
I personally get super annoyed when people keep pointing out style issues, but our CI tool can notify me of issues with my commit until the end of time without me getting frustrated with it.
This sort of baseless assertion has no bearing in reality. In a project that hasn't adopted any linting tools and automatic style checks, all it takes is a misconfigured editor to post a change request that fails to comply with style guides. These sorts of absolutes show a complete detachment from reality and absence of any practical experience in the field.
But you are making these baseless assertions yourself?
Obviously you can have issues if you are not using automated linting (both in the editor and on CI). That’s part of the failure.
It also remove all debate in PRs about style and formatting.
(note: before prettier, I was fairly particular about how I formatted my code, and I disagreed with prettier in some cases, but now, I love having one less thing to think about)
> 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
It isn't Guy Steele's website. That page was written by him but the website is owned by Richard P Gabriel.
That carried me very well.
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.
But perhaps you meant "flow-of-data between structures" -- in which case we have agreement on engineering, but a muddle on semantics.