You misspelled Ritchie. That aside, while what you said is true, it's necessary, but not sufficient. Senior engineers have to have a deeper understanding of how stuff works under the hood. I interview "senior" engineers who have no clue how string literals in C work; or what structure alignment and padding are, or why they're necessary; and lots of other nuts-and-bolts-type stuff. Even if you use higher-level abstractions, you have to understand what they're doing under the hood in order to make informed performance trade-off decisions.
I'd wager that in 90+% of the programming jobs out there you have literally zero need for information on how string literals in C work, or what structure alignment and padding are. Unless you work with C, or do some extremely performance sensitive low level work it really doesn't matter.
What matters in most jobs is getting stuff done, and that can be done by focusing on the actually important bits. Most of the software architecture today can solve the performance, availability and scalability issues etc. on a much higher level so that they don't have to care about the C-level details.
One sign of a senior engineer is knowing when to ignore the low level details and micro-optimizations and focus on the higher level architecture.
And witness code bloat and poor performance rampant both on-line and in apps. Getting poor code done just for the sake of getting it done might help you get to market, but not to remain there.
And you have to know the low level details in order to know when they can be safely ignored.
This forum seems to be quite annoying, people coming up with their hypothetical flaws in other people's arguments and glaring generalizations. You seem to be hinting that "if you don't know how string literals work in C your app is going to be bloated and have poor performance". That's simply garbage.
I quite specifically said you should focus on the important bits, and performance, scalability, good code quality and such are much more important than the low level internals of a programming language. These problems are generally solved at a MUCH higher level on the architectural design, except in a very few special cases.
In case of apps proper use of concurrency models and such is much more likely to affect your performance, than finding the most optimal way to handle strings. Similarly in the web it doesn't matter if your request takes a few more CPU cycles to complete if the architecture is solid and the system scales well to incoming traffic.
No, I literally never have to know the low level details of how strings are implemented in language X to know that it is more than likely unrelated to any performance issues I might be facing.
For example you don't have to know the low level details of how strings are implemented to know that loading a 2GB text file directly in RAM and trying to process it is not quite as efficient than processing it in small chunks.
You definitely do not need to know the low level details of C strings to know which bits are the important bits for you to focus on, unless you're working on some very low level implementations using C strings, and most people aren't.
That was merely one example. There are plenty of others. One is some developer was putting expensive function calls as arguments to a debug print function, so even when the debug printing was disabled, the function arguments were still being called (and their results discarded). In this case, he obviously didn't know that function arguments are always evaluated. That's a fairly low-level thing, but it can kill your performance.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You misspelled Ritchie. That aside, while what you said is true, it's necessary, but not sufficient. Senior engineers have to have a deeper understanding of how stuff works under the hood. I interview "senior" engineers who have no clue how string literals in C work; or what structure alignment and padding are, or why they're necessary; and lots of other nuts-and-bolts-type stuff. Even if you use higher-level abstractions, you have to understand what they're doing under the hood in order to make informed performance trade-off decisions.
I'd wager that in 90+% of the programming jobs out there you have literally zero need for information on how string literals in C work, or what structure alignment and padding are. Unless you work with C, or do some extremely performance sensitive low level work it really doesn't matter.
What matters in most jobs is getting stuff done, and that can be done by focusing on the actually important bits. Most of the software architecture today can solve the performance, availability and scalability issues etc. on a much higher level so that they don't have to care about the C-level details.
One sign of a senior engineer is knowing when to ignore the low level details and micro-optimizations and focus on the higher level architecture.
And witness code bloat and poor performance rampant both on-line and in apps. Getting poor code done just for the sake of getting it done might help you get to market, but not to remain there.
And you have to know the low level details in order to know when they can be safely ignored.
This forum seems to be quite annoying, people coming up with their hypothetical flaws in other people's arguments and glaring generalizations. You seem to be hinting that "if you don't know how string literals work in C your app is going to be bloated and have poor performance". That's simply garbage.
I quite specifically said you should focus on the important bits, and performance, scalability, good code quality and such are much more important than the low level internals of a programming language. These problems are generally solved at a MUCH higher level on the architectural design, except in a very few special cases.
In case of apps proper use of concurrency models and such is much more likely to affect your performance, than finding the most optimal way to handle strings. Similarly in the web it doesn't matter if your request takes a few more CPU cycles to complete if the architecture is solid and the system scales well to incoming traffic.
No, I literally never have to know the low level details of how strings are implemented in language X to know that it is more than likely unrelated to any performance issues I might be facing.
For example you don't have to know the low level details of how strings are implemented to know that loading a 2GB text file directly in RAM and trying to process it is not quite as efficient than processing it in small chunks.
Nobody is putting a gun to your head either to read it or reply. If it's that annoying to you, stop.
And I quite specifically said you have to know a breadth of things to know which bits are the important bits.
You definitely do not need to know the low level details of C strings to know which bits are the important bits for you to focus on, unless you're working on some very low level implementations using C strings, and most people aren't.
That was merely one example. There are plenty of others. One is some developer was putting expensive function calls as arguments to a debug print function, so even when the debug printing was disabled, the function arguments were still being called (and their results discarded). In this case, he obviously didn't know that function arguments are always evaluated. That's a fairly low-level thing, but it can kill your performance.