Startups that bank on Clojure/Script

[Marc Fawzi]

fixed title.... would like to discuss in person with other interested folks if not suitable for the mailing list... :)

On Tue, Apr 14, 2015 at 10:06 PM, Marc Fawzi <marc....@gmail.com> wrote:

Hey everyone,

Would you say that Clojure/Script, owing to its relative obscurity and great design, can be a talent retention tool for startups?

I feel more motivated to go to work every day and more stickiness with my employer as a direct consequence of working with ClojureScript and Reagent.

Do you think this is a general phenomenon?

If so, what can we do to educate the VC community as to the advantages of funding startups that use Clojure/Script? Could this ever fly?

Or is it a situation where most of the world outside this mailing list (and a few other ones) views ClojureScript as a science experiment?

Just very curious. If the consensus on this is positive im sure a few of us determined souls would be inclined to *help* educate the VCs and startups thru a potentially crowd funded direct education campaign... Or community good will.


Sent from my iPhone

[Brian J. Rubinton]

Is your question more generally, are employees more engaged / productive / loyal when given the opportunity to use cutting edge tools? (and do VCs recognize such tools as a competitive advantage vs an unnecessary risk that makes hiring difficult?)

Or, is your question whether Clojure/Script is such a tool?

Personally, the only reason I considered my current employer is because the team is full stack Clojure. For me this is a huge source of job stickiness. I feel like I'm becoming a better programmer faster -- I'm learning more --  using Clojure than I would using traditional tools. For that reason my first question of any other opportunity is whether they use a tool with similar promise.

PG's "Beating the Averages" feels relevant here: http://www.paulgraham.com/avg.html
That's from the entrepreneur's perspective. Not sure whether the broader VC community agrees.

- Brian

--
Note that posts from new members are moderated - please be patient with your first post.
---
You received this message because you are subscribed to the Google Groups "ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com.
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

[Marc Fawzi]

I feel the same way and I assume many others share the sentiment and logic.

My question is about finding an angle to have investors like YCombinator (esp that PG is big Lisp guy) to favor companies that use full stack Clojure or at least ClojureScript. The angle I'm thinking of is like so: Clojure/Script is a talent retention tool and startups will do better if they use it, if only for that reason, but the bigger reason for startups to use it is that it helps programmers become better at their craft, leading to superior products and superior teams. If this theory is anecdotally "proven" then we can give plenty of real examples. 

Yup, just trying to find an angle, if there is one, to get more startups using Clojure/Script so we can all enjoy a bigger and more diverse ecosystem.... Surely, this is the same wish most practitioners have. So maybe we can get the community behind a Clojure/Script education campaign, or just seeding that thought.... 

:)

[Daniel Kersten]

My startup is full stack clojure. I wouldn't be able to stick the hardships of a startup if it weren't developed in something I care about. I also find that the community is quite passionate and, since it's still somewhat of a niche, it makes it easier to attract talent - quite a few people saying they want to use clojure(script) day to day but less competition from companies since fewer use clojure. We'll see how it pans out long term, but for now it seems beneficial. I suppose I'll fund out as we try to actually hire a load of these people if it helps or hinders us but it seems to add a little novelty value.

[Rob Lally]

In my experience VCs aren’t as interested in people trying to move quickly with niche technologies as they once were. 10 years ago it was different when people saw that a Rails team could get products to market faster than the existing enterprisey technologies and change direction faster than lightweight technologies like PHP. That was then, now most startups claim they’ll be fast because they have secret-sauce X & Y. A secret sauce is just assumed. They’ll ask what it is and grill you on it, and you can blow the deal that way, but you can’t win the funding on stack. 

On the other side, your tech-stack has to be exitable to attract their attention. They have to be able to imagine the potential acquisitors and how they’ll react to your choice of X. If they think it would put off the mosts likely candidates that might be a problem, but it might not - that’s a case by case judgement call.

The third aspect is risk: how likely is a startup to fail just because they chose the wrong tech? Startups are risky, and if you perceive people to be taking foolish risks in technology, that doesn’t inspire confidence.

So, where does cljs stand in respect to with those attributes? I don’t know. I might suggest, not too well, if only because so much rests on the inestimable David Nolen’s shoulders. If something terrible happened to him, or he got bored or was overcome with a desire to only program in VB6, or… well, I don’t know bright the cljs future is without him.

Outside of clojurescript itself the ecosystem is interesting but very 1-man project-centric. The only big exceptions are Om, back to David, or Reagent, which still has a low volume of commits and a small community.

Where was I going with all this?

tl;dr;

* Clojurescript may be a competitive advantage, but it isn’t an obviously dominant one. 

* It brings with it risks that would counterbalance the advantage from certain people’s perspective.

* We all owe David a lot and we should remember to thank him, let him know how much we appreciate him.. and perhaps take out top-flight medical insurance for him.

Rob.

[Marc Fawzi]

<<

* We all owe David a lot and we should remember to thank him, let him know how much we appreciate him.. and perhaps take out top-flight medical insurance for him.

>>

... a voice in my head says Clojure and ClojureScript are open source so there must be others involved in its development and it's not David alone... I've assumed it's a bunch of people and entities like clojure.org and companies like cognitect are also contributing to its development... 

Maybe I asked the question 2 years too soon. 

But I hear you on how VCs would think about it. So maybe they're the wrong crowd then. Maybe education should be as it's been happening bottom up and directly engaging developers who may be running their own companies....

That's a better overall angle.

Thank you Rob and I hope to see you again at Reagent meetup tomorrow either live or via Periscope. 

Dmitry Sotnikov is going to give a really good half an hour talk about Reagent, Om and Reagent-Template, followed by Dhruv whose talk about re-frame I'm really excited about, and a demo of reusable reagent components with app-state-troggered CSS transitions (and the challenges there) at the end of all of that.

[Rob Lally]

On 15 Apr 2015, at 18:12, Marc Fawzi <marc....@gmail.com> wrote:

<<

* We all owe David a lot and we should remember to thank him, let him know how much we appreciate him.. and perhaps take out top-flight medical insurance for him.

>>

... a voice in my head says Clojure and ClojureScript are open source so there must be others involved in its development and it's not David alone... I've assumed it's a bunch of people and entities like clojure.org and companies like cognitect are also contributing to its development… 

I don’t want to be seen as diminishing anyone else’s contributions, only recognising what David has done for us. A quick git analysis shows that he’s both the #1 and #2 committer to clojurescript:

git shortlog -s -n --all

  1562  David Nolen

   287  dnolen

   204  Brenton Ashworth

   164  fogus

    95  Michał Marczyk

    93  Rich Hickey

    89  Chouser

    74  Stuart Halloway

    49  Bobby Calderwood

    40  Frank Failla

    ...

Maybe I asked the question 2 years too soon. 

But I hear you on how VCs would think about it. So maybe they're the wrong crowd then. Maybe education should be as it's been happening bottom up and directly engaging developers who may be running their own companies....

That's a better overall angle.

Thank you Rob and I hope to see you again at Reagent meetup tomorrow either live or via Periscope. 

Sadly, work commitments will keep me away. I look forward to watching the videos though.

[Marc Fawzi]

I have been following David on Twitter and there was this one tweet he sent out that said "this is not Top Gun and you're not Maverick" and i take it to mean that if any serious individual or entity was to raise their level of contribution that he would welcome it. Also, a key contribution any of us can make is to the docs and comments. I think 80% of the intellectual capital is in the design of each feature/capability not the actual code specifics so if each so like with the infinitely less intimidating Reagent codebase my thinking is to create a ton of pull requests that help document the design wether its the missing design spec or the code comments. 

the W3C and its various working groups got one thing right which is the specification process 

so maybe the CLJS compiler can be documented by extensive unit tests that can convey how a given feature/capability should work (aka spec) and that would be all the docs we need to assure perpetuation of development 

Hmm.

Sent from my iPhone

[David Nolen]

On Wed, Apr 15, 2015 at 9:58 PM, Rob Lally <rob....@gmail.com> wrote:

I don’t want to be seen as diminishing anyone else’s contributions, only recognising what David has done for us. A quick git analysis shows that he’s both the #1 and #2 committer to clojurescript:

Haha, that's pretty funny :)

But seriously, ClojureScript is a Cognitect stewarded project same as Clojure. There are plenty of capable people besides myself able to push the project along and the initial design and effort by Rich Hickey and the then Relevance team continues to guide the direction of the project today.

Cool technology does not mean much without an active community. Eventually the pace of core development will slow down and likely sooner rather than later. Libraries, documentation, tooling, etc. will have a far bigger impact on the future growth of ClojureScript than any enhancements we might make to the compiler. Fortunately the amount of community activity these days inspires confidence in a sustainable ecosystem.

As far as the original topic, I don't have anything to add. There are plenty of people shipping great products with Clojure and ClojureScript today. How this translates to VC money is outside of my expertise.

David

[Nate Wildermuth]

Interesting questions!

The startup I work for (Nowthis News) made the switch to Clojurescript a few months ago, but I don't think our VCs care much about our tech stack. In my experience, they focus on metrics like growth rates, users, and views.

On hiring and employment, I can't imagine working anywhere else. I get to program in lisp all day long. But I haven't had much luck finding people to join my team. Would love to hear from anyone who's had success on that front!

[David Nolen]

Clojure(Script) meetups and the various conferences (Clojure/conj, Clojure/West, EuroClojure) seem like ideal places to recruit people :)

It's also been my observation that Clojure programmers are becoming increasingly more fluid about "front" and "back" end roles as the stack is quite enjoyable across the board.

David

[Alan Moore]

When constrained by a technology choice you may have to give up requiring other developers to be physically proximate.

I know managers want the comfort of observing warm bodies in cubes banging on keyboards but it doesn't necessarily translate into higher productivity, I get my best work done when everyone else goes home.

I've worked for <self-edit, a while> in cubes emailing co-workers in their cubes and I see no reason why we even have to be in the same building... confounding actually, "stand-ups" not withstanding :-0

Alan

[Joe R. Smith]

Having worked remotely for a couple years now, I can definitely say I’m far more productive.

This sums up why: http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/

[Marc Fawzi]

"The future has arrived, but it's not evenly distributed" -- William Gibson

I think the "remote vs in the office" issue is ultimately about our ability to achieve "eventual consistency" with the rest of the team on multiple levels spanning the inter-personal, cultural, process oriented and technical domains.

But the truth in today's work environment is that being in the office is less productive than working from your own office where you can shut out all distractions. It reduces productivity and increases distraction and therefore software defects by a critical amount and it does not solve the problem of getting everyone on the same page; it only alleviates it. Raw productivity is not the goal, so many companies prefer to bring people under one roof than let them loose on independent projects or going in separate directions on the same thing.

I think we could use better tooling for the remote lifestyle to make sense in the common scenario. But the tools for collaboration that we have are so so. Myself, i feel like a good balance can be attained between productivity and mission coherence. Maybe I'm wrong?

Sent from my iPhone

[Colin Yates]

Having worked remotely for nearly a decade I can say that when it works well it is unbeatable in terms of productivity, satisfaction, home/work balance and so on. When it works badly it is unbeatable in terms of lack of productivity, lack of satisfaction etc.

Delivering the software that the business wants depends far less on developer productivity then it does on communication. By orders of magnitude. I realise that we as developers are highly skilled, creative, specialist/generalists and so on, but I have seen many more projects that were built well but delivered the wrong thing then projects that failed because of developer insufficiency. Almost always because there is inherent ambiguity translating:
- what the business _thinks_ they want
- what the business _meant_ to ask for
- what the team _heard_ the business ask for
- what the developers _interpreted_ those requirements to be

It is communication that is our achille’s heel, not distraction, skill or tooling.

For me, if I haven’t sat down face to face and shown the key stake holders a realisation (i.e. working software) of what they asked for every other week or so I get very twitchy.

Of course, when there is a whole bunch of hidden complexity to solve then sure, working from home and getting your head down is great. All I am saying is that for the project as a whole, it can be exacerbate the fundamental thing success depends on - getting you and them in a room demonstrating what they asked for.

I should also say that a lot of developers (in my non-scientific and non-validated opinion) are prone to introspection and depression and isolation, which is sometimes what they most crave can be the absolute last thing they need.

My advice - work from home sure, but regularly get into the same room (Skype really doesn’t cut it. FaceTime neither as then you need to remember to put your pants on before work!) with the key stake holders and other team mates. Also make sure you have a _very_ disciplined and structured process for separating home and work life.

Anyway, enough ramblings from me.

[Alan Moore]

Ah, my bad. I should have considered the issue of problem domains. For my day job I don't work in an "enterprise" or business consulting context. I build specialty hardware products where just making it work is job #1, reliability is #2, time to market is #3. Feedback from product management is limited at best and primarily given up front, modulo some UI tweaking. 

Also, when I used to work in more typical sw projects, remote teams worked best when everyone is remote. Hallway conversations short circuit the communications and remote engineers are at a disadvantage unless there is good discipline/sharing.

I think this thread has gone somewhat off topic so further discussion should probably be carried on off list. I can be reached @coopsource on Twitter.

Alan
-- 
"Whatever you can do, or dream you can do, begin it. Boldness has genius, power, and magic in it. Begin it now." - Goethe

You received this message because you are subscribed to a topic in the Google Groups "ClojureScript" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojurescript/Eh4mfsIQqDY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com.

[Matt Ho]

@colin Couldn't agree with your comments on remote working more. The challenge for many early stage companies is that they require incredibly high levels of communication to be on the same page.

I also think part of the remote/onsite issue is the difference between efficient and effective. The pro camp seems to focus on efficiency (let me get work done) and the onsite camp focuses on effectiveness (communicate so we can do the right work done). Depends on where you are.

@marc The best way to attract an amazing community around cljs is to show people how you can build amazing products with it without a steep learning curve. If you think of cljs as a product, then learning curve can be thought of as the price you pay to benefit from it. Make that price low to free and show lots of value (e.g. ReactJS) and you'll get wide adoption.

[Marc Fawzi]

@matt

agreed.... 

however, I think "simple" not just "easy" is also "relative" (to the operating principle) For example, my toddler (just turned 2 yrs old) can count to 10 like we do but only if she bounces 10 steps, i.e. via synchronous body movement, but when shown 10 things she only recognize 1, 2 and Many, and 3-10 become just a fuzzy cloud of numbers, that she'll recite happily while moving her index finger around to point at the things but there could be 20 or 5 things and she'll still recite 3 thru 10, so it's not as 1:1 as when counting her own physical bounces, which materialize 1 at a time, and only 1 at any given time, versus all at once as in having X things in front of you.   

we have a long way to go to understand the complex mental context of "simple" 

the good news is building amazing products is the only way to go imo... no code is worth writing if the end result isn't fantastic

Thanks,

marc