4 ms·

I never enjoy seeing this line of argumentation pop up when we (as the computing industry) discuss practicalities of data structures and algorithm choices. I'v

by w1nk 6y ago

I never enjoy seeing this line of argumentation pop up when we (as the computing industry) discuss practicalities of data structures and algorithm choices. I've got a bit over twice your time in the industry and one of the things that is still very clearly on an upward walk is the size of our N's (think big O) in all of our applications and across all of our data structures. I'm not sure what kinds of applications you're building, but if any of your collections contain on the orders of thousands/10s/100s thousands of items, you really should be considering the impact of how you shape that data for consumption inside your application. You hint at the need to do so, arraylists being good enough until they're not and then hashmaps, etc. I think there is a pretty reasonable line between expecting our engineers and peers to pick proper containers for the data they're consuming without stepping over into purely 'academic' territory. Shutting down the discussions with 'well I've never had to use this' feels a bit icky and not a great way to advance any of the conversation.

pjmlp 6y ago
I think it is crucial to understand data structures and algorithms, more so than whatever way they exposed in each programming language, as Nicklaus Wirth puts it, Algorithms + Data Structures = Programs. However I fully subscribe to not care to apply to companies that disregard professional experience in name of clever leetcode answers, completely irrelevant for the position one is applying for.
bartread 6y ago
I tend to agree even though most of the time for me array like structures are often "enough". The thing is it's the 10%, the 5%, or the 1% of the time where you really see the benefit of using those structures. Many years ago I worked on the early versions of an autocomplete app called SQL Prompt. It needed to be able to filter 1000s, 10000s, or 100000s of items to make completion suggestions without interrupting your typing. It still remains the only time in my 20 year career I've had to implement a trie, but it was absolutely the right data structure for that job. Similarly I've used various kinds of tree and graph structures, different hashing schemes, and all kinds of other pointer - and even bit encoded - structures at different points in my career. It's very much in the minority of the work I've done, to the point where I definitely wouldn't do that well in an off the cuff leetcode interview, but I know what I need to look up when I come across a problem that might require a slightly more adventurous data structure or algorithm, and I've no qualms about using them. People act like picking the right algorithm or data structure up front is too much effort or will take too long, and (this really grinds my gears) casually trot out that tired line about premature optimisation. You know what really takes too long? Figuring out why the system you spent 3 years building runs like absolute garbage in production when all your customers and stakeholders are screaming about it, and you're haemorrhaging sales because of it.

by w1nk 6y ago

pjmlp 6y ago

I think it is crucial to understand data structures and algorithms, more so than whatever way they exposed in each programming language, as Nicklaus Wirth puts it, Algorithms + Data Structures = Programs. However I fully subscribe to not care to apply to companies that disregard professional experience in name of clever leetcode answers, completely irrelevant for the position one is applying for.

bartread 6y ago

I tend to agree even though most of the time for me array like structures are often "enough". The thing is it's the 10%, the 5%, or the 1% of the time where you really see the benefit of using those structures. Many years ago I worked on the early versions of an autocomplete app called SQL Prompt. It needed to be able to filter 1000s, 10000s, or 100000s of items to make completion suggestions without interrupting your typing. It still remains the only time in my 20 year career I've had to implement a trie, but it was absolutely the right data structure for that job. Similarly I've used various kinds of tree and graph structures, different hashing schemes, and all kinds of other pointer - and even bit encoded - structures at different points in my career. It's very much in the minority of the work I've done, to the point where I definitely wouldn't do that well in an off the cuff leetcode interview, but I know what I need to look up when I come across a problem that might require a slightly more adventurous data structure or algorithm, and I've no qualms about using them. People act like picking the right algorithm or data structure up front is too much effort or will take too long, and (this really grinds my gears) casually trot out that tired line about premature optimisation. You know what really takes too long? Figuring out why the system you spent 3 years building runs like absolute garbage in production when all your customers and stakeholders are screaming about it, and you're haemorrhaging sales because of it.