It might just be the change from working solo to being part of a larger team, or possibly a large WIP in that team but I feel I always have to discuss, review, explain, talk to customers, business, hire... not much time in the day or week to sit down and think.

I do most of random thinking when out walking the dog or pushing a pram but without capturing it, it’s not very useful to anyone else.

I definitely feel your pain on this. For me, part of it is that I had to start accepting the fact that the "non coding" work has a lot of value for the organization. Especially when it comes to discussing/reviewing/explaining design and architecture issues with other developers / dev teams. I often long for the days where I can quietly code for hours straight. "Flow" is much harder to come by these days.

Sometimes, having flow is truly necessary. So I basically schedule entire days, or half days, for myself, where I completely turn off email and Slack. Important people can contact me in case of emergency.

I've also started to learn that being available all the time on Slack leads to a sort of "abuse" of my time. The abuse isn't intended evilly, but, as other devs (dozens of them) run into a question, they'll just fire off a Slack question to you at any time, in some deep context. This can be extremely interruptive. I've started to learn to tell people to send me an email instead, and I'll get back to them later.

I still don't have an answer. But to be honest, where I work currently there are lots of useless meetings. As we're working remotely now, I do most of my coding on then...

Scheduling “off days” sounds nice. Also the email bit.

How big orgs are you talking about?

We had 1 no-meeting-day a week before the covid-19. It was my most productive day, as a remote. Because of the whole company having to WFH, they decided to cancel the no-meeting-day, thinking that they needed to communicate more - unfortunate choice.

Why do you need meetings every day? Honest question. Is it scheduled meetings or just booking people’s times for matters as they appear? Do stand ups count as meetings?

Scheduled regular stand ups, 15~45 min long. It does count as a meeting.

Ouch that sounds long. Do you get any value out of it? We switched to daily “check-ins” / “check outs” on Slack as each member starts their day at a different time.

Personally not that much, as my work is not correlated to other people’s work, and when it does I talk to them directly by async written channels. My company was not a remote-first before covid-19. I would say that those meetings are legacy culture.

Maybe I should point the managers to some good Remote resources, now that they need it.

I’m caught between being a manager and needing also to code, so I’m trying to go back to first principles which can be exhausting.

The biggest question that came to mind was if the same criticism could be said of Clojure? In my opinion I mostly don't think it applies. The yearly State of Clojure survey speaks volumes of the community's influence of priorities. People have been able to contribute and don't need a personal relationship before being awarded the opportunity to contribute. As far as I know, people have not been actively banned for criticizing the language or even how its ran either. From what I understand Clojure can be forked and no one's going to threaten black listing you from the community for doing so. Though there have been a few defectors in the past who did feel they couldn't evolve Clojure in the way they desired. That brought some discussion about who owns the project vs who should own the project to the forefront. I don't feel I know enough to really commentate on that though. In that respect, I think Clojure falls between the author's expectation of how Open-Source communities should be and the alleged tyranny of Elm.

I think every OSS project that reaches a certain size has events like this -- someone loudly leaving the community for whatever reason and deciding to write some rancid "farewall" letter. Mostly for attention I think. We've certainly had a number of folks -- sometimes well-known for their Clojure projects -- leave under a dark cloud, publicly dissing the way Clojure is run... Scala has had the same... I've seen it in other open source language communities too.

"The second is that if you advertise something as Open Source, there is a common set of assumptions about what that means, some of which are explicit in accepted definitions of the term." -- ah, yes, whenever you have a project that isn't run according to some contributor's (would be contributor's) definition of Open Source, you're going to get complaints about someone else's definition of Open Source 😞

@U8WFYMFRU Have you watched Evan's talk about how hard it is to steward an OSS project?

https://www.youtube.com/watch?v=o_4EX4dPppA

Yes, I've watched it. In concept I agree, but I think that attitude can highlight its consequences if over-relied upon which is what was interesting to me about this post. By their account it seems that sentiment is used to shutdown ANY discourse.

Despite it echoing other defectors feelings, does that mean we shouldn't reflect on it?

I was fairly active in Elm early on. A couple of other people left early over disagreements on tone and direction -- they were very argumentative and confrontational, and the Elm community was nicer without them.

Oh, I'm still plowing through the guy's (long) post... I'll have more constructive/relevant feedback when I'm done.

Hah! I can definitely understand that sentiment, despite my thoughts on Clojure being between the author's ideal and Elm, I think that could be a good thing. I don't think projects benefit from everyone's hands being on the steering wheel but at the same time it should leverage what the experts it can attract may offer. Do you (or anyone) feel Clojure does that? Does Clojure need to?

I think Clojure does, unless I'm mistaken ClojureScript largely came from the community right?

Interesting! https://clojure.org/news/2011/07/22/introducing-clojurescript#_how_we_got_here looks like it was developed by the core team but perhaps inspired by earlier attempts from the community?

The most damning points made were around how critical voices are engaged and the double standards around purity for those in and outside of the core team.

Having a double standard isn’t wrong, necessarily, but acting as if those who need those tools don’t actually need them has got to be infuriating.

“I know that you need this to achieve X, but Elm will not have it b/c we don’t believe it’s best for the language” is hard to hear, but okay “You say you need this to achieve X, but you actually don’t and we’re not open to discussion on it” must be maddening

(I'm not a slow reader -- the wife decided it was time to make pizza for dinner so I was distracted)

Clojure (and ClojureScript) has drawn criticism for its somewhat unusual contribution processes (source on GitHub, issues in JIRA, changes only accepted via patches attached to JIRA issues) but that's how the core team prefer to work and it's not really much of a "burden" to do it that way rather than via pull requests.

Contrib libraries follow core's model, although maintainers have more freedom around the review process and how they develop each project.

Some people in the community really don't like that model -- witness Bug talking about nREPL for example

@U010GL90FN0 Oof that would be rough! Can you imagine how shitty this would be if Clojure was like, "You can absolutely not use Java or JavaScript. You don't need it." shivers

even though it’s happened several times over the course of a few years. i’m always surprised when I update clojure or clojure libraries and nothing breaks. it’s great! it seems like part of the frustration the author had is that elm was introducing breaking/limiting changes and making it hard to upgrade without major effort.

I wonder why the core team prefers JIRA for that? I don't know much about JIRA.

@U7RJTCH6J Also that the Elm team blocked every effort by the author to work around those limitations as well.

that’s the contention that the author holds. I don’t actually follow elm closely enough to know either way

Fair point!

btw, if you’ve never browsed through some of the closed issues on JIRA for clojure (or clojurescript), there are lots of gems and interesting design discussions

Rich has talked about his preferences several times in years past. He likes patch files he can read in isolation. JIRA accounts are somewhat limited in number, to folks who contribute directly to projects, since they migrated to the new host setup.

GitHub can be a real free-for-all so I totally get why they'd want to control the amount "churn" in terms of new tickets and commentary/discussion on issues -- I've been doing OSS for nearly 30 years now and you get a lot of comments and suggestions that just aren't practical/relevant for so many reasons and having to explain over and over again why you won't take a feature or even accept an open issue can be truly exhausting.

Evan and his close core team have always had a fairly "iron grip" on Elm and how libraries are handled. I suspect this Luke got fairly short shrift because he'd repeatedly clashed with the core team prior to the whole 0.19 debacle. I'd seen a few people essentially asked to leave the Elm community because they were disruptive. But the native module thing does sound very restrictive, at least in Luke's telling.

Elm is very opinionated -- to interact with JS in general you are supposed to use ports. It's a very clean system and designed to very specifically keep impure JS code physically separated from the pure Elm code.

Thanks @U04V70XH6 good to know! 😞 In checking out the JIRA I found https://clojure.atlassian.net/browse/CLJ-455. > Rich suspects almost no one should need these ops, and if you think you do, you're probably wrong. I don't want to point fingers here but damn 😩

That said, in context, that does seem more like an edge case than needing to reach the browser's internationalization APIs.

the workaround seems reasonable, and I think this kind of change makes it so everyone doesn’t* pay a performance penalty for a very narrow use case. if I remember correctly, two 64 numbers have enough precision to specify any coordinate in the universe within a meter or something like. so it’s not that you would never need more precision than that, but it’s certainly not very common

Yeah, the 1.3/1.4 numeric changes in Clojure were very controversial for some people. The bottom line was: you shouldn't pay for what you don't use (which was C++'s design mantra too, by the way).

😅 That's cool to know! Though it does give one pause if trying to write a teleportation system in Clojure.

The 1.2/1.3 changes were also very disruptive -- that's when "monolithic Contrib" was split up and many modules were essentially discontinued -- and some parts of the 1.2 ecosystem simply didn't run on 1.3 (due to AOT compiled code not being compatible).

Re: numerics -- the argument was: if you know you need that precision, be explicit -- don't rely on auto-promotion (which slowed down math pre-1.4 for everyone).

Would it be worth starting a community-development discussion around possibly deterring responses like that though?

I don't think it's a problem that needs a proactive effort at the moment?

(and I'm not sure which "responses like that" you're referring to?)

I was referring to responses like "You don't need x. If you do, you're probably wrong." type of responses. But you're probably right 😄 and it's more than likely to become a can of worms anyway.

It's hard to read the tone of that when it's quoted outside the (long) discussions that it was part of -- and it's not Rich himself saying that, it's someone saying "that's what Rich said" (I'd have to go digging for Rich's exact quote -- but those were some very long and fairly fractious discussions way back when).

And, to be fair to Rich, he is sometimes called upon to justify some of his decisions over and over and over again, often by people who haven't taken the time to think carefully about the bigger picture...

Of course, I understood Rich didn't say it. I just meant like we as the community could decide if responding to issues like that is acceptable or not at least for ourselves and to each other. But once you :thinking_face: about it, it really comes down to the nuances and like you said, it's not really the words but the intent.

It really doesn't matter whether we (community) think it's acceptable or not. It's not going to change how Clojure (the project) is run. It's up to each person to decide whether they want to use a particular project, given how it is run. Those sort of responses make zero difference to the vast majority of Clojure users anyway. They tend to only impact a handful of people who interact closely with the core Clojure project itself.

You can use Clojure happily for all your life and never need to confront that.

I've been using Clojure for a decade and maintaining OSS projects all that time and I think it wasn't until Clojure 1.10 that I had a patch accepted into core itself (and it was really only backporting a tiny fix from a later version of one of the Java projects that Clojure vendors internally).

That was the only time I had to deal directly with how core is managed. I've managed five Contrib libraries and assisted with maybe half a dozen others -- and I have to follow the core team's preferred process for those, but the bar is nowhere near as high as for core.

You're right, I hope this wasn't misinterpreted as me coming after the core team or anything. The reason I brought it here was in case there was something to be gained from the article to improve ourselves as individuals, project owners, or future project owners. Additionally there wasn't really any counter arguments made in the article (at least at the last time I read it) so I'm glad you were able to make it less black and white.

I also learned about JIRA discussions, and that 2 64 numbers can refer to most of the universe within a meter 😄

TIL 🙂

Another point you brought to mind is that it's easy to relate to the author because most of us don't have experience maintaining a large project like Elm or Clojure.

Having taken public feedback before, the advice I would give anyone giving it is to remember that, on the one hand, your perspective is valuable and the person working on the project will do a worse job without it than they will with it But that you aren’t entitled to a fix that does what you want it to do, or even a fix at all

And if you legitimately need something and the maintainers aren’t interested in providing it, look carefully at the kinds of discussions you end up in. Look at how you are being treated. If you are not being listened to, or talked down to, you don’t have to participate. They are not entitled to an argument

And arguing in response to folks who aren’t engaging respectfully isn’t going to make anything better.

Yeah, as a maintainer you're in a hard place: if you don't engage with people you get accused of being out of touch and ignoring your users, but if you do engage them, the argument isn't going to go anywhere productive and you risk being drawn into something very unpleasant.

I’ve never been a maintainer, but I’ve had to respond to book reviews. You want/need to engage, but if you end up in an argument, nothing good can come of it. The book is what it is, and either you have the capacity to fix something in the next edition or you don’t. And you can’t respond to everyone.

@U010GL90FN0 may I ask what book you published\wrote?

https://www.amazon.com/Android-Programming-Ranch-Guide-Guides/dp/0321804333

first 3 editions

I have made a terrible mistake https://www.amazon.com/Bill-Phillips/e/B000APJV32%3Fref=dbs_a_mng_rwt_scns_share

it’s a good name. i think I wear it better tbh

might not wear a t-shirt better though

I think that the differences between Clojure and Elm are even more fascinating than the similarities

sure, there are surface level similarities in that there’s a BDFL and most contributions come from one company (though not all!)

but the responsibilities and values that the two BDFLs hold are completely different. I would argue, in opposition

talking about two people like this is weird, but Evan’s stated stance and behavior when it comes to language, libs, etc. is completely against Rich’s stated stance and behavior since after some of those breaking changes in 1.3

for me personally, my continued investment in Clojure after some of the more public departures of prolific users has only been because I spent time reflecting on what the core team’s stated values and beliefs were, and I concluded that they aligned with mine. importantly: • Don’t break users • Encourage and provide tools for experimentation and extension in user-land Evan’s behavior in continually breaking users and discouraging experimentation and extension in user-land (even removing tools for doing it!) would have absolutely killed my passion for the language. Now I’m glad I haven’t bothered to invest in it at all.

There are standards of open source development by which clojure is pretty closed source; but I’m having a hard time thinking of a standard for open source development by which Elm qualifies as an open project. The scope of Elm’s leadership is all-encompassing; even libraries and proprietary projects must abide by leadership’s vision for the language

Ofc everyone is free to run their project as they choose

yeah I see Elm’s behavior not just antithetical to open source, but good software

i don’t follow elm closely, but it’s unclear how true the original author*’s assertions are

Two differences between Clojure and Elm: • Breakage. For Clojure, "you should be able to update and experience no breakage". For Elm: "you should do the migration work, we'll publish a guide and it's not too bad". • Extensibility. As a Clojure user, there's not much you can't do that Rich can. With Elm, the compiler is hard-wired to ensure that only the core team writes JS-code directly (directly /= through ports). Imagine not being able to call Java except through officially sanctioned Cognitect wrappers for Java libraries. That being said, I've really enjoyed the Elm code that I've written. The amount of help the compiler can give you is fantastic. As a team, especially with beginners, that's a fantastic feeling.

@U8WFYMFRU Given the huge interest (73 replies counting), perhaps a discussion on ClojureVerse would be good?

Hmm… I don’t think so personally. I can’t stop anyone from doing that but I don’t think the way I framed it was right. Fortunately it’s been very civil and the verdict has been mostly positive for Clojure. On the other hand my framing is kind of like “Grab a pitchfork and choose a side!” Additionally after hearing Sean’s side of it, it doesn’t seem as black-and-white as it did when I first posted it. I emphasize with the author and the frustration of breaking changes with no opportunity to fix them, on the other side maybe the Elm team decided it didn’t want to be a thin syntax wrapper around JS like a hosted language but try and be a full, self-hosted language with minimal interop? I don’t think either party is right or wrong for wanting what they want.

Hmm, I thought the way you framed it was fine. In an ideal world, we might be able to say just factually true things all the time. In reality, most of us have to contend to be part in a play. Being part in a discussion. Saying what we find to be true, and hoping that sharing it with others might bring something good. And I find civility in how we face criticism much more valuable than being able to anticipate any criticism in advance and avoid it. Thanks for starting the thread anyway :)

> And I find civility in how we face criticism much more valuable in being able to anticipate any criticism in advance and avoid it. I ❤️ that! My aim was reflection, not judgment but I'm not confident I always know the difference. Either way I have no more claims to this link than anyone else so if you wish to take it to ClojureVerse, please keep what you wrote in mind 😄