Ask HN: How do you sell in a new programming language?

My observation (at a Baltimore company) was the exact same. When you post Clojure job ads, your pool becomes national and get rock-solid people who'd be top-2% in the Java pool. The difference is night and day.

The location is a disadvantage, except for local candidates. (There is a lot of talent in Baltimore-- more than you'd think based on the city's reputation-- but the set is small and quickly exhausted for a larger company.) Great programmers who don't mind using Java or C++ have moved on to hedge funds or upper management in the Valley by age 30. Convincing them to take a risk on a geographic move won't happen. The Clojure pool is national-- there are some really great people who will take that risk if you can promise them full-time work in their preferred language. (Being able to make this promise is rare.)

That said, as a sell to upper management, this argument tends to be unsuccessful in my experience. It is 100% true. But the way it sounds is, "People who like the same languages as I do are way better." You can probably understand why managers are skeptical of that claim-- as true as it is.

What's happening in software is that, because 90% of the work in the industry is mindless, ticket-munching bullshit (CommodityJavaDrone stuff) the top programmers are all finding ways to distinguish themselves-- this is something you have to start thinking about by 28, and you have to have a path by 32, lest you be confused for a CommodityJavaDrone and be put on bullshit work (in which case you'll be flushed out by 40)-- as "too good" for junior-level, predigested grunt work. Some become "Data Scientists" or "Machine Learning Engineers" or "Research Engineers". Some learn a lot of nontraditional languages (Clojure, Haskell, Rust). The few who have the connections become startup founders. Others get "special" engineer titles in big companies (Principal Staff Architect XIV). You won't get anyone good (meaning top 5%) over 30 unless you can establish that the job is "special"-- that they won't be lumped in with regular ol' engineering plebes who have minimal autonomy and are basically there to do what they're told-- but managers see that price of talent as a political risk they'd rather not take. It's hard to address these sociological facts (as one of those "older" (30+) top engineers) without coming across as an arrogant twat. The CommodityJavaDrone engineer mentality is borne of a managerial misconception that those older, top engineers aren't needed, that one can just hire college kids on the cheap and mash them together as if they were all the same... but it's completely wrong. A tech company rots if it can't get top talent.

Some managers are extremely resistant to change because they work in organizations with extremely vertical power structures. Consequently, they know that even if they think it is a good idea, they are going to have to sell it to 15 different people and get each to sign off on it. In some organizations (government is an excellent example), a manager would have to write a report to get permission to write a report investigating a new technology. In organizations like this, experienced people (aka - management) generally have horror stories about the time they spent three years getting permission to upgrade all the computers to Windows ME...

That brings up another reason that some organizations are resistant to change. When the kinds of people who read Hacker News think of a new tool, they're usually excited. People like us equate change with learning and improving. Consequently, change is an adventure. Unfortunately, end users don't always feel the same. For these types of users, "IT change" is synonymous with "pain and torture". Consequently, getting permission to use a different tool is usually only the first step. When you actually implement the project, you get to deal with six weeks of whining, followed by another four weeks of training extremely resistant people. And then, for the next several months, every problem on earth is 'the new system's fault'...

And then, there are the sales people. Many managers have horror stories where a sales person convinced them that this great new system would do A, B, C, D, E, and F. Unfortunately, once the system is implemented, lo and behold, the system barely does A and B. If you've ever been through a situation like this, you'll be extraordinarily resistant to any new solution.

Once you know a little more about why your company is resistant to change, you'll be in a better place to make a decision. Maybe you work for a giant, monolithic entity that changes about as fast as granite erodes. In this case, you might have to decide whether you feel comfortable in a company like that. Or, maybe your direct manager got burned by a new tool and is forever paranoid. In a situation like that, you'd be better off implementing a one-off project with the new tool and proving that your solution actually works.

The general advice in situations like this is to show that a new tool will have a positive return on investment. That advice isn't wrong, but unfortunately, when people write about the ROI of a new tool, they usually focus on developer hours saved. While that is a good metric, in most cases, developer hours are just one component of a system's true cost. If you start your analysis earlier, you'll have a better sense of all the other costs involved and be able to speak to the real objections you will face.

I think 3) is a good tip, and I have seen it work for some local companies who moved to Scala (for parts of their code).

The technical leadership team was already interested improving the reliability and rigor of our web backend, but weren't thinking about exploring other programming languages. (we primarily use PHP)

I knew Haskell would be hard to sell, but I also had concerns about it myself, so I ran a live-fire test:

In my spare time, I wrote an interface-compatible Haskell implementation of a particular service that drove a lot of load, but was noncritical. I load-tested this service by flipping an nginx switch to divert traffic to the Haskell implementation. Leadership was ok with this because we could just flip the switch back if there were any issues: The risk of customer impact was miniscule. After some initial tests, we left it to run for a few months without manual intervention.

Over the course of this side-project, I got a few curious coworkers to learn Haskell to help out.

When the right project came along, leadership still had concerns, but I had lot of hard evidence to show that Haskell superbly fit our technical requirements and that the nontechnical problems (like hiring and training) were probably surmountable.

If you come to a C shop and implement something in VisualBasic, you will de escorted right out. Do the same but with Java and you will be flying out, through a nearest window :)

So - hell, no - it's not how it works at all.