10 ms·
I'm not so jaded as to think that deep language understanding isn't a useful or good thing, and I'd like to think I have some myself. However, deep language und
by hacknat 13y ago
I'm not so jaded as to think that deep language understanding isn't a useful or good thing, and I'd like to think I have some myself. However, deep language understanding is not what separates the great engineers from the good ones.
In an interview, I would much rather hear a person say something about a statically declared variable with no initialization being poor code to leave behind for the next person than some arcana about the standard.
- thepicard 13y agoArguably if people have such strong understanding of things they will be better programmers too. I would prefer the person who knew what they were doing, because they also know _why_ weird things are weird, and have a better real understanding of what to do and not do. A person who just knows it's "bad code"--but not why--is almost certainly going to leave other bad code from lack of understanding. To pull an example from the slides, the virtual destructor: making that class virtual when it shouldn't is a waste of CPU cycles _and_ bad documentation for future developers.
- easytiger 13y agoIn c and c++ understanding these things can save you 1 day a week on average.
- pjmlp 13y agoI would say even more than that. C and C++ can make someone loose days to track down issues, in this day and age, where teams are distributed with lots of offshoring and various skill levels across development sites. My last C++ project was in 2006, since then I have only used C++ outside work. At work our focus has been in JVM and .NET languages. I don't miss playing the C++ fireman expert role that has to fix a stability problem created by someone in the other side of the planet.
- ateevchopra 13y agoExactly. Deeper you go, better you are. Better you are, better products you make. Just Simple mathematics.
- dmak 13y agoI'm not sure if I would say that a deeper knowledge of a language would make "better products".
- acron0 13y agoTotally disagree with this. I've worked with plenty of fantastic programmers who are basically worthless without the guidance of a good lead/producer/designer. Nonobligatory image to support statement: http://codinghorror.typepad.com/.a/6a0120a85dcdae970b0128776fec64970c-pi http://codinghorror.typepad.com/.a/6a0120a85dcdae970b0128776...
- ateevchopra 13y agoA programmer is not a designer. Both are completely different fields. What you are saying is that a shark(programmer) cannot fly like an eagle(designer). But it sure can swim. And vice-a-verse.
- acron0 13y agoHmmm, no, to mimic the analogy I am saying that just because something has teeth doesn't mean it can bite like a shark. Just because something has wings doesn't mean it can fly like an eagle. A budgie with a jetpack, however, can probably fly better than an eagle. Or something.
- Dylan16807 13y agoThat gui seems fine to me. It's ugly as sin, sure, but it has everything easy to find and clearly labeled. Ignore the parts you aren't using and you're good to go.
- aspensmonster 13y ago
- jamornh 13y agoHowever, I'd be concerned that the person with strong understanding of things will simply leave uninitialized static variables lying around in the code simply because they _knew_ it was always initialized to 0. It might work if your entire coding team has that innate understanding, but that is unlikely. Sometimes I think that having deep and expert understanding of a language may cause you to create code that other team members cannot understand... not on purpose, but due to your assumption that these are common knowledge (whether they should be or not isn't the issue.)
- mansr 13y agoStatic initialisers are a horrible example of "deep" knowledge. Not knowing how they work reveals not only ignorance of syntax but a fundamental lack of understanding of the entire programming and execution environment. Failure to understand your environment inevitably leads to confusion and bad decisions.
- lttlrck 13y agoI disagree that static initialization is deep understanding nor is it innate.
- Jare 13y agoA more common example is operator precedence, especially booleans. The precedence rules are easy and set in stone for decades, but always use parentheses to clarify, and I do not trust programmers that don't.
- thepicard 13y agoAgain, I think one with deep understanding would know that leaving it unset would result in zero, but also know that initializing it declares intent of the original author, and is thus useful.
- ksk 13y ago>In an interview, I would much rather hear a person say something about a statically declared variable with no initialization being poor code to leave behind for the next person than some arcana about the standard. Why are you forcing those two choices? One could be well-versed with the arcana AS WELL AS point out that bit about statically declared variable .. The problem IMO is most programmers cargo-cult/copy-paste/stackoverflow their way into programming jobs. No, that does not mean you never ask for help. No, that does not mean you never copy-paste. (Phew!) Its sort of like when you're learning math. Great mathematicians can understand the theory and just apply it to whatever problem they come across. Its because they have a very solid foundation underneath them. They wield their knowledge like tools and can just build anything with those tools because they understand those tools very well. Most students however just learn the patterns of the problems. And once they know enough patterns they can solve problems which fit into one of those pre-understood patterns. The people who are deeply knowledgeable about the language are good at knowing the boundaries of the language, knowing when you're using constructs that are not valid-syntax (which still compile), etc. The social aspect of 'good comments' , 'readable code' or 'maintainable code' is also important. You can have programmers that do both. Ofcource those programmers will never work for 'you' (not you, personally..) because most programming jobs are shitty and do not require programmers of that skill. You'll find them toiling away in anonymity, working in research labs, working on compiler optimizers or operating systems or some other domain with challenging technical problems.
- pjmlp 13y ago> You'll find them toiling away in anonymity, working in research labs, working on compiler optimizers or operating systems or some other domain with challenging technical problems. Sadly you are required to move for such jobs, which is not always an option.
- kamaal 13y agoAnd best of all is such things are not fashionable. Take a round of HN or any other place where programmers hang around. Take a note of how many articles, blogs posts, essays, tiny libraries, frameworks etc are written for languages like Javascript, or Python, or Ruby, or Java. Compare this with C. There is a degree of serious technical focus that languages like these demand for big projects. Embedded systems, Operating systems, Databases, compilers etc. A big part of software world uses these languages on a daily basis. But there is no where the kind of hipster crowd, these languages have the web frameworks or languages have. Even if you spend some time searching for resources on the net, there are few that teach deep C skills. There might be one or two books out there which haven't been updated in 2 decades. By and large, these are unfashionable fields to work in. The barrier to entry is really high, Success comes only with seriousness and application of well focused effort, mistakes are expensive and they warrant serious RTFM'ing the hard way- to write to some real serious code.
- ryandrake 13y agoI cant even remember how many times I've had to ask co-workers, "So, that's what you think your code will do... what does the standard say?" or, "Why did you use int there when the API spec defines the parameter as taking size_t?" or, "You think that code in your inner loop will compile to one machine instruction. Have you actually looked at the compiler's output?" and the looks/responses that I got. There seem to be very few programmers who understand the language & their compilers deeply enough, or even care to learn. These programmers are far more productive because they're not constantly guessing or assuming how their code might work.
- kerkeslager 13y agoThere's a deeper problem here, though. If you're asking, "So, that's what you think your code will do... what does the standard say?" the problem isn't really that they don't know the standard, it's that they've written the code in a way where it's ambiguous what it does. If I see static int i; in code, I'm going to change it to static int i = 0; even if I know that static integers are initialized to 0 in the standard, because I know that eventually someone will have to maintain the code who doesn't know that. I don't particularly care what the standard says there: the code shouldn't assume detailed understanding of the standard, which isn't realistically a valid assumption.
- devcjohnson 13y agoMe too reply... Don't get cute and always prefer to explicitly state in code what you get for free implicitly. The maintenance guy that follows behind you will be the one to espouse how clever you actually are. That's how I mentor junior engineers as a general rule.
- daenz 13y agoYou nailed it. Standards are nice and all, when they're perfectly unambiguous, and when everyone follows them exactly. That is not the real world. Writing code clearly and explicitly has far more reward for the effort put into it than learning all the standards pedantically.
- 13y ago