I’m hiring for a weird stack. The people I’ve hired so far aren’t coming in with experience in that stack. They’re coming in with solid design and architecture foundations and enough experience in similar languages that I’m confident that I can develop in them the skills that I need. If I stuck to people with exact experience, as an uninformed recruiter would, I’d be looking for years. The person I hired with the least professional experience has the most experience in one element of the stack: she’ll hit the ground running while the more experienced people spin up on that and other elements.

I can teach languages and nuances of frameworks. I don’t want to teach good communication, collaboration, and teamwork skills.

This is a good take. It sounds like you’re emphasizing growth and learning. It can be fun to push your boundaries and grow as you learn a new language but if you aren’t supported by a company in that process you’re not going to be happy.

Most companies try to claim they’re pro learning and pro growth but then throw their devs in with the sharks on their first week. Taking steps to show candidates you’re serious about their concerns and actively taking steps to mitigate them will set you apart.

But they don’t throw the devs in with the sharks. New devs are thrown unceremoniously into the water, but usually with some nice Code Review brand floaties. If the company fired people for getting too many code review comments their first week, that would really be throwing them in with the sharks.

And if the company doesn’t do code review, what the hell are you so worried about? The company obviously doesn’t care about code quality anyway, so fire away. And maybe float your resume to some friends.

Very much this. When we were hiring for (failing giant social network), our lowest level code was in scala. At the time, nobody knew scala. But our best hires were the ones who knew a couple of other languages and were willing to learn something new. Your engineering chops are transferrable. Your syntax and library knowledge is not, but after you get 2 or 3 languages under your belt, you get to be pretty good at learning the local idioms. You’ll be fine. It’s your critical thinking and teamwork I want.

Almost completely greenfield development in Scala and Rust. Hints of groovy, Java, and standard web stuff. Mix of web development and on-premises server stuff. It might not be that weird, but I’m finding it difficult to hire precisely for.

Will be running Scala stuff everywhere we control the environment, which is in the cloud and certain portions of the on-premise installation.

For the Rust part, we concluded that C or C++ were the options given our “we know nothing about the environment except its kernel” requirements, but then decided that any new stuff in either of those should probably be done in Rust. A part of the role of the Rust app is to provision a JVM for a Scala app and monitor it and the environment in which it’s all running.

It’s pretty exciting and if it all works out, we could be using Scala and Rust fairly interchangeably across the JVM, JavaScript, WebAssembly, and native.

ecosystem is still maturing but it has everything I need right now and I’ve got time to sand the edges

a community that was exceptionally welcoming to new developers, because I knew that my team would not likely know it better than I do, which isn’t that much – I was very fortunate to find someone who has done a lot of Rust work in an internship!

shareable components

Rust has a WebAssembly target so that we could eventually take advantage of that

Rust beat out C, C++, C#, Go, Nim, and Pony. Scala was my first choice with a fallback to Ruby via JRuby or Elixir. It would have been easier to hire for Ruby in my area but I want to help build the Scala community beyond my former employer and a couple of others.

If Scala Native was 1.0, I might have chosen it over Rust mostly for personal preference of language ergonomics. However, I see a lot of promise for Rust and intend to use Rust where it is appropriate.

At the risk of being facile, my experience is that you can program better in those languages. The business value is whatever business value you were getting from programming, but more so; like, pick a point on the project management triangle, and you can get an improvement in those aspects.

Every time I talk to a recent grad I hear a vadriation of the phrase “I know how to code, I can code in anything”.

The other way this fails is languages not derived from ALGOL. I had this attitude a few years into programming when I knew HyperTalk, Visual Basic, PHP, and Python. I was corrected by diving into SQL, assembly, PostScript, Haskell, esolangs…

Algol-derived is a big one, but bigger is whether the language assumes mutable state is the default state of existence, and immutability is either inexpressible or tacked-on.

For example, Lisp isn’t Algol derived. However, Algol and Lisp are more similar than different on the level of how data moves through a program, because they both assume mutable state is the default, and an unmarked default at that, with relatively weak (if any) support for immutable state tacked on later, if ever. The essential similarity between Lisp and Algol is really pointed up by Scheme, on one side, and Python, on the other.

OTOH, declarative languages, such as SQL, and functional languages, such as Haskell, really break brains because their model of data is very different. Spreadsheets are another data paradigm: Automated data flow from cell to cell, in an implicitly parallel environment.

I was surprised when I learned that XSLT is a pure functional language, mainly because I didn’t find it that hard at all (my website is generated from an XML file via XSLT). Verbose, hell yes. Hard? Not really. But in retrospect, I can see the functional nature of XSLT.

APL derivatives, Lisplikes, Autohotkey, LabVIEW, Prolog, Excel… I’ve wondered what it would be like to construct a list of “basis” languages that cover all of the different forms of programming, and if such a list is even possible.

Where’s COBOL and BASIC in this? They each had huge impact. Main concept is that programming could be almost as easy as pseudocode for basic applications. A flawed idea but all kinds of people did productive things with it.

I think I omitted BASIC because it doesn’t influence enough other languages. Wikipedia lists Visual Basic, VB.Net, RealBasic (Xojo), and AutoHotKey. There aren’t any interesting crossovers with e.g. Lisp or ML.

Darn, I don’t know how I overlooked it. Apologies. I guess BASIC could be omitted on that criteria as COBOL already did the Code Like English concept. It’s overall a nice tree of languages. +1 for text art. :)

My attempt at that was to look at Wikipedia’s list of programming paradigms to find key languages for each. Filter out those that dont have FOSS implementation. Pick the best of them as far as stated complexity vs learning materials available. And you then have close to a list like what you’re looking for.

Just curious why does hosting your own matter? I did for YEARS but got sick of dealing with all the infrastructure work around it and switched to Wordpress.com - drives like a Cadillac and somebody else handles the security :)

A very good point. I think I prefer to use a tool I wrote to translate Wordpress.com <-> Pelican via their API to keep local Pelican ready copies of all my Wordpress posts, so if they ever pull anything shady I can bail back to my own blog.

I like Wordpress, but running your own WP installation is challenging on a number of levels. I love Pelican, but most of the time I have for blogging these days is when I’m on the road or public transit, and I haven’t figured out a good workflow for Pelican blogging from my iPad.

Ghost and Wordpress are comparable. However they both giant PHP apps which are challenging to self host in a secure way. There are lots of moving parts and if you’re going to do it right from a security perspective you have to be incredibly careful in locking down each piece.

I have the skills to do this, but the issue is it’s not even just a one time investment of time - you have to continue investing time to keep the installation up to date and ensure that your architecture continues to reflect best practice.

I hosted a Wordpress blog forever, and it got owned by a script kiddie who used it to gain shell access to my site and make a mess of things. It’s embarrassing to admit that, because I do infrastructure for a living these days, but that experience has left me with more respect than the average for the difficulties in securing a complex web application correctly.

Point taken about the hassles of selfhosting. However, Ghost has two things going for it. First, it’s a Node.js app not PHP. Secondly, Ghost is 60k lines of Javascript compared to Wordpress’ 480k lines of PHP.

Good lord! What in the world does Wordpress do? My own blogging engine is 16,421 lines of C code (yes, C, and yes, that line count is including the licensing verbiage on each file in both the main repository and the library I rely upon). It also supports three input sources, a webform (defaults to a textarea, so I don’t use it that often), a text file, and email (my preferred source—yes, I can email entries to my blog).

Yeah, it does a lot :) Among other things it provides a REST based webservice which most clients use for posting, really rich theming and plugin capability. Super good comment spam mitigation. The list goes on. Yes it’s a big drooly PHP app but for certain classes of use case it’s really hard to beat (although I haven’t evaluated Ghost in depth.)

I get that moves between languages can be uncomfortable, and are harder for some than others. The real danger is tying yourself down. Saying “I will only code in X” is a great way to end up obsolete. Saying “we only hire experts in X” is a great way to have no candidates.

I somewhat disagree. There are still people who write COBOL for a living and they get paid bank. If you love a technology then feel free to pursue using it to your heart’s content.

I think there is value in learning other languages. I’ve dabbled with BASIC, C, Python, Matlab, Octave, LabVIEW, JavaScript, and obviously Ruby. I’m not saying that you should be a language monogamist and never expand your horizons. Every new language I learn teaches me something regardless of how “similar” they are to a lang I already know. I’ve still not come across another language that feels better than Ruby does to me.

Would I ever work in another language? Sure. But while I’ve got options that include my preferred lang, the reasons need to be more compelling that “is a job”.

I do think companies need to write better requirements for jobs. Most of the “we need an expert” really means they would like an expert but will take someone with a pulse who has completed a “hello world”. Sometimes you really do need someone with a lot of experience for senior level positions. Most of the time the company has no clue.

I would say that you’re actually misinterpreting the lesson of the COBOL programmers. The COBOL programmers you see today are making bank, but you have to keep in mind that they’re the survivors of multiple rounds of layoffs that resulted in mass unemployment at the beginning of the ‘90s. In essence you’re looking at the top 1% or 0.5% of COBOL programmers, those that are good enough to get called out retirement at multiples of their original salary to repair legacy systems. You’re not seeing the ones who went on to different kinds of programming or left the industry altogether.

In addition, the problem with sticking to a single language for work is that if there’s another big secular shift in the industry (like the one away from COBOL), it can leave you unhireable. I’ve seen this initially with COBOL, and later with Perl. When Perl faded as a language for web development and was replaced with PHP, Python and Ruby, there were quite a few Perl hackers who had a really hard time finding work, simply because the only thing they had on their resume (in a professional capacity) was Perl. Meanwhile those who had Perl + Java, or Perl + Python, or Perl + C# had a much easier time getting work because they were able to lean on the non-Perl parts of their work experience to make a case that they would be productive in a non-Perl environment.

That said, I wholly agree that companies are terrible at writing requirements. The vast majority of developer positions do not require deep knowledge of the internals of frameworks or language runtimes. Usually, basic knowledge of algorithms, data structures, combined with surface level familiarity with language syntax is more than sufficient to ensure that a developer can become productive in a reasonable period of time.

However, the world we live in is a world in which employers filter resumes by keyword. In such a world, it makes sense to have professional accomplishments in as diverse a set of programming environments as possible in order to ensure that you’re not caught flat footed by secular shifts in the industry.

Great article. Everyone assumes that if you know Ruby you can pick up Python trivially and visa veresa. The truth is you CAN, but as the article details, the devil is in the details, and in particular, the idioms.

One that still bites me TO THIS DAY after ~3 years of Python is my brain still wants to default to:

My stance is Robert DeNiro’s. It’s a tool. You put the tools in the toolbox. It’s not so much that I can “code in anything”, as much as that I’m gonna have to learn your idioms and more important, your business domain. Those are bigger challenges than learning the tech we’re using.

This is super interesting - and it caused a lot of emotions to bubble up on reading. I’ve never been a spectacular coder. But I’m a terrific engineer (very imho). This has always been a conundrum for me.

The emphasis now is for “full stack developers”. However, stacks are getting very, very unique. I’ve never really seen two the same.

Nobody will know your stack. It’s much better to have someone who can navigate your stack. We put so much emphasis in hiring on writing code, but never how good people are at reading code.

Additionally, we put so much into “expressive” languages now. Programming Ruby isn’t Ruby. It’s a bunch of DSLs that you need to get your head around. The magic of Rails was they somehow assembled a bunch in one place.

“Write it in language X” is rarely a real requirement, but there’s always the option of creating a shared library written in something else and calling it from the target language. It’s a popular choice in Python because it isn’t particularly fast but has an easy to use CFFI.

True, but it’s usually a functional requirement. I mentioned I do a bunch of performance work. I do it in Ruby. I work directly in libraries like Rails to speed them up. Could I make Rails faster by re-writing the whole thing in C? Sure, but then it would likely not be Rails when i’m done and would also impact the productivity of anyone else who wanted to hack on the library (likely rubyists) if they did not also know C.

In my case I find hotspots and speed things up 5-20% at a time. It might sound trivial when if we wrote it in C we could make it 40,000% faster. But sometimes 20% is enough, and 40,000% isn’t worth the overhead to get there.

Sometimes “using the right tool for the job” is about knowing when the tradeoffs aren’t worth it. There is a need and a benefit for knowing how to optimize for performance of your code even if you’re not on the bleeding edge. Even if you’re in a “fast” language, if you don’t know how to write fast code you can still get in trouble pretty easy.

There are cases where bottlenecks have been found to the point that people choose to drop to the C level and write native extensions for example fast_blank gem gives a huge speed up over Active Support’s blank? method. This is not in the Rails dependencies. Other gems like XML parsing with nokogiri is in the Rails dependencies.

This is what you’re suggesting with “shared libraries” and in general it works pretty well. I say: make it, make it correct, then make it fast. Once you’ve identified your bottleneck then you can optimize for speed where you need it.

Author seems kind of hard on themselves at the end. If you’re introspective, working at your craft, and willing to learn, you already have most of the guard rails in place to stop yourself from creating a big ball of mud, even in a relatively new language.