Signaling in tech is some fucked up shit (2016)
daiyi.co
daiyi.co
Recruiters use an intuitive approach to conditional probability. Given only the info alone (if someone did JQuery or Clojure) exposes you to two bell curves, with the X-axis being "programming ability". The first bell curve that has all JQuery people is more on "the left" and the one having all Clojurians is more on the right. The Clojure bell curve has shitty engineers and some really good people are part of the JQuery one.
Prejudice is sort of rational. If a recruiter looks at one datapoint, it's unlikely that it is at the tails of the bell curve, so the Clojurian applicant will get more attention. If you are treated unfairly because of the group you "belong to", I am sorry - but this is reality.
If I randomly select a programmer from all the programmers who write Clojure, working or not, interviewing or not, they are likely to be a “better” programmer than if I randomly select a programmer from all the programmers who write JavaScript, working or not, interviewing or not.
But of course, that’s not what happens when I interview. I meet one person in the morning with three years experience working on projects of types A, B, and C. In the afternoon I meet another with four years of experience working on projects of types B, C, and D.
If one has Clojure and the other JavaScript, I’m much more likely to be delighted to discuss Clojure than JavaScript, but as far as HIRE/NO HIRE is concened, the thing that matters to me are projects Of type A, B, C, or D, and the candidate’s role/contribution.
If the JavaScript programmer’s experience is solid, I do not want a recruiter in-house or otherwise trying to save me an interview and filtering them out.
The bottom line is, there are like 100x as many JS folks as CJ folks. So let’s say there are 100 great CJ people out of 1,000 CJ people. 10% ham!
But that means there are 100,000 JS people. If even 1% of them are great, that means that there are 1,000 great JS people out there, and I do not want to pass on meeting any of them just because there are also 99,000 not-so-great JS people out there.
In my imaginary distribution, a random CJ person is 10x more likely to be good. But there are 10x as many good JS people as CJ people, and my experience is that THEIR experience is a far better signal than their programming language.
—-
p.s. I am competing with people who only want to hire programmers with shiny signals like ClojureScript or the ability to quote “JavaScript Allongé.” Good! Let them ignore the 1,000 good JS people, easier for me to interview them and make a successful offer.
Now that I think about it, please ignore what I just said. Only interview people who build systems out of Lisp, Prolog, and Maleboge.
“Nova 1220 BASIC, Acius 4th Dimension, Hypercard, MetroWerks CodeWarrior, Lightspeed C, Turbo Pascal, MP/M, DigiTalk Smalltalk/V, J2EE, ...”
What does any of that have to do with each other.
However, the implicit companion assumption that a resume with lots of clojure experience will have those skills is not something I've seen any evidence for. Many Clojure-focused candidates are unproductively dogmatic and are at risk of wasting everyone's time by trying to rearchitect our codebase because it doesn't meet their particular taste. In general, if a candidate is an adherent to a niche programming language they need to be able to explain to me when its use would be appropriate and inappropriate. If their answer is "this language and/or dogma is always better" then you're adorable but you need some more experience before I'm going to hire you.
It's also important to point out that, while my core requirements are the same for both jQuery and Clojurey candidates (ability to function in a large, complex codebase & ability to manage your own code's complexity), the specific skillsets are very different. Most clojure enthusiasts are actively bad front-end engineers. Which is fine! But many positions require engineers to at least be able to dabble in UI work, and if I get the sense that you would find it beneath you to do so, its probably going to mean better luck somewhere else unless I have a very specific position to fill.
Would you care to share those statistics? While we're at it let's also be sure to define "good engineer."
For what it's worth, I'm challenging you as someone who is neither a JavaScript developer nor a Clojure developer. I'm of the opinion that biases like the one the author laments are perpetuated (in part) by this leaky arguments from "statistics" that never appear.
You're then meant to combine their stated experience with their stated credentials and your assessment of their trustworthiness to arrive at some conclusion.
This imprecision may annoy you but it is a common way of speaking English so it's probably not in your interest to fight over the choice of wording.
This is because saying something is true "statistically" is a claim made in both scientific and casual contexts. It's mentally taxing to figure out which context is in play - someone could have come into this thread with actual statistics and said the same phrase, verbatim. Therefore (as I see it), it's realistically plausible that someone could read the original comment and come away believing recruiters have done actual statistical analysis a la TripleByte to arrive at their conclusion.
For example I have not run a study but I am very confident that, statistically speaking, tall people are better at basketball than short people. I am saying that I have an opinion that if you were to try and choose good basketball players, biasing yourself towards the tall people will increase your odds of making a good choice. I use the phrase "statistically speaking" to make it clear I am not saying "All tall people are better at basketball than short people".
In a lot of contexts you will drop the phrase completely because you are talking to other smart people and they will know that the context of your statement is in the realm of populations and odds, but online there are a lot of pedants with poor communication skills so you have be extra clear.
Idiomatically, any way you use the phrase implies great confidence in the corresponding claim. But I have not seen any substantial explanation of why this effect makes sense, which makes me extremely suspicious that the effect exists at all. I don’t particularly care about whether they’ve conducted a peer reviewed study. I care about whether or not their heuristic is backed by anything empirical. “I’ve noticed this...” doesn’t cut it, no matter how fast and loose you want to play with the literal meaning of the word in context.
"I'm so going to win the lottery"
"On average ... no you aren't" / "Statistically speaking ... no you aren't" / "If you work out the odds ... no you aren't" / etc.
If I ask you a question about some gambling game, you are going to think about it in a statistical way. I mean you will think in terms of populations and samples and odds, not that you will go perform experiments and then do a statistical analysis of that evidence in order to come to a scientific conclusion.
I, like you, am riled up by people using puff words to inflate the apparent credibility of claims, often claims that have little or no basis for actual credibility.
But I think that "statistically speaking", as it is used by nearly all English speakers, means "speaking about these groups in aggregate", not "speaking as a statistician". It doesn't even mean something about an empirical basis, it means talking about groups. I agree pretty much entirely with freshhawk's analysis.
Now, aside from _word choice_, your skepticism about whether the original poster has any empirical basis at all for their claim... well, fair enough.
I'm deeply skeptical. People like to throw around percentages and references to statistics to justify their biases, but I don't think the commenter has done nearly enough to motivate the conclusion that the modal Clojure developer is more likely to be a "good engineer" than the modal JavaScript developer.
If someone who interviews thousands of people and finds a correlation between those who have some clojure experience and quality, I believe him.
For the simple reason that most programmers don't try very hard and anyone taking the time to even learn a rarely used language is demonstrating a positive quality that most don't.
I stand by my point: using words like "statistically" and "correlation" perpetuate biases which may not have a rational basis. In this entire thread no one has explained why Clojure programmers are more likely to be "good" than JavaScript programmers (nor has "good" been defined!). I could just as plausibly state that someone tried to learn Clojure because they perceive it to be a buzzword, just as JavaScript programmers are often accused of playing buzzword bingo with web development frameworks.
Empirically speaking, we haven't ended up anywhere. No matter how sure you are of this phenomenon, unless you try to make its observation more robust, it will continue to be a microcosm of the tech hiring industry. Heuristics often belie subtle biases that do not actually have a foundation in truth.
Once known as the Python Paradox http://www.paulgraham.com/pypar.html
Nowadays I suppose it would be the Clojure Conundrum or the Haskell Happenstance
Their websites sound like they are the pinnacle of the industry, but on phone/email they sound like a bunch of HS dropouts :(
Heck, I’d even say if you only look at the population of engineers who you have directly observed doing a good job on some interview trivia or code test, you still cannot reliably conclude that draws from that population are statistically significantly more likely to be acceptably good at a job once hired than draws from a different population.
People and processes capable of detecting skilled engineers are extremely rare. Skilled engineers are also somewhat rare.
What we set up as tech hiring processes are mostly just crap-shoot just-so stories we tell ourselves, mixed with a ton of hubris.
No, they're paying them to find engineers that will pass the interview process. It's a subtle, but important distinction since prejudices that exist among engineers will naturally develop in recruiters. It's the recruiting equivalent of teaching to the test.
And like it or not, the kind of signaling the article describes is real. When an engineer says they can write clojure, it indicates a curiosity that ability to program JavaScript does not. Almost no one is forced to learn Clojure because of some job, project or even job prospects. It means you likely cared enough to devote your own time to learning for the sake of learning. And a lot of engineers look at this kind of thing as important and screen for it in interviews.
A recruiter operating any differently would be like a machine learning algorithm that ignores its training data.
The curious thing is, I think the number who regard it as important is likely far higher than the number who actually do it. Which is understandable; once you reach a level of seniority you also have many other demands on your time and may not be able to be a hobbyist anymore on top of day job, family commitments and so on. So maybe once you learnt every new language but now you don’t have the opportunity, or you have decided to “go deep” in just a few, established languages. So the power of the signal is highly variable depending both on where the interviewer and interviewee are in their lives.
Also, knowing JS in the late-90s did indicate a curious and ambitious developer. It only went mainstream later...
P(broken|android) =~ P(android|broken)
P(android) >> P(broken)But when my iPhone breaks, I take it into Apple for service and add it to my collection of “Apple gives great service” data points.
Saying that prejudice is just applied statistics completely mischaracterizes prejudice.
Of all the stupid arrogant awfulness in tech that has crossed my path this one is definitely high on the list of the most baffling. Web dev is the hardest and most intimidating dev work I've ever done, by a country mile.
(Whether that complexity is 'justified' is an entirely different discussion that, while no doubt interesting, has nothing to do with this person's post)
Tech is the new Wall Street in a lot of ways. But instead of being honest about where the paycheck comes from we gloss it up so it’s less morally reprehensible. I actually have more respect for people on Wall Street these days. At least they are honest with themselves about the game. I think I have more respect for Jordan Belfort and Lou Pai then the exec teams af Facebook and Uber.
I see this mindset in Seattle very often. A lot of my friends have recently been quitting their jobs to do something other than tech because of the overly inflated egos and the need for software engineers to constantly "do something new" instead of just maintaining & fix what they already have.
So is not pushing negative externalities inherent to web apps to customers just because it makes web devs more productive.
Today's web is a monster.
Same could be said of bailouts, recycling, MLM, and other sucker games...
That's almost certainly what's needed. The fundamental structure of the HTML-CSS-JS triad is the problem that all this complexity tries to abstract around.
Separation of concerns is only good if you're separating the right concerns. Back when web pages were really PAGES (ie documents), the Content-Styling-Interactivity division made sense. But now that web pages are applications that division makes very little sense.
All the different solutions represent different approaches to redefining the separation of concerns, but what they all agree on is that Content-Styling-Interactivity is the wrong separation.
I'll go as far as to say that will never change. Applications are only one part of the web; the other parts matter too.
I care more about reading documents on the web, and I'm glad it has a nice simple way of presenting them (HTML) and styling them (CSS).
CSS works OK as long as you aren't trying to control things pixel-for-pixel, which is not what it's meant for. It obviously could be better, but the problem is not easy by any means.
>I'll go as far as to say that will never change. Applications are only one part of the web; the other parts matter too.
That's true, but it's also not the problem domain.
No one is having trouble creating document websites on the internet. That problem is, more or less, solved to the point that almost anyone with no technical background can do it.
Application-type sites are where all the pain points lie.
(Whether that complexity is 'justified' is an entirely different discussion that, while no doubt interesting, has nothing to do with this person's post)
IMHO that has everything to do with it. It's hard to have any other opinion of web developers when you constantly see the large amounts of unnecessary complexity they foist upon everyone else. As I said, I worked in that space briefly, with others who had severe "framework envy", and largely see this complexity as being self-inflicted --- in some ways it was like Enterprise Java (another thing I did for a similarly brief time), except with much more churn. On more than one occasion I've had to clean up the mess they made by rewriting large web apps with simpler means, and the result was better by every metric (speed, memory, lines of code, etc.) except perhaps fashionability and job security.
I mentioned to some people I was learning clojure. Everyone was super into this. People started telling me I was really cool.
The author of this article must certainly not be in the same "tech bubble" I'm in, where telling someone you're interested in Clojure is going to be met more with neutral "what?" and "why?" reactions. However, I certainly agree with the title of the article: "signaling in tech is some fucked up shit".
“Aren’t you just trying to walk to the store?”
“Look! I added a fifth! Everyone do this now!”
(You might think it cheating somewhat because HoneySQL is just a thin syntactic wrapper on SQL, but then again, if I weren't cheap/poor, I could use Datomic, where it really is the same language.)
I don't have a good explanation for either of those phenomena, but I think language-counting isn't a good way to combat them.
With web development, I have to know HTML, CSS, and JS at least. I probably really need to know SQL. And I switch between those four (at least) every day, many times a day.
The context switching existed but not at the same frequency.
Putting up a simple web site that does something basic, that you then walk away from is easy, and is what a lot of people who call themselves web developers do.
Building something like Gmail or Facebook OTOH are endeavors only slightly below the moon landing in complexity and “solving cool problems”.
And it is equally legitimately "web development"...
Facebook is about an order of magnitude less, so the Apollo program fits nicely between them.
I realise looking back that comparing a company to a project/program isn't really correct. One kind ends, the other tries very hard not to end.
But you're of course right that I exaggerated a bit for effect. I do that sometimes.
My point still stands if you slice a few orders of magnitude off my hyperbole.
But the Apollo program and the Manhattan project were something else. Arguably they represent the historical highwater marks in terms of megaprojects which had effectively unlimited resources in the face of wide-open, unsolved problems.
[1] https://qz.com/726338/the-code-that-took-america-to-the-moon...
[2] https://github.com/chrislgarry/Apollo-11
[3] https://www.quora.com/How-many-lines-of-code-is-Facebook
...which, if I were to guess, consists of a significant amount of "do nothing" or otherwise useless abstractions that either were put there dogmatically or once served a purpose but no longer does. This is reasonably prevalent in Enterprise software but I imagine the much higher churn in Facebook code also increases the amount of cruft that gets thrown in or otherwise left behind.
Search HN or the Internet in general for mentions of Facebook's app being bloated and you'll find that even non-technical users are at least somewhat surprised by this gross inefficiency.
My personal experience has been that the label "web developer" is typically used by less experienced people if only because after a little while in the industry, even if your focus is primarily web-related, you start to develop skills that are more widely applicable and don't want to be "pigeonholed". It doesn't have anything to do with the difficulty of the problem set, the quality of the ecosystem, or any other specific value judgment.
It's the difference between a package delivery service characterizing their employees as "box movers" v. "logistics coordinators".
From my experience, it seems like a lot of web dev people struggle with OS/Compilers/Embedded/Robotics work, but people who don't struggle with OS/Compilers/Embedded/Robotics work tend to handle web dev just fine.
Why is that? The only explanation I can think of is because the work is easier (easier, not trivial).
(Note: I don't think a web developer (or anyone) should be considered a "lower class" of coder, but saying web dev is the hardest and most intimidating dev work feels untrue).
Those people who are good at OS/Compilers etc would still need to use a tutorial to pick up HTML/CSS/JS...and due to the popularity and inclusiveness of the web dev community, they will find it relatively easy to find high quality interactive tutorials that can get them up and running quite quickly. Additionally a lot of the web is designed to be easy to use...its the reason why we're all using HTML5 and not XHTML right now. I think of the current competition between Vue, React, Angular and others to basically be an ease-of-use competition. Its genuinely quite cool that web developers are making fairly tricky concepts easy to use with these libraries.
On the other hand, a lot of material about OSes, compilers, embedded systems is relatively obscure, frequently out of date, possibly difficult to find outside textbooks and research papers, and open source libraries in these domains might even require looking through source code just to figure out how to use a library. A lot of these communities are also indirectly elitist, leading to various sorts of bootstrapping problems for newcomers (I've heard "if you can't build the Linux kernel, why are you even trying to learn about it" several times on different mailing lists :/)
As a personal anecdote, I work on compiler and OS things as part of my job, and most people on my team have a high degree of respect towards web dev work. There are only 2 people on my team who think that we could easily do some light web dev: me and another colleague, both of us who've done actual web dev jobs for several years before transferring to our current team. So I don't think web dev is easier, but just far more accessible than a lot of other fields.
The lack of respect for how difficult it can be to make a smooth user experience is in a way understandable. But the truth is front-end people spend at least 1/2 their time in Chinese finger traps ...
That's because of:
* an over-inflated sense of importance (see the comparison with the moon landing)
* aggressiveness (see the endless statements about killing the desktop, mobile, etc)
* low barrier to entry and high population numbers to entry resulting in lots of ignorance
* attention deficit (see the endless churn in frameworks, libraries, solutions)
* and poor technical craftsmanship (at the end of the day, the solutions offered have poor performance and poor platform integration). This is justified by the fact that these poor technologies are making webdevs more productive.
Not all of the above apply to back-end webdev, those devs are more relaxed. Unfortunately they're being assimilated by the front-end.
More to the point, why would people want to work in a hard and intimidating area anyways? If it was fun and interesting, it might be challenging but not intimidating. Again, I’m not making judgements in web dev, just on how biased perceptions go.
The reason is how a lot of companies do web: sloppyly and pay peanuts.
I think Web Dev and App Dev get such a bad rap because the half-life of the knowledge there is so short that length of experience isn't the signal that it is in other areas (and sometimes it can be an anti-signal).
Even of people who look down on "web development", I don't see anyone claiming that writing Google.com is easy.
There's lots of types of projects that I don't think very highly of, even if technically challenging and competently implemented, simply for being not worthwhile.
I don’t ever recall running into someone who would treat me badly based on what I do. I’m not arguing it doesn’t exist. I certainly believe the author. I just haven’t experienced it myself. Have I just been lucky?
- Signaling in tech is a real thing. I believe this stems from being (understandably) picky about our peers, combined with a fundamental difficulty of evaluating them. The problem is complex enough that our strong tendency is to fall back on stereotyping and other heuristics.
- Many programmers (myself included) have had encounters with "Web developers" whose primary interaction with JS is copying and pasting. Of course, it's hard to say what percentage of "Web developers" fall into this category -- certainly it's just a small proportion of the whole -- but enough of this type exist that "Web developer" is not always a positive signal -- indeed, it can be negative for some people.
- The above issue appears to be self-reinforcing, because the more the tech culture becomes aware of the problem, the more the stigma grows for existing Web developers that have not changed their title. Posts like the OP's are valuable because they work to correct our cultural narrative.
I'd expect the most likely people to experience this are "Web developers" who haven't yet accrued enough other signals of their competency (like experience, charisma, or similarity with their peers). e.g. a soft-spoken female Web developer without a lot of experience sounds like an archetype where this could be an issue.
Of course, it's a game of chance. But the odds are incredibly different for each person.
Also, from what I can tell people in academia and certain open source circles are brutal to each other (e.g. Linus Torvalds). I'm sure they would shit on the work I do every day... but I'm too busy to care.
It most certainly is, when you have to work with and clean up the mess.
Much like there is the notion of "10x" programmers, there are also "-10x" ones. Unfortunately they can stay around for a surprisingly long time.
Judging the quality of someone’s work _may_ be my job if I’m asked for peer feedback, but even there I disagree. I feel it should be up to a manager to determine whether his or her reports are doing good work. (I’m not a fan of peer feedback for a variety of reasons.)
Of course if someone is incompetent, that’s a different matter. How I’d deal with that is too circumstance specific to outline here. I’ve been fortunate in that I can only recall a few such people.
I suspect it's because the mothership goes out of its way to keep them in a constant state of anxiety and confusion--open offices, stack ranking, endless meetings, etc...
It is easier to assert your dominance over them when they are at each others' throats.
Even setting aside the issue of complexity, from a business perspective, web dev is immensely valuable and only becoming more so.
And as for complexity, I always thought I could learn it easily because its "not real CS" but man its a huge, complex, ever-changing ecosystem and not at all easy. And it takes a much broader set of skills (both technical and non-technical) than pure backend programming or whatever.
Mad respect to all web devs, and all devs. The sooner we get rid of the caste system within software the better.
I'd argue that the real signaling here is the op showed genuine curiosity. This is hard to fake, and the "fangirls" in this example could be people pretending to like Clojure because that's the hip language/framework of the day.
Maybe people respect you more for being genuine.
Learn enough concepts from a few different schools of thought to be able to make sense of a language in a reasonable time. Master a few, eventually.
An ability to use a semi-obscure language to solve a problem, and an ability to explain why it is superior for the task is indeed an important signal of the above-mentioned abilities, and a costly one. Costly also for the employer (in terms of your negotiated salary).
I've found that while I can't change peoples' biases, waving the flag of "I do stuff in Rust in my spare time" is enough to scare off at least the Java folk.
There's an interesting power struggle I've been caught in more than once: Back-end devs describe their work as very hard so that they're left in peace, and the easiest way to strengthen that is to describe someone else's work - front-end developers' in this case - as easy.
This way whenever a change in requirements occurs there's pressure to avoid doing changes on the back-end in favor of changing things on the front-end. At the same time interesting and "hard" things are meant to be done on the back-end even though nowadays it's possible and sometimes easier to do them on the front-end.
The fact that back-end devs are paid approximately 20% more naturally only worsens this.
It's a never ending comparison contest. And despite functional programming having an objectively higher barrier to entry, it is entirely possible to write absolute garbage code in an FP language as well.
I can attest to that as I in college had a course on functional programming with Haskell and the way I did my assignment was awful to say the least.
Has Clojure already lost its cool mystique in the 2 years since this was written? If so I think that further proves the point that assuming good/bad things about a person's talents based on the tools they have used in the past is foolish.
I'm in my 30's and have used a lot of different languages and have worked in a lot of different aspects of software development. As long as I'm being compensated at my skill level, I couldn't care less what language I'm using. I'm currently a web dev and the company I work for primarily uses PHP. To make a long story short, a good friend of mine works for a huge university and if I hang out with him during the week, I'm inevitably going to be around some college kids. The typical icebreaker conversations of "what are you studying" often times leads to chats with CS students. The amount of trash talking I get from kids who haven't even graduated and have no professional experience once they find out I primarily use PHP is astounding. Golang and Python seem to be cool amongst college students, so once they find out I also have more experience with those languages than they do with programming in any language, I suddenly become cool and worth their time.
Here's one way to look at it, considering everything else equal, if you were an employer, would you pick someone who knows X (where X is jquery or whatever requirements you need) or someone who knows X + Y (where Y is some interesting technology that may eventually turns out to be useful)?
And CSS is harder than programming!
PS. I use TypeScript, love it and don't believe it to be suboptimal.
I also find the webdev low status pretty unjustified. It's true that it's less mathy than other disciplines, but at scale, "webdev" is every bit as architecturally challenging as anything else, and in some cases moreso because of the sheer number of different technologies and stacks you have to be fluent in to make it all work together.
Web Dev is hard __precisely__ because of this mess!
Fail early and fail often. Web dev has very low (technical) overhead and aligns with "startup" mentality. The good news is that the customer has different expectations every 6 months so it's not the worst thing in the world to have a slightly different set of technologies to meet those needs.
RE: your actual post, I've also personally noticed this, and a similar concept that when you reveal that the bulk of your experience is on a "dinosaur" language, you are automatically lumped into the set of less competent programmers. It pretty explicitly informed my choice of programming language for interviews.
Fortunately, I've found that there's a fairly direct correlation between people you would want to work with and learn from and how much this signalling affects them. Many of the programmers I respect most openly don't care what your language background is, just that you can wrestle your tech stack into good software. That's been my experience too: the good ones can ship great software on pretty much any (reasonable) stack. The okay ones ship okay software on pretty much any stack.
Nice article, the self-deprecating/funny tone is rather sparingly found in tech blogs (well, apart from Julia Evans).
I have worked at companies with open positions, and I have had to sort through a lot of resumes. I also get an informal Bayesian probability heuristic in seeing the resume and then seeing the person who wrote the resume. People who are on the ball, who are the standard deviation above the rest, know what to put on their resumes which looks impressive. People who are a standard deviation below the rest not only don't know how to put together an impressive resume that stands out, they don't even know how to put together a median, average resume.
If I was hiring programmers with little experience, and everyone has the same skillset - Javascript, ES7(8,9...), V8, Javascript framework du jour (React, Angular, Vue, Node.js) - they all look the same. If someone has Clojure on their resume as well, it sends a certain signal out. You still want to talk to that person, and verify that they are a standard deviation above the rest, but it sets you out from the pack. If we don't go by such signals from resumes and the like, I don't know where to go from. The OP is correct though, once you send up a signal you are a standard deviation above, then you have to follow through and you start feeling compelled to be able to produce at a level a standard deviation above.
I would also disagree that the web dev learning curve is not that steep... sure to get something to "compile" (well, show up on the screen) is stupid easy (<p>Hello world</p>)... but to actually make a functional, usable, performant, efficient, accessible, beautiful site or app requires managing a lot of complexity across a bewildering amount of environments and tools.
Want to fast-track a new project into a convoluted legacy codebase few humans can grok? Hire a bad dev and have them write in any language, it doesn't matter. I've seen Clojure code bases passed through a dozen hands that no one could figure out.
Those two factors right there weed out a certain bottom percentile of developers.
Signaling of the kind the author describes is information. If it truly is as widespread as the author suggests it is valuable-- just take note of the few people not signaling in this manner and then try to forge relationships with them.
1 - Learn to recognize biases.
2 - Scrutinize your thoughts to limit the influence of your biases.
3 - Work on processes to limit unconscious biases.
4 - Since you cannot eliminate biases, use biases to your advantage.
The exception might be demand based. PHP for example is generally sneered and looked down upon, but if a successful startup is built using PHP (there are lot's) then demand will be high for that specific expertise.
It is the same with any subject, music and movies also has this, the more underground music/movies and more original/classic movies you have seen the more you appear to know. It is snobby but it is a signal that you probabilistically are more experienced.
Even the OP posted how he came into programming with javascript and webdev, then tried Clojure and went into SICP. The latter two aren't gateway languages/areas. The gateway languages are javascript, java, C, C++, .NET, Ruby maybe Python now are usually the first languages people know, learning Clojure meant it was at least your second language, rarely do people start with Clojure, so it signals you have gone deeper in knowledge and have somewhat leveled-up even though day to day you seem the same self.
We often mock up in our minds what it means to work in a language or framework and bucket people based on these poor signals.
I tried to look it up and failed to find a definition that made sense.
I see this a lot in our field unfortunately. "You program in X? A real programmer would program in Y because...".
On the writing style; hope you are more fun over lunch talks :). Hope it is a jokingly written article because the dark writing style can easily be confused with a negative attitude for people who can only judge by the article. Cheer up!
P.s. the fangirl comment is a little out of place in an article on signaling written in this tone. It's like you think less of people who love the language for reasons that qualify them as "fangirl" in your eyes. Just saying.
You know, sometimes I wish HN would do a bit more editorializing/subtitling and less slavishly copying the damn stupidest subject lines that the original author thought would be cool....
Seriously, what's your experience out of "tech"? "tech" is the best signaling environment ever created.
But Daiyi's main point isn't that abc coders aren't xyz, but rather that other people are also xyz, and that if an efg coder becomes an abc coder and are found to be xyz then they were probably xyz back when they were efg before becoming abc coders.
And this point should be well taken. There is a common trend that analytic subjects contribute more value than artistic subjects. This, in part, is due to the phenomenon that analytic subjects have values that are easier to calculate (...analytically, whence this is somewhat circular) while artistic subjects have effects that must be evaluated more subjectively. A coder works for a week and adds a new feature which increases marketability. A painter works for a week and produces a painting that may eventually sell for $500 in a couple years. But this undervalues the painter---the effect of arts on a society is more than their retail value.
I think this in part describes why web devs/front end engineers are socially valued less than coders in the development community. Their contributions are harder to quantify and the problems that they solve are more diffuse and subjective. This leads to "it's hard to quantify an efg coder's contribution" being conflated with "efg coders contribute less".
But this is BS---I have yet to come across anything that isn't both an art and a science if done correctly. In fact, this thought lead me to my own answer to one of the great philosophical questions of the ages: "what is art?": I contend that art is anything done well.
And as a computer scientist with a prior life as a musician I can assure you that there is plenty of 'calculation' that goes into the arts. Sometimes this is explicit. For instance, say that I have a closed voicing CFA (closed voicing means everything is close together) and they are moving to B?G that will then move to CEG. What do I want to replace `?` with? Well we don't want F to move down (we try to avoid parallel motion, this can be thought of as a sort of axiom) so F must either remain fixed (oblique motion) or go up (contrary motion). We also don't want voices to cross (while voice crossing is less taboo than parallel motion it is still often avoided, and our adherence to this restriction makes our problem much easier). Since we are working with a closed voice we have two (diatonic) choices: we can double the G or stay fixed on F. Doubling the G is boring but staying on F creates dissonance (B to F is a b5 and F to G is a M2). Luckily this dissonance is nicely resolved by the subsequent voicing and we win music! Yay!
Notice something? This is just a constraint system! But rather than solving a SAT formula we are adding in some subjective data to consider as well. I like to phrase this as "In math, `1 + 2 + 3 = 6` while in music, `C + E + G = happy`".
These calculations can also be done implicitly: say I'm taking a break over some jazz tune and I'm hitting a turn around, a ii-V7-i. I have a vague notion that I want to hit the "Billie Holiday special" (https://youtu.be/KUCyjDOlnPU?t=2m59s) at the end of my break (a melodic 5-2-1 with a slight scoop up to the 2 which falls back to the 1). I'm in the key of Bb and I want to play this around the tonic at the 8th fret of my D string. Right now I'm in the upper area of the neck and about to change to the ii chord which holds for two beats. I want to leave a pause over the V chord to make the tag more interesting, so I have exactly two beats to get from where I am to where I want to go, and I have to quickly 'calculate' this transition in real time. This is, of course, very natural since I've been playing for most of my life, and the 'calculation' is more of a feeling than an explicit mental exercise. But underneath the hood there is a shitload of precomputation that I did, practicing similar harmonic and melodic situations, honing my instincts, expanding my ear, studying theory, etc. I have just, in real time, solved a complicated constraint problem in front of a room full of people. And they are all cheering for me! See? People love math!
I'm sure I don't have to argue the reverse direction on this site (namely that coding/engineering/mathematics/etc are all forms of art) so I'll omit this.
All this is to say that the distinction between the artists and scientists is very blurry. I won't go so far as to argue that it doesn't exist since it clearly does. But when I try to figure out what that distinction is I find a number of qualitative differences but nothing quantitative.
Having said that, I don't know what timeframe this person is referring to but web development went from extraordinarily hackish and ill considered (the WebForm/php/intermixed render blocks era) to being a quite disciplined portion of the industry. I remember when the overwhelming bulk of web developers wouldn't grok that JavaScript had closures, and they didn't have to use globals to store state during an event handler.
Web devs didn't make it that way. They're just the ones who have to live with it.
We should be buying them lunch and thanking them for their service, not crapping on them.
I don't think I've had to write anything 100% in assembly in 20 years, so no idea what you'd use on Linux.