Clojurians Log v2

Do clients come to you for Clojure, or is it something you introduce?Both. Some clients come because I know Clojure. Others come because I know software development and they trust my judgement when I say that I'll use Clojure. > If you introduce it, how often do potential clients freak out? Depends on what you mean by "freak out". I usually have long-term clients so the sample isn't that large, but I have only a single client who isn't happy about Clojure. But only because of two reasons: • There are other people working for that client, none of which have any desire to become familiar with the language • The client just doesn't like Lisp > Do you work for a specific niche, or with a diversity of clients? I have three currently active clients, two of which are long-term with various load. One is in genetics. Another is in education. The third is in HR. But I suspect that different people will have drastically different experience, and a lot of people aren't at liberty to tell, so hard to gauge how useful any such answers could be.

Thank you for sharing, @p-himik! On top of that, most will not even see the question. So, yes, it's just anecdotal; no conclusions can be derived from a one case or a few. Still, it's interesting to know how/what some are doing.

Right. Well, feel free to ask follow-up questions, if you have any. It's my day off and I'm having a beer, so I can talk your ear off. :)

Awesome! First, what's your beer style? 🍺 Then, how did you get started with solo development in Clojure? Did you have a clj job before and then became independent, or did you start on your own?

> First, what's your beer style? Definitely not IPA or Guinness. Hard to tell besides that - I very rarely drink. > how did you get started with solo development in Clojure? I don't know where I first heard about Clojure, but somehow I was always intrigued by lisps and Clojure just appeared on my radar at some point. It was right before I tried getting an regular job at a "Java shop" (they paid well), and they decided to experiment with the admission test - there was only a task that needs to be done and there were no constraints whatsoever, so I decided to use Clojure. Oh, you can still find it here: https://github.com/p-himik/xored_task 12 years ago, dang. It ended up landing me that job, but I was using pretty much exclusively Java there, and for a gnarly enterprise project for Cisco. After a couple of years I was done and decided to try my luck with freelancing. It just so happened that right during that period a friend mentioned Toptal to me. I tried getting there, it was no problem. Got my first client there after a couple of months of filtering out projects and rarely applying to some that seemed interesting. Initially the client wanted only some simple Python scripts, but it ended up being a complex CMS in Clojure for education-related data, and I still work with that client. Although he has bought me out from Toptal ages ago, so we work directly. The genetics-related client from the Netherlands just knew me from my work with other people in the Institute of Cytology and Genetics in Novosibirsk, Russia, years ago. I just came to the institute people at some point because I was interested in genetics and wanted to work for them for free - just for that interest. Apparently my work and also the people accepting that work were good enough for me to actually get paid on par with that other client. And when the genetics-related client got to know about that, they decided to hire me. And the third client learned about me through this Slack and my active participation. And there were a few others like them as well. All in all, it's a mix of whole lotta luck and a decent amount of effort that was mostly focused around avoiding things I don't like.

Very nice. This is encouraging for me, since I left my job (one that wasn't awful but wasn't exactly my calling either) earlier this year with the aim of working as a freelance, on climate change-related stuff (which is a gigantic space). I've considered the idea of looking for interesting things to work on for free since money is not my main concern at the time and it could be fun and even lead to opportunities. Your Netherlands-genetics story is encouraging in that direction. I mean, it could also have led to no paid work, but seems like a good thing to do anyway if it's possible.

And I can totally see you being hired from your activity here. You add a lot of value! Many times I've learned things from threads you replied to —even on topics I hadn't even considered.

Thanks. :) I can only add two things: 1. Increase your luck factor. It's impossible to a priori judge what approach is the best, but any approach is better than none. Most often, it's just anything that lets some new people learn about what you're capable of. 2. To some, this might sound like a personal attack, but it's just something that anyone could benefit from, me included - work on developing your critical thinking. Even if somehow there's objectively nothing to improve upon in one's particular case, it never hurts to hone your blade, so to speak. In fact, now I think that earlier I misrepresented myself a bit. It seems that, while at least some of my clients start working with me because of Clojure and software development in general, the ones that stick do so because I can, to put it bluntly, think straight. Well, most of the time - I'm still not perfect by any means of course, I notice mishaps and potential areas for improvement every week. Pretty much all of it boils down to "slow down, think a bit more, challenge your assumptions". A simple "why?", uttered repeatedly, can be annoying but can save a lot of resources. I just now thought that the two of my oldest clients don't even discuss development itself with me all that much. It's mostly client needs, processes, even management - often way outside of my immediate responsibility area.

The luck factor / increasing my luck surface area is something that I'm pushing myself to do. It's too easy to just write code that I want to write, scratch technical itches; talking to people and putting things out in the world is (to me) harder, fuzzier. But once it gets going, quite enjoyable too. And, adding to the critical thinking / thinking straight / thinking in the clients' language and terms: sometimes that even means knowing when to advise them not to work on something and other cases that are not solved through writing or changing code.

Sometimes I structure proposals in terms of outcomes, not specific code, and clients couldn't care less about the implementation details. They just want to be able to do X or prevent Y; the means by which that is accomplished are not essential.

I'm curious, if you want to share, do you use hourly billing, project-based, retainer or something else entirely? I myself work mostly project-based, fixed price and keep projects small and defined by success criteria relevant to the client. Occasionally I'll do hourly based when I see no way around it but that's quite rare.

> sometimes that even means knowing when to advise them not to work on something Absolutely, happens all the time. Or something like "If you really want me to do it, I can do it. But I think you should hire somebody else who's more suited for the job." > do you use hourly billing, project-based, retainer or something else entirely? I charge hourly, but I'm flexible in that regard - it's just a personal preference with not too much behind it. Lets me treat all clients equally, even if I sit with them for just an hour. Doesn't put too much onus on me. But I also have a decent work ethic and I try to be transparent with my clients, so I don't disappear out of nowhere, I don't leave them hanging.

Yeah. Being reliable, honest, clear and just a nice person to work with goes great lengths at retaining clients and being recommended —and enjoying the work relationship! 🙂

> Do clients come to you for Clojure, or is it something you introduce? Both. > If you introduce it, how often do potential clients freak out? I've had to explain what it is, but only once did a client (actually the client's other giant-Borg consultants) have a problem with it.

> hourly billing, project-based, retainer or something else entirely? At the risk of intruding on your convo, daily billing is also a good option. Client doesn't feel nickel-and-dimed and freelancer doesn't have to obsessively time-track.

True, daily beats hourly; time tracking is one of my least favorite activities.

Randomly remembered this thread and realized that I forgot to add something. Hourly billing does not necessitate time tracking. It merely enables optional granularity. You can still decide that today you're working a full day, without any time tracking, and bill your client for 8 hours instead of 1 day.

2.5 hours is incredible

Just started watching that last night, great stuff so far

Just watched it a couple of hours ago, really intriguing

I feel like the heart of the story is in the first 8 minutes when he shows the two ways you can group. The ideal grouping is always a level below how your user will think. Your building a system for them after all, you need to work with the building blocks of it. So for instance, your user will have a thief and guard fight. You develop at a layer below that: with the physics of bodies in motion. Everything past that in the talk, while interesting, seems like a journey to understand why people don't do this sometimes. And unfortunately, no one is going to write down the reasons.

That feels kinda dismissive of the value of learning about the history of programming, and I think a shallow understanding of the history of these ideas is a big contributor to the problems that Muratori identified in the talk. If people had expressed curiosity sooner about roads not taken during the development of OOP, then perhaps it would have been a "15-year mistake" instead of a "35-year mistake," because they may have recognized the alternatives that hadn't yet caught on.

At one point I heard him say something about his complaint about OOP is hierarchical inheritance, but not about type checking. He likes type checking. That would be a departure from Rich and Clojure. Thoughts on this? Am I reading too much into it? I still haven't finished listening to the whole talk. Also, hierarchical inheritance is addressed nicely in Clojure, and I learned a ton from this blog post: https://eli.thegreenplace.net/2016/the-expression-problem-and-its-solutions/

Casey Muratori is mostly a C("++") programmer; he's pretty well-known in the indie game industry, and, quite frankly, I've yet to find any YouTube video he's a part of that isn't really interesting. I can imagine that when you work in C you kind of like types, for as far as they do get you.

something I'll never stop being pedantic about: there are languages "without types", eg. forth and assembly where data has no type tag and the language has no notation for data types. the languages most of us use are either statically typed before running, or checked via tags at runtime

I think the actual debate being referenced here is about the value of static type verification

And C is pretty weakly-typed (hello, void *!) so what a C/C++ dev might like about types is going to be different than, say, a Haskeller...

Casey is very narrow and specific with his gripe - it is with compile time hierarchy which matches the domain model - e.g. type taxonomies. Animal, Dog, Retriever. ECS systems are more dynamic in this regard and while he does not use them he finds them preferable to. Drink (responsibly) every time he says "compile-time hierarchy that matches the domain model"

I think his arguments were slightly too focused on the tools, and not the mentality, and i suspect plenty of ECS systems are just as misguiding in their abstraction boundaries, but maybe i'm missing something.

If you squint, you could mistake a ECS system for a EAV database

be sure to protect access to your ECS system on your ATM machine with a PIN number

(that took me a second to get!)

it's a TLA compliance issue, nobody wants two letter acronyms (and they confusingly share the same TLA with three letter acronyms), so they steal part of the compound noun to upgrade to three letters

I guess that would be a TLA acronym 🤣

Here's the slide where C. Muratori mentioned Rich Hickey. https://www.youtube.com/clip/Ugkx9DifEUEdoA7iw7v8TcUC3w8R0_ep6bR8. "I created a property list, that basically is callbacks, using.. this is called Rich Hickey functor, I'm not kidding. It was a callback, that you could use to do typesafe callbacks back in the early days of C++." My initial reaction was, wait what? back in 1997, young Casey read Rich's paper on callbacks in C++? The power of early internet or some C++ magazines published Rich's paper.

@afoltzm I wasn't trying to be dismissive, I think everything in the talk is important, but like most vital things, i can't summarize it. I think casey himself recognizes this dilemma, which is why their are so many false "ends", it's his way of saying you can't ever really know all the reasons why something happened, and the worst thing you can do, to your point, is to stop being curious. At around 6:08 https://youtu.be/wo84LFzx5nI?feature=shared&t=370 casey quotes someone saying "for some reason OOP has gotten into this mindset of compile time hierarchy's that match the domain model, meaning if you think about modeling the natural world and bringing it into the natural world... why are we doing that?.... make something the user experiences, but make the code something that makes sense for the code" I think Rich address this very same thing in Simple Made Easy around here https://youtu.be/wo84LFzx5nI?feature=shared&t=370 when he talks about how OOP makes complex (intertwining) easy (near at hand) and how users don't care about how the developer felt when writing the code, and so it's the build artifacts that matters. So these questions about circle what I was what i was attempting to address with my comment that the "ideal grouping is a level below what your user will experience" or, as I put in another channel "its about having empathy for you user". And so to answer Casey's question, about why this happens, I think the answer is circular, and it absolutely requires a study of history. His talk does an excellent job of dispelling some of the notions that people use to mask their true intentions, sometimes even from themselves. But it doesn't give anyone a blueprint for what do in their situation sadly. Sometimes, you have to trust your other devs, because they know more about whats a worth while fight to take, sometimes, you can risk pushing for something you really believe in, because you see how it will help you long term. But a lot of those choices, won't make their way into the code.

I think the paradoxical outcome of what casey is explaining is similar to what rich was getting at with simple made easy, that sometimes to make something better for someone else, you have to travel an uncomfortable journey. The wise man knows this through experience, and so tries to teach it to the next generation. But the qustion is, can it be taught? Did they learn through words? or through doing? And if they keep the next generation from the road, aren't they effectively gate keeping what helped them in the first place?

I just know that the hard part isn't making horizontal red lines vertical. laughcry (4:50 ~ 5:30ish in the video)

This talk is making me want to code Simula

Some pages associated with @mavbozo’s note above: http://www.tutok.sk/fastgl/callback.html and https://github.com/janelia-arduino/Functor and https://news.ycombinator.com/item?id=4256366

ooooh thanks for linking Rich's "CALLBACKS IN C++ USING TEMPLATE FUNCTORS"

Sounds like a cool idea

Not aware of anything existing

I like the idea. Might even help some developers to find clojure jobs. And it could also help to grow as a community making it easier finding other Clojure developers nearby

no geography on https://www.clojureconsultants.org/

Is this a rule to not provide location info there or is this information just not part of this listing?

Also I think that this would still be an interesting thing to get to meet other Clojure Devs apart from possible opportunities for Clojure consultants and freelancers

> Is this a rule to not provide location info there or is this information just not part of this listing? The latter, I was never asked about it.

it used to list location

for example https://clojurians.slack.com/archives/C5FBP6A5V/p1692661290543139

Huh!

I think I remember putting in my city, and also it once led to on-site work. The client may have found that info elsewhere but I think not.

Ah, wait - that location is from a GitHub/LinkedIn link preview. Not from the website itself.

Maybe that client found it with cross-check then