Interruption to Salary
Interruption
How much less do people hate software updates if they happen invisibly, as in in a webapp? In other words, what do people dislike more, being interrupted by an update, or the changes the update contains?
I’d like to find some quantifiable measures, but I can’t picture how you’d measure something like update hate.
Tools
Why can’t I find useful tools for data flow analysis in programs?
This baffles me. Puzzling out the conditions that lead to something having a particular value at a particular line is perhaps the core problem of programming, yet everyday tools to help do it have barely improved since the invention of grep. It’s as if we know how wheels can be built, we have a few wheeled things (compilers), but we don’t attach wheels to the heavy loads we push every day.
Esoterica
Is it surprising how rarely people pick esoteric tech stacks? Using mainstream tech increases the size of the pools for jobs and candidates, but in programming, those pools are huge. It’s filtering the pool that’s hard, and wouldn’t picking something like Haskell be a strong signal?
Paul Graham makes this point about choosing lisp to build Shopify1. In my opinion the most common tech stack is an anti filter since it is where the mediocrities flock. So you want an uncommon but not totally crazy tech stack.
One of the reasons flowtype died and typescript flourished was flowtype was a JavaScript tool written in Haskell. The guy left Facebook and no one knew how to or wanted to maintain it.
—TL
As I read Beating the Averages, Graham didn’t advocate Lisp for signaling value, but for its inherent “power.” TL replies, “He thinks there are very few mediocre Lisp coders and goodness knows the big popular stacks are great hiding spots for mediocrities,” but I’m not sure I read that in the article.
The idea of “uncommon but not totally crazy” will be interesting to follow up.
It’s true that something like that is a strong signal, but as someone who had to be in the unfortunate position of “only guy who can do Clojure” at a job with a few Clojure-built tools after the other guys on the team who knew Clojure left the company or got re-orged around, I can say it’s very hard to hire for niche languages, especially in companies where there’s already some other primary language toolchain and the hiring decisions are primarily being made around that with your niche thing being a “bonus”. If your whole company is in the niche language, it can work. If it’s just 10%, it better really be worth it for that 10% on its own merit because otherwise you pay more of a price for it. Even if the popular language is known by, I dunno, a third of the programmers out there, you have to imagine that the intersection of “knows the popular language” AND “knows the niche language” is a lot smaller than “knows the niche language”.
—JJ
This story lines up well with Paul Graham’s point,
But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn’t realize he’s looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
—Ibid
I worked on a Haskell team at Target and Haskell directly helped us recruit some great folks we would not have attracted otherwise. I later worked on a “sister” team that hired data science/engineering folks to use Python, and the recruiting pipeline was noticeably less strong.
Apart from attracting people who wanted to do Haskell for its own sake, the other thing that Haskell gave us was a way to signal—to show rather than tell—that we were willing to do different and interesting things as a team. It gave credence to our story that we were doing some legitimately novel work. (Of course, it also helped that we actually were!) I remember the first person I interviewed was an OR expert who later told me he chose our team over Google because we were doing some cool things he hadn’t seen before.
I heard similar stories from folks at Jane Street about using OCaml, going back to when they were much smaller and less well-known than they are today. And another similar story with Symmetry Investments and D.
Anyway, point being that I’ve seen, first hand, how well using a “niche” language can work for recruiting. I won’t speculate on why more organizations aren’t willing to try it, but I know it works :P
—TJ
The point about traders is especially interesting, as software errors are probably far more dangerous to the likes of Jane Street than to those we call “tech companies.”
“Esoteric” stacks are awesome for small companies. You will end up attracting good talent, and people matter more than stack. Big companies can’t afford these stacks because they need to hire in big numbers, and by doing that they attract a lot of mediocrity. So if you want mediocrity in your startup, go for a popular stack.
—JMJ
If true, this would require that you switch at some point, assuming you want to grow. I don’t think I buy it, but it’s worth considering.
Several replies said picking up new languages is relatively easy, so the language is relatively unimportant. I think that’s sometimes true, but a complicated topic, worthy of a longer article.
Salary
Observation related to yesterday’s post: If I search for “Haskell” jobs, there are a few, but they don’t appear to pay more than any other programming job.
| [1] | It was Viaweb, not Shopify, but that I don’t think that’s salient. |