Comment by ActorNightly
4 days ago
The issue with pointers is that CS gets taught in a VERY bad way. The way it should be taught is starting with basic assembly on a microprocessor. This trains your brain to think of memory locations and data in memory.
Then when you start using pointers, it makes sense. If variable is a pointer, that means its a memory location. *variable is a way to get that data. Then arrays is just a wrapper around pointer arithmetic.
Whereas with CS, you learn about variables first, which is an abstraction on top of memory, and pointers don't make sense in this regard.
This is why any EE/ECE grads are much better developers than CS grads, because once you understand fundamentals
> This is why any EE/ECE grads are much better developers than CS grads, because once you understand fundamentals
This is largely not the case in my experience. They probably understand the lower level details of manipulating memory better, but there's a lot more to developing software than understanding that memory is a specific place.
>but there's a lot more to developing software than understanding that memory is a specific place.
Yep, and all of that is derivative from how to organize memory. Classes are just more fancy structs. Object creation is memory initialization. Processing flow and code reuse is recognizing memory access patterns. ETC and so on.
All of software engineering is not derivative of memory organization. Algorithm efficiency for example is entirely independent of physical memory implementations. Just because an algorithm may use a set or an array does not make it derivative.
1 reply →
Springer press has a book "Programming for Engineers and Scientists" or something like that, which is the first book I picked up to "self teach CS". From the get go pointers are involved and explained in this linear memory model and explained how they work on the stack and what not. I always thought this was the best approach; the reality is taught first, the abstraction (syntax) second. Not sure why so many programming books do it the other way.
> The issue with pointers is that CS gets taught in a VERY bad way. The way it should be taught is starting with basic assembly on a microprocessor. This trains your brain to think of memory locations and data in memory.
Can't agree with this enough. The moment i finally understood what pointers are was when I landed embedded job and during debugging session I looked at memory browser that showed my variable at exact address in memory. After that all about pointer arithmetic and even function pointers became clear as day. Something at least 3 teachers weren't able to explain clear enough.
You can do the same with regular, non-embedded programs in a debugging session
The book "Understanding and Using C Pointers: Core Techniques for Memory Management" by Richard M Reese, is a great way to learn pointers
> This is why any EE/ECE grads are much better developers than CS grads, because once you understand fundamentals
Hah, like fuck they are. The worst code I regularly have to review is written by EE grads. They have less of an understanding of pointers than the people in the office with a CS background.
I have probably like 2000 interviews under my belt across multiple companies. Your experience is an outlier. EE/ECE grads generally can write better optimized software - the only downside is that they aren't thinking as much of maintainability in design of interfaces, but thats a problem that is solved with LLMS