Hacker News new | ask | show | jobs
by JamesonNetworks 1068 days ago
Another of these is: amateurs focus on code, professionals focus on the data model.
6 comments

I think this statement is actually much more true than the titles' statement (for programming).
Speaking as a pro, or so I like to think, I'm not sure what you mean by data model. Are you simply talking about data structures?
Data structures is often part of the model, but that's not what the "data model" is all about. It's about having a good overview of how everything is connected.

https://en.wikipedia.org/wiki/Data_model

Um...I think his point is clear? First, you understand your data, and decide how to represent it. Only then can you write code to work with that data.

Poor programmers dive into methods and algorithms, and then try to force their data to match. Which almost never works.

Pretty much. A manager early in my career would say “get the data model right and the code will write itself” and I’ve found that to be mostly true.
It wasn't clear. If he meant data structures then say data structures. If he meant something different or broader by 'data model' then I don't know what that was.

I value plain, simple code and equally plain, simple writing. I am becoming dismayed at the trend towards fancy labels on basic things. A while back someone talked about 'affordances' in C# which sent me into a tailspin because I thought there was some significant area of the language I'd never encountered. Turns out he just meant attributes and methods.

"Data model" isn't a confusing term, and "data modeller" is a profession. They work on data models.
"modeling your data" is terminology that I encountered before, not sure why you find it unusual /shrug
@pessimizer, @SuperCuber - So educate me. Let's base it on something I've actually done, a code analyser. For this you parse the code into an AST, and to deal with lexical scopes of declarations of procedures/variables etc. you have a stack of symbol tables.

So we've got a tree (the AST), we've got a symbol table for the current scope (a hash table of <id, info> pairs), and we have a stack of symbol tables (a stack).

A tree, a hash table and a stack. Those are data structures. What more needs to be added to this definition to turn it from "data structures" into a "data model"?

Firstly this is a serious question, secondly I have a great deal of experience of defining data structures to solve problems, so I can't see what adding an abstract term is doing.

You could say that the extra something is the specification/maintenance of the correct interrelationship between those data structures (and I'd agree), and there's a word for that: it's called 'code'. I genuinely don't understand what you're getting at and I'd genuinely like to know.

And no answer :-( It does rather defeat the point of discussion here if people say things they won't back up. I don't know if I've changed your mind, you certainly haven't given me any reason to change mine, so why post?
Clever architecture can almost always beat clever coding, languages and frameworks.
Yes! And amateurs focus on tools, pros focus on execution/getting it done.
Amateurs would disagree
Good data model means less code