Comment by sesm
2 years ago
Hiring open source rockstars is problematic, so is hiring resume-driven trend-chasers.
But I think that author is missing at least one more category: senior engineers that worked in multiple programming languages over their career, who can see how design of Gooby and values of it's community create a better programming environment.
Indeed. Category 3 seems to be about developers who insist on using Gooby regardless of whether or not it’s a reasonable choice for solving the current problem. What about developers who simply have Gooby as one tool in their toolbox, know how to use it, and enjoy doing so when an appropriate opportunity arises?
I once wrote some Haskell professionally. It was a successor to a previous generation of the application that I had written in Python and maintained for several years. Using Haskell was my choice and it was made because some of Haskell’s strengths would address specific pain points learned from that experience. Meanwhile, everything else I wrote for that client was still being done in mainstream languages for mainstream reasons and there was never any suggestion that we would rewrite anything else in Haskell or adopt it by default for any new work, so I think this situation is clearly distinct from category 3 in the article.
At this point pretty much any language you want to pick for me is a couple weeks’ ramp up time. I couldn’t really care less.
What’s the right language? Probably the language you’re already using for the rest of your stuff so we can interface with the rest of the org efficiently.
Is it new? Grab whatever the industry standard is for your segment. Lots of libs, lots of mindshare, easy to hire, get it done.
I do get caught in HR filters a lot without a bunch of projects in gooby though.
> At this point pretty much any language you want to pick for me is a couple weeks’ ramp up time. I couldn’t really care less.
When you learn a programming language for a few weeks, the knowledge will be very superficial. Rather consider a few years of additional learning outside and in addition to the job to be realistic to get a decent understanding of the very encompassing and non-trivial details of the programming language, its lore, its culture and its often huge ecosystem.
> Rather consider a few years of additional learning outside and in addition to the job to be realistic to get a decent understanding of the very encompassing and non-trivial details of the programming language, its lore, its culture and its often huge ecosystem.
Not really, unless you're trying to extract the maximum performance from the compiler, or you're trying to publish your own libraries. You learn Java, C# is pretty close. You know LISP and Java, you can pickup Clojure really quick.
As for the ecosystem, what you need to learn depends on the problem, not on the solution. If you need to do JSON parsing, you take a few days to investigate the available libraries, write your own parser if none exists. That assumes you know what JSON is and what serializing data entails. These are universal problems that exists outside of the Knowing Language X scope.
I'd much prefer hiring someone who can build web applications than someone who knows express.js.
The ideas begin to repeat after a while. I’m a bit of a rolling stone. Most folks tend to specialize but I get bored easily.
> At this point pretty much any language you want to pick for me is a couple weeks’ ramp up time. I couldn’t really care less.
This is the right attitude
It’s just not that hard. Problem domains are hard. If you asked me to work in computer vision that’d be hard for me. Same for high frequency trading. Asking me to write this device driver in rust versus nasty old C, whatever man, bits is bits. I lie about my experience in different stacks solving the same old troubles all the time.
Languages are boring. Problem domains can be a lot of fun.