For me 'good' includes well named data-structures, I stress A LOT over names, it's important for me to create meaningful names that are consistent with what the company refers to in their processes and then I keep the names consistent throughout the code base. I reach out to the business partners and try and nail down the nomenclature. It is extremely helpful to have the code match the business processes; everyone is speaking the same language and it avoids having to do a translation.
I'm fascinated a lot at how each worth words are expressed by the author, just make a grasp and experience it daily in working life is really improving me a lot
I don't get this at all, so maybe I'm just one of those bad programmers.
I think both code and design (data + data structures + relationships) are important. I was recently in a C# codebase, and it used very good data structures and relationships. It had really good architecture and design in fact. It even had stellar performance and successfully provided a solution to the problem it was intended to solve. However, its codebase was tragic to maintain.
I've found the single most important metric in a codebase is maintainability. Good data structures and relationships can help with that. This doesn't imply that bad code won't obfuscate most of the good and end up costing maintainers and companies dearly on time and money.
I think the quote meant that data design is super important and while it doesn't necessarily mean the codebase itself is pristine, it does mean that the codebase would be worse off without good data design.
The main thing is that, like you said, good data structures and relationships help with maintainability. However, bad code is much much easier to fix compared to bad data design, usually because dependencies at that point are so deep-rooted that the migration to better designed data is painful.
The higher up in the funnel you can solve the problem, the easier things become downstream. It's a critical piece of software architecture and the article describes this well with the data & data structures analogy!
I agree! Nice article. This is the reason I write about data structures and focus on having good data structures, not on having short code. This article summarises the point of my entire stack haha
Thanks for the article. It would be great if you also have code example.
the irony tier of this comment is infinite ...
I'm not. As a junior level programmer, some graphic will help me understand thing easier.
exactly
For me 'good' includes well named data-structures, I stress A LOT over names, it's important for me to create meaningful names that are consistent with what the company refers to in their processes and then I keep the names consistent throughout the code base. I reach out to the business partners and try and nail down the nomenclature. It is extremely helpful to have the code match the business processes; everyone is speaking the same language and it avoids having to do a translation.
I'm fascinated a lot at how each worth words are expressed by the author, just make a grasp and experience it daily in working life is really improving me a lot
Can’t agree more.
I don't get this at all, so maybe I'm just one of those bad programmers.
I think both code and design (data + data structures + relationships) are important. I was recently in a C# codebase, and it used very good data structures and relationships. It had really good architecture and design in fact. It even had stellar performance and successfully provided a solution to the problem it was intended to solve. However, its codebase was tragic to maintain.
I've found the single most important metric in a codebase is maintainability. Good data structures and relationships can help with that. This doesn't imply that bad code won't obfuscate most of the good and end up costing maintainers and companies dearly on time and money.
I don't think you're wrong at all!
I think the quote meant that data design is super important and while it doesn't necessarily mean the codebase itself is pristine, it does mean that the codebase would be worse off without good data design.
The main thing is that, like you said, good data structures and relationships help with maintainability. However, bad code is much much easier to fix compared to bad data design, usually because dependencies at that point are so deep-rooted that the migration to better designed data is painful.
The higher up in the funnel you can solve the problem, the easier things become downstream. It's a critical piece of software architecture and the article describes this well with the data & data structures analogy!
I agree! Nice article. This is the reason I write about data structures and focus on having good data structures, not on having short code. This article summarises the point of my entire stack haha
https://kanaye.substack.com/
Loved the piece, Leonardo and thanks for the shout-out as well!
Examples?