21–30 of 309 posts
So what are some examples of those problems? No one can really tell you if this is something unusual or not without having an idea of what the problems are. And CS courses and algorithms vary from pretty simple to actually really hard.
Earlier quoted context omitted.
Knowing things like binary trees, heaps, B-trees, queues etc. are not history. They are fundamental to writing applications. Using one data structure or a particular sort method will make your application much faster. Supposed you have had a billion elements to sort, but you knew every element in that array is between 1-100. I mean a bucket sort would be much much faster than using a quick sort.
> They are fundamental to writing applications. That's funny, I must not have written any applications in the past 14 years. (Seriously though, I read one algorithms book when I was 16, and used those algorithms approximately... five times... in the past decade and a half)
Earlier quoted context omitted.
Knowing things like binary trees, heaps, B-trees, queues etc. are not history. They are fundamental to writing applications. Using one data structure or a particular sort method will make your application much faster. Supposed you have had a billion elements to sort, but you knew every element in that array is between 1-100. I mean a bucket sort would be much much faster than using a quick sort.
> They are fundamental to writing applications. That's funny, I must not have written any applications in the past 14 years. (Seriously though, I read one algorithms book when I was 16, and used those algorithms approximately... five times... in the past decade and a half)
I remember being a programmer before studying formal computer science, I definitely wrote some slow and bad code that I just didn't know could be much better, and/or simpler.
A lot of "classic" problems are so embedded into CS professors that they don't even see them as problems anymore (lazy caterer, pick's theorem, etc) so if you didn't study these classics explicitly in school you have to discover them on your own.
(2) Doing similar things over and over may not transfer experience to other things.
Earlier quoted context omitted.
> They are fundamental to writing applications. That's funny, I must not have written any applications in the past 14 years. (Seriously though, I read one algorithms book when I was 16, and used those algorithms approximately... five times... in the past decade and a half)
It's certainly good if you know how trees and linked lists are implemented, but as you point out most app devs are working on a higher level of abstraction. All of that nitty gritty implementation details are already available to application developers in convenient, well tested wrappers. You can easily go through your entire career without ever having to worry about how doubly-linked lists or B-Trees actually work.
Until they don't, because for some reason the abstraction cannot be applied in a particular scenario (or actually could be, but it's not understood), or just does not scale anymore.
I've used this analogy before. When you first start, imagine that you are standing on the ground. There are lots and lots of things you can see. There is a lot to learn. Eventually, you get pretty good at everything you can see. But as you get better, hopefully you start travelling upwards. It broadens your horizons and you can see more.
Often this is an unsettling feeling. You think, "I've worked so hard, and there is still more???" Some people give up, "I'm fine doing what I was doing. This other stuff isn't necessary!" However, this will lead to an early exit from this career. Being a programmer is about always learning and always expanding. Things change so fast and you have to keep up.
As you learn more, you keep travelling upwards, expanding your view even more. It's amazing because when you thought there was a lot when you started, as you move upwards, the amount of new stuff you can see starts to accelerate. It's easy to get overwhelmed. Don't worry, though. Just pick stuff you are interested in. Don't rush. You have plenty of time. However, don't stop either.
Eventually, you will get so high that the earth is just a round ball. For a long time nothing will seem to change. You'll probably think, "I've learned everything! I'm amazing!". And then you will run across the moon. "Woah... I know nothing". That's what it's like when you start to get more senior. You keep expanding your view, but things don't seem to change, until you see some new island of stuff that you never really imagined before. Again, it's easy to give up and to think, "I'm a senior developer and I'm world class in X. What do I need with the moon?" But that's a trap. It's the easiest way to ensure that you are seen as the strange old doofus in the corner using crappy, ancient techniques. Learning, learning, learning every day for the rest of your life. That's what being a programmer is.
I hope that helps!
Think of it this way: application development, software engineering, and computer science (and data science and ... etc) sometimes use the same tools but are all different disciplines. Universities traditionally focused on Computer Science and their graduates would often need a lot of grooming before they could really be independently and reliably productive in the commercial words of application development or softw…
But it doesn't need particular deep CS knowledge. There are people that program for 30 years, get paid six figure salaries and "never needed that shit". And they're really good at their jobs. But sometimes (less often than it's required to pass for an interview) you're really expected to dig that deep because you need to solve problems that existing frameworks and libraries don't handle.
Background: learning basic CS stuff after 20 years of programming professionally. You will never learn it on the job.