Good programmers worry about data structures and their relationships
Posted by fagnerbrack@reddit | programming | View on Reddit | 39 comments
Posted by fagnerbrack@reddit | programming | View on Reddit | 39 comments
pnedito@reddit
Good programmers build a base abstract interface to their data structures and update the underlying structures as/when needed while keeping the abstract interface intact.
joey_nottawa@reddit
This is a truism to most seniors, but when I was doing my internships this would have helped immensely.
When you're starting out, it's often pretty easy to get in the habit of piling new members or relationships into your datatypes as you better understand the requirements. This strategy really starts to fall apart when you have multiple developers on a project or working on a project impacting multiple teams.
A simple example I recall getting in a Snap interview was how to structure the data for a GUI text editor. You've got a big blob of text which you'd like to draw in a canvas of some size, what's the best way to do so while still being mindful of space and time efficiency? It's an interesting problem to think about before going and reading into what the now idiomatic approaches are.
Empty-Win-5381@reddit
When you get into the need of having to communicate your work, you start to make it simpler and more understandable
joey_nottawa@reddit
Yep, big time. I think working on a team and having in-person technical discussions on your design is a necessary step for any good engineer. You can get really far studying by oneself, but there reaches a plateau where more meaningful growth requires other people.
Empty-Win-5381@reddit
It does. And there's also room to question what it really even means to study by oneself. After all, such self study relies on the work of others presumably and is pretty much definitely always the case. The attempt to bring so much merit to oneself by viciously avoiding the "collective" path is just a severe misaprehension of reality
FletcherTheMouse@reddit
Mmm, I agree with your last part, but I find that I work very well when I work (Almost struggle at times) through a problem. It's not that I avoid other people, it's just I find critical parts of the problem rather enjoyable.
That being said, I do enjoy the 'right' people to study with (or 'against'). It's not the easiest thing in the world to find though: A good study partner.
Empty-Win-5381@reddit
I Loved what you said in the way you put it
photon_lines@reddit
For anyone needing a quick review or refresher of some key data structures - I made a visual focused cheat sheet and overview available here: https://open.substack.com/pub/photonlines/p/visual-data-structures-cheat-sheet?utm_campaign=post&utm_medium=web
MaverickGuardian@reddit
This could be extended in a way that when you realize you need to refactor your code, it's usually better to refactor data structures first and fix code to work with that. Most business cases won't require efficient algorithms ever. Just efficient data.
agustin689@reddit
Which is why all dynamic languages are useless by definition.
The very first thing I always do when starting anything is to define the data structures I will use, and their relationships, in the form of static types.
I cannot even fathom how would anyone do it in any other way, other than guessing and vomiting code against the wall until it sticks, which is what I think most dynamic language bros do anyway.
Thin-Walrus-3052@reddit
I agree
Thin-Walrus-3052@reddit
Good programmers worry about their relationships.
rashnull@reddit
Who cares?! We live in the world of AI generated gobbledygook and fast deadlines!
Empty-Win-5381@reddit
Lmao. Is that your own World?
clintp@reddit
Old news:
-- Fred Brooks, The Mythical Man Month 11975
BounceVector@reddit
(Psst, typo, you meant 1975, not 11975)
Captator@reddit
He was ahead of his time )))
Empty-Win-5381@reddit
Late to his time, a time traveler
Empty-Win-5381@reddit
Interesting!! You're an old timer?
Full-Spectral@reddit
They don't NOT worry about them. But that might be far from the most important consideration, depending on the type of code being written. Honestly, for the stuff I write, which are large scale, bespoke systems, the real challenges are creating consistent mechanisms that can be used consistently throughout, logging strategies, I/O strategies, interface design, large scale project structure, naming things, safety, being no more complex than required, etc...
To me, data structures tend to be internal details that can be changed later if needed, and considerably less important until or if my original choice is found to be lacking.
I think a lot of this point of view comes from the fact that so many people work in cloud world these days and see that as 'how software is', that it's all about complex data relationships and databases and being able to feed data to phone junkies as fast as possible and all that. Not necessarily the case for the poster her, but it's something I see a lot. If that's all you've done your own career, it can be easy to see those needs as paramount in general.
Mickl193@reddit
„Considerably less important until or if my original choice is found to be lacking” Couldn’t agree more, start as stupid simple as possible considering all your current requirements and iterate only if the current solution is lacking, don’t overengineer, don’t overoptimize, focus on the things that are actually important day to day like observability, cluster resilience etc. And not chasing milliseconds for no reason.
Many_Particular_8618@reddit
Talking is easy. Real code is designing. Design is programming. Programming is testing. Testing is giving proof. Giving proof is reasoning.
glznzuriel@reddit
Lean 4 all the way!!!
cheezballs@reddit
Another "no duh" blogspam article
vom-IT-coffin@reddit
Tell that to my team.
codeprimate@reddit
ALWAYS model the problem domain's data schema before writing a line of code.
CS 101
Emotional-Courage-26@reddit
A project well begun is a project half done
Glass_Abrocoma_7400@reddit
Learned the hard way
lood9phee2Ri@reddit
bad programmers worry about data structures and their relationships.
smooth programmers worry about data structures and their relationships.
wan programmers worry about data structures and their relationships.
bisexual programmers worry about data structures and their relationships.
golfing programmers worry about data structures and their relationships.
Full-Spectral@reddit
Good programmers help their elderly neighbors take out the garbage.
Knaapje@reddit
Are you okay?
lood9phee2Ri@reddit
fine, I just find it a pretty vacuous thing to say, let alone write a whole blogpost about.
FistBus2786@reddit
You're right because we have no objective quantifiable definition of a "good programmer". So an article claiming good programmers do this or that is meaningless, since we can't even agree on what a good programmer is.
The underlying assumption of such articles is that the author is a good enough programmer to recognize others of equal or higher level of goodness.
Knaapje@reddit
I mean, I agree to the extent that the point seems so obviously true that it doesn't make me compelled to read the article, but nothing is ever worth not writing about - we might just not be the target audience. Put differently, this might just be the eye-opening article a junior or novice visiting this sub needed to reevaluate their way of working - no need to gatekeep or criticize knowledge sharing because the point is already obvious to others.
SneakyDeaky123@reddit
Bad programmers don’t care about what good programmers are doing
Good programmers worry about what bad programmers are doing.
n3phtys@reddit
There is some truth in this. Most younger or average programmers do not see data structures as variables to change and try to encode everything into explicit procedural code that moves from A to B. ORMs make this worse, because A and B literally become ORM CRUD repositories.
It takes a lot of experience to see code and data both malleable. Uncle Bob in his previous Primeagen interview talked about this - higher abstraction languages and metaprogramming helps a lot. If you can encode more and more of requirements into the datastructure and meta informations, the remaining code becomes trivially easy and sometimes clear from intuition alone.
One big problem is that especially modern frontend frameworks HATE this. With more and more developers starting or making mostly a living with them, they heavily encourage very procedural code (though most often wrapped in reactive primitives at least). Metaprogramming or data structures is the field of the framework devs, not the application devs.
But how will those developers ever actually use better datastructures? Or even learn about utilizing them in general?
burnmp3s@reddit
I'm not sure if it makes me a bad programmer but if a dictionary has a relationship with a binary heap I would say that's none of my business
realPrimoh@reddit
Extra time spent in figuring out proper data structures, whether it be proto or DB schemas has always paid off down the road IMO.
Protos are a bit nicer since their fields are append-only (but you can do the same for DBs technically), but still, migrations are a pain especially when multiple teams are involved.
fagnerbrack@reddit (OP)
Condensed version:
This post discusses how great programmers focus on the importance of data structures and how they relate to each other. It emphasizes that the way data is organized and the connections between different pieces of information are critical for designing effective software. The content delves into real-world software engineering concepts, particularly around managing data, and explores how thoughtful structuring can prevent future challenges in scalability and performance. The post also highlights the significance of understanding the core principles of how data is handled, offering practical insights for improving software development skills.
If the summary seems inacurate, just downvote and I'll try to delete the comment eventually 👍
^(Click here for more info, I read all comments)