Knowing (in Python, for example) when to use a list, a tuple, a dict, a set or a deque makes a rather big difference, and is a skill I probably use almost every day at work.
See also this tweet from last night for a real-world application:
back
1 comments
Interesting. Thanks for that. Curious what kind of work that is - do you have real-time critical apps that you have to tweak milliseconds or watch RAM consumption carefully?
I sometimes feel like I could be lazy, but I just never seem to need to deal with that type of tuning due to the nature of my work which is business apps. Don't get me wrong, I do deal with performance tuning - but never at the data structure or algorithm level. I would say I spend time architecting to preventing huge data structures to begin with. Also SQL tuning, interface design and things that I have to deal with. The low-level stuff like sorting algorithms are just built into whatever language I'm using and they don't seem to be a bottleneck.
I'm co-founder at a hedge fund startup. Much of our code may not be extremely sensitive to small delays, but picking the right datastructures makes a big difference even on small workloads. And we do have some big simulations where performance definitely counts. But mostly, picking the right datastructure isn't that hard most of the time, and is a painless kind of optimization.
> I just never seem to need to deal with that type of tuning due to the nature of my work which is business apps.
and
> Also SQL tuning
Are at odds with each other. Although the terminology is different, you are in fact doing it if your SQL tuning includes things like adding an index and selecting the right kind of index for your workload (every database has different names, but the different kinds usually include hash, btree, and a couple of others).
I suppose that is true. Indexing is something I deal with but I guess I don't really think much about the underlying storage mechanics.