This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (5)
- # aws (12)
- # aws-lambda (5)
- # beginners (42)
- # calva (56)
- # cider (16)
- # clj-kondo (1)
- # cljs-dev (45)
- # cljsjs (1)
- # cljsrn (25)
- # clojure (171)
- # clojure-europe (3)
- # clojure-italy (16)
- # clojure-losangeles (2)
- # clojure-nl (49)
- # clojure-spec (2)
- # clojure-sweden (3)
- # clojure-uk (11)
- # clojurescript (84)
- # component (11)
- # core-async (12)
- # core-logic (2)
- # cursive (8)
- # datomic (41)
- # events (2)
- # fulcro (48)
- # graalvm (1)
- # graphql (1)
- # hoplon (12)
- # jackdaw (1)
- # jobs (1)
- # jobs-discuss (45)
- # joker (5)
- # keechma (10)
- # nyc (3)
- # off-topic (14)
- # pathom (16)
- # qa (1)
- # re-frame (22)
- # reagent (12)
- # reitit (4)
- # remote-jobs (1)
- # shadow-cljs (40)
- # spacemacs (3)
- # timbre (3)
- # tools-deps (29)
Trying to search for any near DFW, and it seems like it might end up being a .NET desert.
Either/or. Most of the Clojure action in TX does seem to be in Austin, but could also be a case where most public postings are going to be .NET / Java, but there's quieter roles that could be filled with Clojurians / other FP devs.
Might poke my nose in at Capital One, I hear they're at least a chunk more diverse with their tech.
yeah, if someone is already using the JVM then maybe you could start introducing Clojure
☝️:skin-tone-2: This was how I turned my current place into a Clojure shop. They’d been on the JVM for years and were open to anything that didn’t substantially change their workflow (at the time — of course, now being an all-Clojure backend, our workflow has changed quite a bit, for the better!).
Probably if you know a specific clojure stack really well, back to front, then adoption would be a no-brainer, because you can show people 'the way' for most problems Otherwise adopting Clojure would seem a more speculative/risky bet
Well, you’re unlikely to introduce any new tech unless you know it well enough to mentor the other folks you work with — unless, somehow, you get enough folks’ interest that they’ll all learn it on their own and then do a “grass roots” adoption.
:thumbsup: most adoption I have witnessed has been grassroots. everyone learns at the same time. But debt is accumulated during that path
Size of the project is also a factor. I’m ok with writing a one-off, minor utility program in a brand new language. but I’d be very hesitant to write something important in a language that no one on my team (myself included) knew well
At my current company we did it all the opposite: new huge project, very high profile, chosen as a team but everyone was new except me
https://clojurians.slack.com/archives/C0KL616MN/p1560466754052500 Clojure has spread to a handful of other startups in Charlottesville. We regularly have ~15 people at our meetups
What do you guys do at your meetups? We’ve got a Clojure Meetup in JHB with about 10 regular attendees. We have trouble getting regularly speakers, because we’re such a small pool and not everyone wants to speak. Thoughts?
you can see our list of topics here: https://www.meetup.com/Cville-Clojure/events/past/ we do not meet monthly, so it gives us some more time to line up content. Mostly people just give experience reports on a technology they use for work, or a personal project
> Otherwise adopting Clojure would seem a more speculative/risky bet in my experience: adopting new tool (language, framework, library) is risky only if there are people in the team opposed to this change. The biggest risk factor for the business, whenever such change is proposed is nothing to do with the semantics of the language, either it is dynamically or statically typed, etc. What that would be? Hiring. Management (mostly for the right reasons) concerned with that and they don’t care about potential technical benefits/drawbacks. And right now that seems to be Clojure’s Achilles’ heel. I am not sure exactly how, but I think we (Clojure community) should unite together to fix this.
@ag Most Clojure shops seem to say they’ve had a lot of success hiring “good developers” from other languages and training them in Clojure. There are certainly a lot of candidates out there who would love to write Clojure all day instead of what they currently write 🙂
I know, right? But we need more success stories such as yours - converting whole shop to Clojure. I have seen talks where people share success stories jumping from Elm (which is very nice), from Purescript (which is totally awesome) to use Clojurescript. We need more stories like that
I tried to hire on Twitter (was a mistake to ask to DM, should’ve included email instead). I got tons of DM requests.
I got people contacted me from all over the world. the US, Chile, Mexico, India, Bangladesh, Thailand, Australia, all over the Europe, Israel and Jordan.
People want to use Clojure full-time. The myth that it is difficult to hire people for Clojure was debunked almost immediately
However, most companies want either “highly experienced” Clojure developers or developers who are willing to “work-and-learn” and willing to take a cut in their salary
and most of those people are already senior engineers, they don’t want to downshift even for the sake of using Clojure
Yeah. That’s the other side of the coin: if you’re a small company, using Clojure, do you have the bandwidth/resources/etc to train devs in Clojure (regardless of their past experience)?
When we first started toward Clojure, we cross-trained internally (me + two others). Over time, we looked at hiring a junior Clojure dev but got so many “hopefuls” and realized we’d probably have to do the training/etc and that would be tough, so as the existing folks decided to move on (one back to the previous tech, the other on to another Clojure company), we decided to hire mid-/senior Clojure devs and that worked out.
It seems that our industry writ large always wants to hire “highly experienced” developers regardless of language. Though “highly experienced” often is taken to mean e.g. 3-5 years of industry experience.
> developers who are willing to “work-and-learn” and willing to take a cut in their salary I get why, but on the other hand that's just silly. You train someone and they will immediately leave if you underpay them...
I mean let’s not kid ourselves, although Clojure is really not that difficult to start with, mastering it takes months. Investing in Clojure stack and investing in training Clojure devs - is not a sprint, it’s a marathon, long-term investment.
But we can influence this narrative. We can convince businesses that ROI from hiring Clojure devs and from switching to Clojure is much, much higher.
If you’re hiring at a given level, you should pay at that level. Whether you choose to hire a “level X” developer for a “level X” position where they don’t yet know the core skill is a completely separate matter.
If a “senior” Python dev decides to apply for a “junior” Clojure role because they don’t know Clojure and want to learn, that’s up to them. If they want to stick with a “senior” salary, they should probably stick with applying for “senior” roles 🙂
I’ve turned down developers who I’ve felt were too senior for a junior role, who wanted to “work-and-learn”, precisely because of that.
Not sure how relevant this is to most companies, but I've tried to tackle larger/more difficult projects with Clojure than I did in other languages. They haven't all been successful, so instead of there being a bunch of projects that couldn't be done I ended up with a mix of successes and failures. I'm not sure if that's an overall positive, since the business side doesn't always have the ability to weigh the difficulty of the different things they've asked for.
As I said before: for businesses the choice of language doesn’t really matter much. They see it like: “FB was built with php”. Most fo the time they are worried about “what if we never be able to outsource this project, because we won’t find specialists?”
I figure every company has it's own weirdness - I was able to prove the value of Clojure on the first project and some business-level explanations and comparisons. I had non-programmer managers gush about very specific things I've been able to do for them to programmer friends of theirs and had them ask for presentations of how the code looked comparing similar problems. I was able to get buy in to use Datomic on a project because of what I could promise to be able to do with it compared to SQL. However, I still have this feeling in the back of my mind that unless I am wildly successful with every project someone is going to tell me to stop using Clojure and go back to what I used to use, and this is after using Clojure for the vast majority of my programming for the last few years. Of course, I'm the only programmer here the IT manager, so my experience is probably vastly different from working at a company with a larger dev team.
Isn’t that at least partly influenced by Clojure being so very different from the mainstream? There’s just so many attack vectors against the language, and every time there are very good reasons for things being different and is very often precisely the reason it works so much better, but you get exhausted defending Clojure at every turn.
Start compiling a list of things that are different. You start with parens? lisp? and end up with “you told me you could do what in how little time?” with little being 0.5 or less and people start looking at you funny
And so it ends up being the proverbial pudding that needs to be eaten. Every. Single. Time.