Ask HN: As a non-engineer, should I join a startup because it uses Clojure?
13 comments
In my experience, the highest "times 10" productivity comes when developers are motivated and passionate about the work they are doing. (Along with having a baseline of skill of course.)
Great developers can be passionate about niche languages and in the short term it could be a recruiting tool for exceptional developers. But you have to balance that against the fact that if your chosen language is too far outside most other developers' experience you're greatly reducing the pool from which you can hire.
Let's say somehow you are able to find a team of five truly energetic self-managing Clojure developers. Yes, I would back that team if they were up against 25 average developers and associated managers.
But then how're you gonna scale? You can't just take normal developers, teach them Clojure, and expect them to get Clojure fever the same way your group of self-selected experts had. I mean, they are professionals and they will learn it, but you will end up with an ordinary development team simply using a uncommon language.
You cannot beat regression-to-the-mean simply by choosing a different development toolchain. You can only beat it by hiring the right people, often those who tend to fall through the cracks of traditional HR processes, and letting them recommend the tools.
Great developers can be passionate about niche languages and in the short term it could be a recruiting tool for exceptional developers. But you have to balance that against the fact that if your chosen language is too far outside most other developers' experience you're greatly reducing the pool from which you can hire.
Let's say somehow you are able to find a team of five truly energetic self-managing Clojure developers. Yes, I would back that team if they were up against 25 average developers and associated managers.
But then how're you gonna scale? You can't just take normal developers, teach them Clojure, and expect them to get Clojure fever the same way your group of self-selected experts had. I mean, they are professionals and they will learn it, but you will end up with an ordinary development team simply using a uncommon language.
You cannot beat regression-to-the-mean simply by choosing a different development toolchain. You can only beat it by hiring the right people, often those who tend to fall through the cracks of traditional HR processes, and letting them recommend the tools.
I'm very much a Clojure enthusiast and run the local Clojure user group.
But, as a non-engineer, I don't think it really affects you enough to factor into the equation.
1) Will Clojure provide a competitive advantage in terms of cost savings and productivity?
Maybe. If they're experienced at Clojure and are good engineers to begin with. But its not likely enough to base your decision on.
(I argue and hope that it does provide productivity advantages for a variety of reasons, but I wouldn't be confident enough of this to base your decision on)
2) Will Clojure provide a hiring advantage because engineers are excited to work with it?
Maybe. Are there excited Clojure enthusiasts in your area who want to work on it? In my own experience, this may very well be true - I interact with a lot of enthusiastic programmers hoping for a job using Clojure in the user group. But, again, I'm not sure this is proven enough to base your decision on. Again, in my experience, the global Clojure community is exceptionally skilled and talented and have good sensibilities about what makes good, understandable, solid code and all Clojure developers I have spoken to are very happy writing Clojure. So if you can tap into these people, then that is definitely a positive for the company, but I'm not sure it will make or break the company.
Bottom-line is that Clojure is unlikely to be a top 3 contributing cause for success or failure, so, as a non-engineer who doesn't get any personal satisfaction from the language, I don't think it should be a major factor in your decision.
But, as a non-engineer, I don't think it really affects you enough to factor into the equation.
1) Will Clojure provide a competitive advantage in terms of cost savings and productivity?
Maybe. If they're experienced at Clojure and are good engineers to begin with. But its not likely enough to base your decision on.
(I argue and hope that it does provide productivity advantages for a variety of reasons, but I wouldn't be confident enough of this to base your decision on)
2) Will Clojure provide a hiring advantage because engineers are excited to work with it?
Maybe. Are there excited Clojure enthusiasts in your area who want to work on it? In my own experience, this may very well be true - I interact with a lot of enthusiastic programmers hoping for a job using Clojure in the user group. But, again, I'm not sure this is proven enough to base your decision on. Again, in my experience, the global Clojure community is exceptionally skilled and talented and have good sensibilities about what makes good, understandable, solid code and all Clojure developers I have spoken to are very happy writing Clojure. So if you can tap into these people, then that is definitely a positive for the company, but I'm not sure it will make or break the company.
Bottom-line is that Clojure is unlikely to be a top 3 contributing cause for success or failure, so, as a non-engineer who doesn't get any personal satisfaction from the language, I don't think it should be a major factor in your decision.
> An intriguing opportunity lies at a startup whose CEO keeps pitching me on the fact his company uses Closure, which is supposedly a hot new language? He claims Closure will provide a material competitive advantage because of potential cost savings.
No.
And I think you mean Clojure: https://en.wikipedia.org/wiki/Clojure
No.
And I think you mean Clojure: https://en.wikipedia.org/wiki/Clojure
Use of Clojure in and of itself is not likely an indicator of anything.
In some cases, choice of tech-stack can provide competitive advantage.
You could ask the CEO for specifics on competitive advantage Clojure provide and evaluate for yourself if it actually does.
In some cases, choice of tech-stack can provide competitive advantage.
You could ask the CEO for specifics on competitive advantage Clojure provide and evaluate for yourself if it actually does.
It's definitely a common sentiment in the LISP community. It's probably valid if your tech is not linked to some platform/language/env that doesn't work well with Clojure.
I'd say the main argument against it, is that a decade ago the divide between LISPs and stacic languages (basically the mainstream at the time) was indeed huge. While today if you don't use a LISP you're probably going to go with a fairly dynamic and functional language anyways.
I'd only be wary if he has an absolutely religious conviction it's true. If it's an educated bet then it's fine in my book.
I'd say the main argument against it, is that a decade ago the divide between LISPs and stacic languages (basically the mainstream at the time) was indeed huge. While today if you don't use a LISP you're probably going to go with a fairly dynamic and functional language anyways.
I'd only be wary if he has an absolutely religious conviction it's true. If it's an educated bet then it's fine in my book.
No. This is not an advantage.
Any average developer can probably write something in Ruby/Rails at least 2x faster(in developing time) than the best clojurist alive if the startup in question is a web app / mobile app. And this matters for a startup, time to market.
If the startup has a very complex business domain, needs some deep data science to be done, machine learning or some sort of thing, it might be a good indicative that they use clojure, but there's like 10.000 things that you should care before if they use clojure.
There's a lot of companies that are about raising money, picking a weird stack, hiring a bunch of hipsters and then running out of money and closing operation. I know people who are programmers that know that the company product sucks and just stick to the company because of the tech stack. As non-founding engineers don't get that much stock options it seems a good idea to work for a company with some fun stack that pays well enough even though you think the product is shit.
As you aren't a programmer, you should look for companies where you see that the business makes sense. Tech tools rarely end up as a big market advantage.
What makes all the difference is having great managers, board, C-level, culture... and of course, a decent business model. With a competent team, good business model the team will apply a tech stack that is good enough to solve the situations at hand a move the company forward. And this won't evolve just one programming language, just as you can't create a big company just doing advertising, or just having only finance people. You need all kind of skillsets and this also applies to tech.
Clojure? Last concern.
Any average developer can probably write something in Ruby/Rails at least 2x faster(in developing time) than the best clojurist alive if the startup in question is a web app / mobile app. And this matters for a startup, time to market.
If the startup has a very complex business domain, needs some deep data science to be done, machine learning or some sort of thing, it might be a good indicative that they use clojure, but there's like 10.000 things that you should care before if they use clojure.
There's a lot of companies that are about raising money, picking a weird stack, hiring a bunch of hipsters and then running out of money and closing operation. I know people who are programmers that know that the company product sucks and just stick to the company because of the tech stack. As non-founding engineers don't get that much stock options it seems a good idea to work for a company with some fun stack that pays well enough even though you think the product is shit.
As you aren't a programmer, you should look for companies where you see that the business makes sense. Tech tools rarely end up as a big market advantage.
What makes all the difference is having great managers, board, C-level, culture... and of course, a decent business model. With a competent team, good business model the team will apply a tech stack that is good enough to solve the situations at hand a move the company forward. And this won't evolve just one programming language, just as you can't create a big company just doing advertising, or just having only finance people. You need all kind of skillsets and this also applies to tech.
Clojure? Last concern.
> Any average developer can probably write something in Ruby/Rails at least 2x faster(in developing time) than the best clojurist alive if the startup in question is a web app / mobile app. And this matters for a startup, time to market.
Bahaha that's so false. Sorry I'm not laughing at you, just that it's not true.
Bahaha that's so false. Sorry I'm not laughing at you, just that it's not true.
As much as I want to say yes (I would be horribly excited to work with Clojure) it seems to be something of questionable value to a non-engineer.
Depending on the application there is probably a productivity advantage and you're certain to find a small number of very talented engineers. After that you may have to train engineers. If its a more interesting / profitable project you can expand the hiring pool by looking globally. Famously, Jane Street uses OCaml and it works out well for them.
I'd say yes in two scenarios, if you want a smaller team (and dont need to scale up too much in number of engineers; although you can switch languages later if the company begins to succeed) or if you have a more specialized project that benefits from the language and probably needs more of an academic background.
Depending on the application there is probably a productivity advantage and you're certain to find a small number of very talented engineers. After that you may have to train engineers. If its a more interesting / profitable project you can expand the hiring pool by looking globally. Famously, Jane Street uses OCaml and it works out well for them.
I'd say yes in two scenarios, if you want a smaller team (and dont need to scale up too much in number of engineers; although you can switch languages later if the company begins to succeed) or if you have a more specialized project that benefits from the language and probably needs more of an academic background.
Clojure is a nice language, but it's not magic.
Other unrelated questions:
Are they going to pay you at market rate? (Are they going to pay you??)
How much equity would you get? (My usual joke is that if it's more than 20% you are a cofounder and if it's less than 2% you are an employee.)
Other unrelated questions:
Are they going to pay you at market rate? (Are they going to pay you??)
How much equity would you get? (My usual joke is that if it's more than 20% you are a cofounder and if it's less than 2% you are an employee.)
And between is the new fangled "founding team" bit?
1) It may. Depending on the problem they are trying to solve.
2) It will have some appealing for some developers yes, but the pool of talent will be smaller than a more mainstream language
2) It will have some appealing for some developers yes, but the pool of talent will be smaller than a more mainstream language
You already have the necessary experience to answer this question. The people and the business are more important than the technology.
Using Clojure will not prevent the CEO from turning out to be a maniac and hothead.
Using Clojure will not prevent the CEO from turning out to be a maniac and hothead.
Hahaha... This post made my day.
I used to work in private equity (sorry!), but I recently left the dark side to join the startup world. Unfortunately, the CEO turned out to be a maniac and hothead. I resigned recently and am considering multiple opportunities.
An intriguing opportunity lies at a startup whose CEO keeps pitching me on the fact his company uses Clojure, which is supposedly a hot new language? He claims Clojure will provide a material competitive advantage because of potential cost savings.
Two quick questions:
1) Will Clojure provide a competitive advantage in terms of cost savings and productivity?
2) Will Clojure provide a hiring advantage because engineers are excited to work with it?
Thanks!