michaelochurch

Hiring adults and trusting them to get their work done.

Am I going to tell a front-end engineer with 15 years of exprience that he has to use PureScript because I, personally, think JavaScript is a poorly-designed language? No. That would be dogmatic. I generally prefer letting domain experts call the shots that affect them. It's about getting the right decision, regardless of whether it's my decision, and I may not have all the information.

There are times to step back and let someone else call the shots, and there are times to stand your ground and fight. Make no mistake, though: promotions and demotions and firings result from these decisions and their long-term consequences, so getting them right really matters.

I'll support Luke's claim. We've had over 30 people for the last two meetups (in March and May). There's a lot of interest in the next Meetup (July or August, depending on speaker availability).

I'm also planning to do a beginner Haskell class (assuming programming experience, but no Haskell experience) in Chicago around November over a couple of weekends. I'm writing a summer class that my company will use, and I'm planning to convert that to a weekend workshop (probably 2 weekends, realistically) in the fall.

It's rarely a tool that kills a company, though. It's an attitude. It's not the tool's fault. If you use some Java (perhaps you need to be on the JVM, because you're doing Android development or because an external client wants Jars) but allow the better engineers to work in Clojure or Scala, you'll be fine. If you hire the New Guy CTO Who Really Likes Java and people are punished for using high-productivity languages, then you're fucked. (<whine>"How are we going to hire Clojure engineers?"</whine> "Train internal talent up to it, dumbass.") But you'd probably be fucked if you had that same guy and he was fixated on a different platform or language. It isn't Java's fault.

It's similar to the debate about Agile/Scrotum, in which defenders of these methodologies blame imperfect people for the messes that these processes often create. The Agile Manifesto is pretty reasonable, all considered. But the sorts of people who will impose Agile from the top down, as a justification for aggressive micromanagement and age discrimination (cf. the terminal juniority of a culture where even senior engineers submit to time tracking)... are also the sorts of people who will destroy your company if they ever get to make decisions that actually affect other people.

As for Haskell... I've never met anyone who regretted using it. Of about 20 cases where people put it into production, I've never heard of anyone regretting it. (I have heard regret stories about Scala, especially regarding the build chain circa 2011-13, though it may have improved.) There is one case where that company moved to F#, but it wasn't Haskell's fault so much as a standardization around the Microsoft stack.

Unsubstantiated FUD.

You have to be in a quiet environment where you can focus on the sound. Also, I've found better results with isochronic tones. Binaural beats pretty much mandate headphones and, even then, if you're in a noisy environment or there are defects in the headphones that have one side louder than the other, it can be quite "off".

It definitely alters consciousness, but I don't know if there's anything magical about beats per se, because drumming has been used to similar effects for thousands of years. Whether it does so by entraining the brainwaves, that I don't know. It seems like a reasonable guess, but the brain is far too complex for one to assume that such a thing as "an alpha state" exists: we actually have multiple frequencies at all times, and variation around the brain, and we're just starting to develop the technical capability to look at the complexity of all this.

The upper limit for senior people before they start to get pissed off is probably: the lowest of 10 minutes per week person, or 60 minutes for a weekly meeting, or 20 minutes for a daily meeting. So with a team of 8, you can either have a 60-minute meeting or daily 16-minute meetings. With a team of 4, you're limited to 40 minutes for a weekly meeting or 8 minutes of status reporting for a daily meeting.

Standups are good insofar as they allay toxic suspicion that <Person X> isn't contributing. They're like prisons: not innately good, but the aspect of human nature that they exist to control or mitigate is worse.

Of course, most seasoned people realize that the game of status reporting is like playing Scrabble. It's not about dropping the 100-point words. It's about not opening up the board (and getting nagged with follow-on questions).

Now, I believe you that most of these Agile methodologies were designed with better intentions. I absolutely agree. But they devolve. We've seen that, over and over and over. They don't fix things. They make tolerably broken things more intolerably broken. If you're in an environment where business runs the show and engineers just implement (i.e. business-driven engineering) then the right thing to do, often, is to become politically inert, silently learn new skills, and save your energy (slack) while opportunities are few so you can step up when the business-driven engineering regime goes away (or when you change companies). Scrotum gets in the way of that, and by putting such an emphasis on micro-estimates (numbers that will always turn into political tools) it generates politics.

Investor contact is another, related, one. When engineers accept 0.05% equity slices at the expense of hedge-fund jobs, they're doing it because they've been told (and haven't had the life experience to have doubts) that they'll have investor contact within 6 months if they do a good job, and have the connections necessary to be founders inside of 18 months. It almost never happens that way.

Obviously, trust has varying degrees and context. In Japan, you can leave your laptop at a cafe; in the U.S., you probably wouldn't. That doesn't mean that we're "low trust" or trust-sparse. We might generally trust most people to be decent while aware of the ~0.05% (?) chance per person (that someone steals the computer.

What is changing is trust with regard to competence. People were never so foolish as to trust all others without limits, but there used to be an assumption of competence in the professional world. Institutions like universities are less trusted, and so are people in general when it comes to basic competence and readiness for autonomy. It would be unthinkable, 20 years ago, that CS graduates from MIT and Stanford could be expected to justify hours of their time in "Scrum ceremonies" (which means that they aren't trusted, which means that their credentialing institutions and work experiences aren't trusted). Even average programmers in the bowels of Fortune 500's IT organizations had more autonomy than the typical "Agile" programmer today.

Right now we are in an era of organizational decline. It's not necessarily catastrophic; it might not even be bad. What it does mean is that institutions (universities, professional organizations, corporations, and even unions) have lost their role as central brokers of trust. It raises interesting questions. Thus far, most of the successful startups have been beneficiaries of institutional decline (and, again, some of those institutions deserved to break down, so I'm not moralizing) and there doesn't seem to be any economic reward to build institutions (as opposed to mere corporations, smaller in scope) up... so it doesn't happen.

    λ 1 `quot` 0
    *** Exception: divide by zero

Also, partial functions like `head` or `fromJust` can burn you:

    λ head []
    *** Exception: Prelude.head: empty list

In Haskell, exceptions in non-IO code (other than deliberate hard crashes) are generally considered a wart to be avoided and mitigated as much as possible (because they interfere with functional programming).

Yes, absolutely. It's amazing how overlooked this fact seems to be, by many. Languages aren't that hard to learn, so excluding the really awful ones (e.g. Java for anything other than code that has to be on the JVM and has to be fast) the "familiarity" aspect is minuscule. Programmers learn new languages quickly. What does matter is the community and the quality of programmer you'll attract based on the tools you use and the signals that your tools send about who makes decisions.

Second, when you're aggressive or even uncivil, it hurts you with that person. That said, it can be beneficial-- in very small doses. Punching down is bad, while punching up is risky (the best target is a person of high status, that is "punching up", and low character, but with no real power) and if you're perceived as being uncivil for personal benefit, you're just considered an asshole. Usually, uncivil behavior is to one's benefit when (and pretty much only when) one is perceived as being that way for the group: you're a protector. People tire of selfish rule-breakers and firebrands, but those who behave in such ways for group benefit tend to inspire loyalty.

Don't get me wrong: it's generally best not to be uncivil or arrogant at all. It's just not intellectually honest to say that it's always socially detrimental to be that way. You have to be extremely selective in your targets to make it work, though.

Chicago probably has the best salary/cost-of-living ratio and Budapest isn't so bad because it's cheap. Singapore, on the other hand, has NYC-level rents if you can't get into high-density housing.

It's not great for software engineers (compared to executives) anywhere but, at least in the other cities I listed, there's a fighting chance of them getting something beyond a college lifestyle.

If you don't have at least some engineers making money and getting to call shots-- I'll argue till I'm blue in the face that the current Valley culture doesn't have enough of them, but it has some-- then you don't get innovation. You get the same tired old ideas, sped along just slightly by a higher degree of technical efficiency (the rising tide).

I'd love to be wrong about this, but I've interviewed with a couple of Singapore companies in my life and the culture that I've seen is just not progressive nor is it pro-technologist. It seems to still be a world where businessmen call the shots-- but I'll admit: I don't live there. Given that it was difficult to get anyone but a bank to pay for relocation (I became "cat relo guy", for one place, because I mentioned that it'd cost $7k to move my cats... that negotiation, predictably, fell through) I'm pretty sure I never will.

Bonus points for realism in the burning hedges-- if you "New Game+" it and have the flame-thrower when you get to the Atherton level.

Of course, the breadwinners in those families (who finance the NIMBYs) get some karma when their trophy spouses (the ones pushing the NIMBY rules that prevent new development) give them stupid kids who'll require expensive and emotionally exhausting string-pulling in order to get them into schools. It's not enough, but it is something.

I don't intend for this to reflect on Google (he was a level 7 or 8, not a person of significance) as I'm sure that this dynamic exists, to the same degree, at all the hot tech companies.

It fails you if you have a monadic rather than applicative requirement on the computation; that is, if intermediate computations can require you to take more locks that you couldn't have predicted needing in advance. In that case, you're going to need a transactional-memory system that can abort and retry computations, and that is powerful but hard to get right.

So far, when VC flips its products on to the public markets, the markets react fairly rationally and the bad companies tank. Look at Zynga. The market may be overvaluing it still, but it's nothing like the 1990s. Public markets seem to be recognizing shitty tech stocks as what they are. So, we're not at the 1999 level of bubble.

Furthermore, the 2001 crash didn't have a major effect on the economy (although it was bad for the Bay Area, and for many engineers). It wasn't the crash, or even 9/11, but the sluggish ("jobless") recovery in 2002-4 that made the 2000s (except for people on Wall Street or in the slowly recovering Valley) a shit decade.

So, let's assume that the VC bubble ends. Some people will get hurt. The celebrity engineers who make $500,000 and aren't any good will get beefed. Run-of-the-mill engineers, if they're any good, might drop from $140k to $125k; not such a big deal. The ScrumDrone engineers will have a hard time finding work. Unfortunately, this will also hurt self-taught (meaning "no college degree") engineers even if they are good; the ones who are talented are still in a position of low leverage because "everyone knows" (well, employers know) they're more sensitive to a dry-up.

The short answer is that some people will take painful hits-- you're going to have a lot of 25-year-olds who thought they were millionaires, find out that they worked overtime for nothing-- but average people of average-or-better talent will mostly be fine. Bay Area salaries for good engineers might go down 10 to 20 percent at worst.

The bad news: housing in San Francisco's not going to become more affordable. First, the people who actually have money (not a half-million from options) are already diversified and less exposed to dot-com/VC, and the foreign money-launderers aren't exposed to it at all. Second, people hoard rather than sell (a steep positive volume/price correlation) when the market "should" soften. The stupid competitiveness around getting rentals (e.g. competitive open-houses, people cutting checks for a whole year's rent) will go away, but rents and prices will stay about where they are.

These methods take management strategies typically reserved for juniors and the underperforming and try to apply them to everyone. It's awful.

However, "Agile" and "Scrum" seem to mean different things everywhere. Some companies say they "do Scrum" but just mean that they have a 15-minute status meeting (which isn't that big of a deal; it's a minor annoyance but it actually can defuse politics and suspicion). Others haul out the whole shebang, with nightmarish "ceremonies" that take hours and involve beasts like "product backlogs" and "business user stories" meant to spread disease.

By "Scrum compliant", I meant the sort of mediocre (or junior) engineer who will accept being managed down to the day.

That said, I don't think that Agile or Scrum is the right thing, even for juniors. Junior engineers should be getting daily feedback, but it should be in the form of genuine doing-the-right-thing mentoring, not continual progress tracking.

There is a lot in software that takes more than 3 years to learn: machine learning (real ML, not tweaking off-the-shelf algorithms) and compilers and the like. The problem is that the man-child oligarchy that has taken over Silicon Valley (and, because of SV's influence, the industry as a whole, at least culturally) doesn't value fundamental or technical work (as opposed to doing "make the thingy work with the other thingy" Scrum tickets for a PM barely old enough to drink) so there are so few people doing it, and the competition for positions in real programming is quite high (and the salaries, sadly, aren't as good).

It's easier to get a real programming job at 30 than at 22, but fake programming jobs outnumber real ones by such a large margin. And when you're older and have a family to feed, being too old for the well-paid but fake programming jobs at the Hoolis becomes somewhat of a problem, because real programming jobs are so rare that it sometimes involves a cross-country move to get one.

Ergo, you're old and out of touch and worthless and go live on a programmer retirement farm in iowa because you're not a culture fit with the 22 year old CEOs anymore. yolo, and you wasted it by not becoming a billionaire by 28.

I think that attracting the "old" programmers to a specific city (possibly in the Midwest, say Chicago or Minneapolis, but possibly one overseas like Budapest) is the first step step in taking over the world. I'm not sure what the second is, but an industry that tosses people out just as they're beginning to get good at their jobs is (fuck this term in general, but here it applies) ripe for disruption.

A team player-- that is, a unionist-- is the last thing that Silicon Valley investors and executives want.

However, that older engineer will achieve more in an 8-hour day than the CommodityScrumDrone achieves in three 70-hour weeks.

Unless, you know, you orient the entire organization around replaceable, low-skill, "Scrum" compliant engineers and never invest in your people. Then you're striving for mediocrity and deserve to fail miserably.

Age discrimination isn't about competence (programmers peak much later than 40) but control. It exists because the VC man-child oligarchy (oddly enough, software inherits the age-discrimination culture from business-culture colonists who'd be "too old" to write code) thinks that people will work harder if this shitty, artificial time pressure is put on them. And, of course, much of the ageism and sexism is unintentional but still exclusionary. See: open-plan offices and the aggressive micromanagement of Scrum. I don't think Scrum and open-plan were devised with ageism in mind, but they contribute massively to the attrition. As people get older, they have less tolerance for macho-subordinate bullshit.

This macho-subordinate culture that is imposed on software engineers needs to die. It drives out an incredible amount of talent, makes us an HR nightmare as far as diversity goes, and it has nothing to do with programming; in fact, it detracts from the quality of what is produced. We have to kill it at any cost and professionalize our industry because we can't trust our financial backers.

It makes me fucking sick that people get downvoted for expressing unpleasant but completely accurate accounts of what is actually going on.

Also, hotel rooms, during the day, tend to be where one is when travel isn't going well. I used to think five-star hotels were a waste of money; why would someone pay $300+ more per night just to have a fountain in the lobby? But now that many of my friends are having children, I understand it. If you're traveling with kids (increasing your likelihood that someone gets sick, or just exhausted) then you need the 4- or 5-star accommodations that you don't need if you're a young person who'll use it as a crash pad only.

Hotel rooms, then, are places associated with misfortune: travel ruined by someone getting sick, an unexpected layover due to travel delays, or landing in a city where one feels unsafe due to local conditions like crime or dangerous weather. If your travel goes well, you're only in one to sleep. If it goes poorly, you spend an order of magnitude more waking time in it.

I think you've got a good 6-12 months before Haskell is more productive for you than OCaml or a C/Python/Lua stack. If you're coming from Java, you're more productive than you were at 1 month in Haskell (you still know very little Haskell, but you're pwning your former Java-toting self)... but in your case, you already know quite a few high-level languages. So it's not surprising that you get less done in a language that forces you to contend with monads (which aren't as hard as they're made out to be, but they're one more new concept) just to have state. If you're coming from Java, you're more productive in Haskell almost instantaneously, before you really even know it. If you're coming from Python, you're less productive day-by-day because the compiler keeps burning you, but you find long-term development going faster due to fewer code breakages. If you're coming from Ocaml... the short answer is that they're both great languages with more in common than not (although I prefer Haskell) so it's not surprising that it takes a while to get up to your prior speed (because your prior speed is so much higher than that of someone from Java).

Real World Haskell is a good book, though a bit slow and dated. Learn You a Haskell is a decent intro book but it has some gaps. I'm working on a Summer Haskell Course at my company and will be publishing the slides. And Chris Allen recommends the CS 194 course that Penn offers (you can find it online). Resources are out there.

First, Paul Graham isn't an expert on languages. He wrote a decent Lisp book, years ago. Relative to VCs, he's a technical genius. Relative to technical geniuses, he's a VC. I respect him for taking iconoclastic positions against the Establishment, and I miss that Paul Graham, but... he has serious blind spots when it comes to, say, statically typed languages.

Now, PG probably intended "Blub" to mean a mediocre language du jour like C++ (in the early 1990s) or Java (since the late '90s) but Blub is more of an attitude than a language. Yes, there really are one-language programmers who can't think out of a specific paradigm. They exist, and they're the ones who write FactoryVisitorFactory classes because they haven't been exposed to functional programming and the right way of solving certain problems. That said, there are cases where C or Java is the absolute right language to use. Not many, for Java, but they exist. Not everyone who uses those "Blub languages" is a mediocre programmer; Java is not always Blub, and C is definitely not always Blub (in fact, it's out of fashion among the Blubanistas, who avoid low level programming because "it's too hard".)

As for "Flub"... I don't even know where to begin. Just going to snipe specific points.

'Power' and 'Expressiveness' turn out to be separate concepts. In the end, there is no simple continuum that you can use to line programming languages up, nose to tail, feeble to awesome.

I agree with this, whole-heartedly. Assembly and C, I would argue, are more powerful than Haskell because it makes it so much easier to create custom control flows and to manage memory explicitly. Haskell is more expressive. You trade some power, in exchange for a language that allows you to write very robust code, very quickly. But sometimes you need that power and C is the best option.

To use it effectively, however, requires using an IDE, and Flubbists hate IDEs, partly because their finger muscle memory has been overspecialized from spending too much time in Eighties power editors, but also because using an IDE is too closely associated with Blub practices.

No, we dislike IDEs (actually, we don't; we dislike broken languages and codebases that require us to use IDEs) because it's a lot easier to keep flow when you're using the keyboard only. Switching to the mouse to recompile breaks flow.

IDEs also have a stigma because they're most useful when you're maintaining other peoples' code, which generally is a disliked sort of work given to juniors. So, IDEs tend to be associated with the second-class programmers who spend most of their time on maintenance work. I, personally, think the "reading code is for losers" attitude that many programmers cop is stupid and counterproductive. I enjoy reading good code and I wish that I had better tools for doing it.

A disruptive startup is more likely to use Blub in creative ways, focusing on the idea, not the implementation. Facebook dominated its market - using PHP - which everyone agrees is crap. Google built up the world's biggest advertising agency using Java and C++; Android is a Java-like ecosystem that runs in most pockets these days.

Oh, this shitty argument. "Your tech should be boring, your product should be interesting." Yawn. It's a bullshit argument and I'll tackle it another time.

Google was originally written in Python, which was more of a reach than Haskell is now. Python sucked in 1998. Also, the late '90s were a time when PL was considered to be a dead field, so PL never worked its way into Google's DNA and it's stayed that way. They use C++ because it was the best choice in the late 1990s, and they tolerate Java in the context of acquisitions, and when they tried to come up with their own language... the best they could do is Go.

Facebook started on PHP but is increasingly innovative on the language front, with Erlang, Ocaml, and Haskell getting a presence.

You put a group of merely good Lisp programmers on a project, and embed them in a corporate environment, and the stellar results are likely to be not reproducible. (I don't doubt they will be more productive than Java programmers. But will the result blend?)

"Will it blend?" I'm sorry, but I prefer not to think of my work as something that will be ground to a pulp. If that's the kind of work you want, then hire a Scrum drone, not someone like me.

Big companies understand this problem well, and prefer Blub programmers, who are easier to source and come with less attitude.

False. Do Haskell programmers come with more "attitude" than mediocre Java programmers? Yeah, there's probably a slight difference. However, the problem isn't "Haskell programmers" or "Java programmers" but people. People are just a pain in the ass: all of us, to some degree. Since you need 30 Java programmers to do the work of 5 Haskell programmers, you not only have more sources of "attitude" with the 30, but you have more politics and less per-person productivity on account of the larger team.