I recommend reading Robert Gossbach's fiction book _A Shortage of Engineers_ for a funny and ironic hardware-centric view of this.
I once got a roomful of laughter by quipping, "What we need are some more fat engineers with beards here." Where there is laughter there is often a painful truth.
The fact that java was included in the list is actually just an indication that the author is a java programmer, and he wishes that he were in the guild O:-)
John lives in the basement of the UCLA center for Health Sciences. It's is actually a maze. You can get very lost very easy. There are street signs inside it's halls. John is deep inside the foundations of the building. John is part of that foundation, so it fits.
John knows. What? Well, just about nothing he'll tell you. But it is a lie. John is part of the cadre of people that know what they do not know, and John knows it's a lot. But that is the trick, John knows that he is a moron. This is because John has just about seen it all.
Here's an example. On labtop centrifuges, the transformer for the high velocity motor sits right under the catch lid for liquids on most models. Not the best design, but if it fries, just about anyone will know. And pay. They cost a lot, as they need to be precise. So John repairs them for the UCLA researches that can't be bothered. But there is a thing that John knows, because he's part of the cadre.
If nitric acid, common in organic chemistry, drips on the transformer and fries it, something happens. John knows this because one day he was soldering on the PCB to repair the transformer and the whole ground trace went missing in about one second. John lost his eyebrows to find this out. Turns out, the nitric acid reacts with the various chemicals in the transformer and the PCB. The PCB gets eaten and becomes, well, a very good way of removing hair on your face. The whole board gets contaminated with a drop and you have to very very careful when soldering thereafter.
John knows this. Not really anyone else but who John talks to knows this. And since John is part of the cadre, not really anyone knows. But all the guys, and they are universally men, know. And they care.
The cadre is full of the people the OP talks about. Large shirts holding in bellies of Tab and Fritos, heavy breathing, glasses, a lot of Weird Al and Dr. Demento trivia. These guys are insufferable at first. They couldn't hold a girlfriend, let alone a wife, to save their lives. They know nothing of sports or chrome. Their lives are their work. The people upstairs from John are completely reliant on John, and they hate it. John isn't unfriendly, in fact, hes a great guy. But Lord almighty, he will talk your ear off.
The fact that nitric acid is a strong, very corrosive acid (pKₐ of about -1.3) is not exactly esoteric; a high school student taking A.P Chemistry understands that.
The story about nitric acid reminds me of my favorite quote by Ira Remsen about the value of experiments in a laboratory:
❝While reading a textbook of chemistry I came upon the statement, "nitric acid acts upon copper." I was getting tired of reading such absurd stuff and I was determined to see what this meant. Copper was more or less familiar to me, for copper cents were then in use. I had seen a bottle marked nitric acid on a table in the doctor's office where I was then "doing time." I did not know its peculiarities, but the spirit of adventure was upon me. Having nitric acid and copper, I had only to learn what the words "act upon" meant. The statement "nitric acid acts upon copper" would be something more than mere words. All was still. In the interest of knowledge I was even willing to sacrifice one of the few copper cents then in my possession. I put one of them on the table, opened the bottle marked nitric acid, poured some of the liquid on the copper and prepared to make an observation. But what was this wonderful thing which I beheld? The cent was already changed and it was no small change either. A green-blue liquid foamed and fumed over the cent and over the table. The air in the neighborhood of the performance became colored dark red. A great colored cloud arose. This was disagreeable and suffocating. How should I stop this? I tried to get rid of the objectionable mess by picking it up and throwing it out of the window. I learned another fact. Nitric acid not only acts upon copper, but it acts upon fingers. The pain led to another unpremeditated experiment. I drew my fingers across my trousers and another fact was discovered. Nitric acid acts upon trousers. Taking everything into consideration, that was the most impressive experiment and relatively probably the most costly experiment I have ever performed. . . . It was a revelation to me. It resulted in a desire on my part to learn more about that remarkable kind of action. Plainly, the only way to learn about it was to see its results, to experiment, to work in a laboratory.❞
Man, what about Clojure, Scala, Go, Node.js, Hadoop and Spark? I wanted to join the elite group and screw those JS/PHP monkeys (JS in the backend with Node callbacks are honorary elite members), so I invested so much time learning those - only to understand C is the only l33t!
To tell you a secret, C is too hard for me because all of the system programming, de-referencing pointers make my head spin. Their threading, socket multiplexing I usually can't understand until Node.js or Scala introduces something similar to it and boils it down for me. Bah, seg-fault again!
Well, I hope someone makes a Codeacademy or Railcast for C very soon for a plebe like me. But only give select invitations as not to dilute the membership, I don't want to belong to any club that will accept me.
First, don't call people "monkeys". Second, just enjoy programming and tinkering for its own sake. There is no rush to gain membership into some kind of mythical elite crowd. In fact, that label itself, "elite", is derogatory, and ascribing it to your would-be mentors might just turn them off.
C is not hard. You will probably have harder time understanding the vocabulary, than the concepts themselves. Read Beej's C and network programming guides. Get a Free UNIX, download the source for simple utilities and tinker.
Don't confuse C programming with Unix systems/network programming. You can write C to write anything, but it excels at low-level stuff. Also, don't scoff at higher-level languages; you can cover a lot more ground and learn more using higher abstraction. Go and Rust should be preferred to C at this stage. Clojure and Scala are yet higher level and support more paradigms. Hadoop and Spark and domain-specific tools, not really programming languages. Node is probably good for something, but I have no experience with it.
You know what the great engineers that I know have in common? They're great at engineering. Once you start looking at other qualities, they are pretty diverse. Some have families, others are single. Some play trading card games, others write musicals. Some wear ironic T-shirts, others dress "up" (not exclusive of course). Some fly planes, others ride bikes. Some are straight white dudes with kids, others are transgender people in polyamorous relationships.
You know what else is interesting? They come from everywhere, and every one of them had a first gig somewhere, where nobody realised how brilliant they were (with some rare exceptions).
Great people are all around you. Don't limit yourself by falling for the caricature.
Certainly he's targeting a not-exactly-right stereotype that he'd like to be true and there isnt really such a strong web of invisible geniuses that all know each other.
That said there's some truth in it.
For starters most real C coders do in fact know all other languages. your typical python coder (cause yeah, PHP is kinda dead) can't do that. he can't fix the server software thats in C either.
Generally, he writes a new server in python, and its magically slower and problematic. Wrong tool.
Go and such languages might make this gap a little narrower tho.
>For starters most real C coders do in fact know all other languages. your typical python coder (cause yeah, PHP is kinda dead) can't do that. he can't fix the server software thats in C either.
You must know very different "typical python coders" than I do. Almost every Pythonista I know or look up to knows at least some C, at least enough to write Cython, and usually enough to write idiomatic C. As you allude to, we often have to when we need to optimize CPU-bound code.
Almost the only exception to this are the coders I know who are just starting to program. But almost anyone who stays active in Python will eventually learn some C, if they don't already know it.
do you know how the memory allocation works when you create a list in python by inferring from how you'd do it in C?
its a very basic question and I don't know many python devs that know the answer right off the bat. its going to be "u malloc stuff right?"
Another basic question: what happens exactly when you open and start reading a file?
"u call open right?"
thats not enough to figure out how things work. Coding "real" C (as in being able to do anything in C, not just code snippets) means that you probably understand how most things work under the hood, including libc, the kernel(s), file system, etc - at a pretty good level of detail.
If you know many like that, its great, but if you think the majority (or even a third) know these things - then I also think that either you or I live in an imaginary world =p
I've been trying to write a comment essentially just like this one, unsuccessfully; thanks for putting it so clearly. I can't think of anyone that fits the stereotype listed in the article, and I've met many downright astounding hackers; the trait they share is curiosity, above all else. This means that they're about the furthest thing from the 1-dimensional stereotype in the article -- they play music, build cars, hack game consoles, write novels, fly planes, and are generally just complex individuals. Boiling them down to a bullet point list of generalizations is just silly.
@bdcravens posted this 2-year-old link (https://news.ycombinator.com/item?id=3922579), referencing the same post. Read the whole thread -- lots of interesting comments from all kinds of perspectives.
A question for the community, based on this comment:
I've been speaking to a few of the more established startups in the Bay Area that built apps on Rails and have started migrating the performance hotspots to the JVM. There's definitely a pattern I've seen.
1) First version of the app is built in Ruby, Python, or PHP and the lightweight stack helps the business stay nimble as it finds its market position/niche. During this time, there are a LOT of inexperienced, younger engineers working on the code.
2) Once the right market position is found, the app takes off and scaling problems abound as the lightweight stack starts to fall down at massive scale.
3) Funding is secured and more experienced, older talent (the Guild) is brought in (at much higher salaries) to help fix the hot spots. This is usually done using a combination of using the JVM or unmanaged C/C++. The engineering demographic often switches here as you see a lot of 30-something veterans from Yahoo, Google, etc come in and bring their tools with them.
4) Scaling isn't an issue anymore, but the culture has changed a bit as the business has become more established. Many of the early folks have moved on or gone into leadership roles. A few have been absorbed into the Guild and will move on.
It's very interesting. I've worked mostly in the midwest and the South during my career, and this lifecycle of talent is not something I've really observed outside of the Valley.
Why wouldn't this be something that takes place outside of the Bay Area?
> Why wouldn't this be something that takes place outside of the Bay Area?
As someone who's worked both inside and outside the Bay Area - because startups on the outside can't afford to do step 3. Or don't dare to. They keep patching things up, applying duct tape upon gaffer tape solutions ad infinitum.
In a lot of cases they also just never reach the scale where doing this would make sense.
I can't tell if this is ironic, or if the scene has been so watered down by hipsters that knowing C is like being a magician? I mean, having worked with people like this (outside of the crude stereotypes), these people aren't that hard to find. The addendum makes me think it's more about valuing real experience with timeless technology over fads, which I guess I agree with, but I find the point of the article to be a bit opaque.
"companies that have struggled to build an engineering reputation, like foursquare, can offer." Excuse me? Foursquare has pretty well regarded engineering talent, at least their West Coast office.
Nice and truthy, but backwards: company success causes hiring of the Guild, not vice versa. Sun didn't die because neckbeards left. Neckbeards left because Sun was dying.
36 comments
[ 2.9 ms ] story [ 75.1 ms ] threadI recommend reading Robert Gossbach's fiction book _A Shortage of Engineers_ for a funny and ironic hardware-centric view of this.
I once got a roomful of laughter by quipping, "What we need are some more fat engineers with beards here." Where there is laughter there is often a painful truth.
It's got nothing to do with a particular list of languages. I think.
John knows. What? Well, just about nothing he'll tell you. But it is a lie. John is part of the cadre of people that know what they do not know, and John knows it's a lot. But that is the trick, John knows that he is a moron. This is because John has just about seen it all.
Here's an example. On labtop centrifuges, the transformer for the high velocity motor sits right under the catch lid for liquids on most models. Not the best design, but if it fries, just about anyone will know. And pay. They cost a lot, as they need to be precise. So John repairs them for the UCLA researches that can't be bothered. But there is a thing that John knows, because he's part of the cadre.
If nitric acid, common in organic chemistry, drips on the transformer and fries it, something happens. John knows this because one day he was soldering on the PCB to repair the transformer and the whole ground trace went missing in about one second. John lost his eyebrows to find this out. Turns out, the nitric acid reacts with the various chemicals in the transformer and the PCB. The PCB gets eaten and becomes, well, a very good way of removing hair on your face. The whole board gets contaminated with a drop and you have to very very careful when soldering thereafter.
John knows this. Not really anyone else but who John talks to knows this. And since John is part of the cadre, not really anyone knows. But all the guys, and they are universally men, know. And they care.
The cadre is full of the people the OP talks about. Large shirts holding in bellies of Tab and Fritos, heavy breathing, glasses, a lot of Weird Al and Dr. Demento trivia. These guys are insufferable at first. They couldn't hold a girlfriend, let alone a wife, to save their lives. They know nothing of sports or chrome. Their lives are their work. The people upstairs from John are completely reliant on John, and they hate it. John isn't unfriendly, in fact, hes a great guy. But Lord almighty, he will talk your ear off.
But John knows.
The story about nitric acid reminds me of my favorite quote by Ira Remsen about the value of experiments in a laboratory:
❝While reading a textbook of chemistry I came upon the statement, "nitric acid acts upon copper." I was getting tired of reading such absurd stuff and I was determined to see what this meant. Copper was more or less familiar to me, for copper cents were then in use. I had seen a bottle marked nitric acid on a table in the doctor's office where I was then "doing time." I did not know its peculiarities, but the spirit of adventure was upon me. Having nitric acid and copper, I had only to learn what the words "act upon" meant. The statement "nitric acid acts upon copper" would be something more than mere words. All was still. In the interest of knowledge I was even willing to sacrifice one of the few copper cents then in my possession. I put one of them on the table, opened the bottle marked nitric acid, poured some of the liquid on the copper and prepared to make an observation. But what was this wonderful thing which I beheld? The cent was already changed and it was no small change either. A green-blue liquid foamed and fumed over the cent and over the table. The air in the neighborhood of the performance became colored dark red. A great colored cloud arose. This was disagreeable and suffocating. How should I stop this? I tried to get rid of the objectionable mess by picking it up and throwing it out of the window. I learned another fact. Nitric acid not only acts upon copper, but it acts upon fingers. The pain led to another unpremeditated experiment. I drew my fingers across my trousers and another fact was discovered. Nitric acid acts upon trousers. Taking everything into consideration, that was the most impressive experiment and relatively probably the most costly experiment I have ever performed. . . . It was a revelation to me. It resulted in a desire on my part to learn more about that remarkable kind of action. Plainly, the only way to learn about it was to see its results, to experiment, to work in a laboratory.❞
https://www.youtube.com/watch?v=pJSQq494oV4
To tell you a secret, C is too hard for me because all of the system programming, de-referencing pointers make my head spin. Their threading, socket multiplexing I usually can't understand until Node.js or Scala introduces something similar to it and boils it down for me. Bah, seg-fault again!
Well, I hope someone makes a Codeacademy or Railcast for C very soon for a plebe like me. But only give select invitations as not to dilute the membership, I don't want to belong to any club that will accept me.
C is not hard. You will probably have harder time understanding the vocabulary, than the concepts themselves. Read Beej's C and network programming guides. Get a Free UNIX, download the source for simple utilities and tinker.
http://beej.us/guide/bgc/
http://beej.us/guide/bgnet/
Don't confuse C programming with Unix systems/network programming. You can write C to write anything, but it excels at low-level stuff. Also, don't scoff at higher-level languages; you can cover a lot more ground and learn more using higher abstraction. Go and Rust should be preferred to C at this stage. Clojure and Scala are yet higher level and support more paradigms. Hadoop and Spark and domain-specific tools, not really programming languages. Node is probably good for something, but I have no experience with it.
You know what the great engineers that I know have in common? They're great at engineering. Once you start looking at other qualities, they are pretty diverse. Some have families, others are single. Some play trading card games, others write musicals. Some wear ironic T-shirts, others dress "up" (not exclusive of course). Some fly planes, others ride bikes. Some are straight white dudes with kids, others are transgender people in polyamorous relationships.
You know what else is interesting? They come from everywhere, and every one of them had a first gig somewhere, where nobody realised how brilliant they were (with some rare exceptions).
Great people are all around you. Don't limit yourself by falling for the caricature.
That said there's some truth in it.
For starters most real C coders do in fact know all other languages. your typical python coder (cause yeah, PHP is kinda dead) can't do that. he can't fix the server software thats in C either.
Generally, he writes a new server in python, and its magically slower and problematic. Wrong tool.
Go and such languages might make this gap a little narrower tho.
You must know very different "typical python coders" than I do. Almost every Pythonista I know or look up to knows at least some C, at least enough to write Cython, and usually enough to write idiomatic C. As you allude to, we often have to when we need to optimize CPU-bound code.
Almost the only exception to this are the coders I know who are just starting to program. But almost anyone who stays active in Python will eventually learn some C, if they don't already know it.
do you know how the memory allocation works when you create a list in python by inferring from how you'd do it in C?
its a very basic question and I don't know many python devs that know the answer right off the bat. its going to be "u malloc stuff right?"
Another basic question: what happens exactly when you open and start reading a file? "u call open right?"
thats not enough to figure out how things work. Coding "real" C (as in being able to do anything in C, not just code snippets) means that you probably understand how most things work under the hood, including libc, the kernel(s), file system, etc - at a pretty good level of detail.
If you know many like that, its great, but if you think the majority (or even a third) know these things - then I also think that either you or I live in an imaginary world =p
A question for the community, based on this comment:
hkarthik 780 days ago | link (https://news.ycombinator.com/item?id=3923997)
I've been speaking to a few of the more established startups in the Bay Area that built apps on Rails and have started migrating the performance hotspots to the JVM. There's definitely a pattern I've seen.
1) First version of the app is built in Ruby, Python, or PHP and the lightweight stack helps the business stay nimble as it finds its market position/niche. During this time, there are a LOT of inexperienced, younger engineers working on the code.
2) Once the right market position is found, the app takes off and scaling problems abound as the lightweight stack starts to fall down at massive scale.
3) Funding is secured and more experienced, older talent (the Guild) is brought in (at much higher salaries) to help fix the hot spots. This is usually done using a combination of using the JVM or unmanaged C/C++. The engineering demographic often switches here as you see a lot of 30-something veterans from Yahoo, Google, etc come in and bring their tools with them.
4) Scaling isn't an issue anymore, but the culture has changed a bit as the business has become more established. Many of the early folks have moved on or gone into leadership roles. A few have been absorbed into the Guild and will move on.
It's very interesting. I've worked mostly in the midwest and the South during my career, and this lifecycle of talent is not something I've really observed outside of the Valley.
Why wouldn't this be something that takes place outside of the Bay Area?
As someone who's worked both inside and outside the Bay Area - because startups on the outside can't afford to do step 3. Or don't dare to. They keep patching things up, applying duct tape upon gaffer tape solutions ad infinitum.
In a lot of cases they also just never reach the scale where doing this would make sense.