3 ms·
I think some of the commenters are missing the underlying message here. The point is that if you start out by using a really high-level language like Java or R
by Maro 18y ago
I think some of the commenters are missing the underlying message here.
The point is that if you start out by using a really high-level language like Java or Ruby or, going even higher, JavaScript then overall you won't be a very good engineer. To give an extreme example, JavaScript is Turing-complete, so you can re-implement anything in it, but I still wouldn't hire somebody who's only ever used JavaScript, even if he wrote an "OS" in it.
The reason is simple: sometimes you have to go down to the C/C++ level, sometimes you have to go down to the TCP/IP level, and so on. If you can't do that, you're not as valuable as someone who can, and you'll be outsourced.
I can even give an example from my own life: For 3 years I worked as a C/C++ programmer, where the work involved lots of debugging, dealing with memory managers, all kinds of fairly low-level crap. It wasn't rocket science, but it required a different mindset then working at higher levels. I hated it, because I wanted to do more interesting, more modern stuff. So I quit. The company desperately tried to keep me on, but I wouldn't. I went to work for a smaller company, like a startup, where I was given a small project to design and implement on my own, since I was hired as a senior programmer. Now, I'm not a particular fan of Java, but this project just cried out for it. 1 year later I was basically layed off (among other reasons) because the company realized that since the work I'm doing is not low-level, they can hire any "PHP-monkey" for 1/3 of what I make. I've basically been "outsourced", although not geographically.
So the lesson to engineers is: don't go work for small webby startups unless you're a co-founder, because most of the stuff they do requires moderate skills and thus they don't need to pay good engineers, plus they're always short on cash =)
- sofal 18y agoHow does "low-level" imply difficulty? Why are low-level programming tasks considered harder than tasks higher on the abstraction ladder? I don't think the difficulty of your job has anything to do with with the level of abstraction you're working at. If you hold job difficulty constant and vary the level of abstraction you'd probably see different salaries based on the supply and demand for programmers working at that level. Low-level is not superior to high-level. They each have their own different challenges. I don't think it is a bad thing to focus on high-level for your career. That does not mean spitting out half-baked PHP web pages. Of course it's helpful to have been exposed to low-level concepts at some point. This is the same tired old argument about how real engineers program in binary and you ignorant handicapped kiddies can only program in C. The only thing that changes is the level of abstraction at which the 'real engineers' work, and that just keeps going up. Somewhat related: http://www.yosefk.com/blog/low-level-is-easy.html http://www.yosefk.com/blog/low-level-is-easy.html
- Maro 18y agoThe point is, low-level, as the name implies, is at a lower level than high-level. So every once in a while, you'll run into problems at the higher levels, and you have to dig into lower level stuff to solve a problem. So what do you do if you cannot because you have no conception about the lower-levels / overall architecture? I've seen PHP programmers run into bugs and throw up their hands and yell "It just doesn't work! But the bug cannot be in my code!". Of course the bug was in their code, they just have no deep understanding of even their own environment.