Clojurians Log v2

> multi-million lines of code monolith That seems like way too many LOC for it to be Clojure 😛

Interestingly, never heard of this 6 million lines of code before. I have heard of their close to 2000 microservices though…

Iirc, this particular project was not clojure, it was some kind of etl data model. But we also have way more than 6 million LOC of Clojure

I'd say it still belongs to #ai-skeptics

I've initiated a rewrite once in my career and from my experience it was a terrible idea even though I wanted to avoid huge classes with abstract hierarchies. I think that LLM tools make it very easy for trigger-happy people to fire this kind of idea and get approval because of the false perception that rewrite is an extremely easy idea and feature parity will be kept. But in reality it's not true unless very strict policy of "no more features unless we're finished" is being enforced by technical person.

And then a secondary effect that kills it completely is that if management starts to believe that the rewrite is too easy they won't even hire anybody that would understand the source project in the first place. Making the rewrite impossible.

I have done a few successful rerwites (that have cost manyears for the teams). If it needs to be done then it should be done. But don't do it because you like something more. You need a business reason for it.

I don't think AI will change this landscape much.

Makes the kickoffs of rewrites cheaper, but the end of those projects has never been stuck behind typing speed.

It's a great point. The Bun rewrite blog talked about this. They're hoping that now they can start re-structuring code to be more Rust idiomatic and get rid of some of the unsafe that the AI ported over. So basically the rewrite in Rust isn't truly done yet, because it was currently done as a 1:1 with the Zig code.

I've also seen a few rewrites from one lang to another where the new rewrite claims to be so much better, but often it's that they redesigned certain things at the same time, so the language might not have made that much of a difference compared to the redesign.

I think it fair to say that the Bun rewrite didn't have much to do with technology, but rather that Anthropic owns them and Zig bans AI contributions. The Bun team's technical arguments doesn't really hold water, as laid out in the Jetbrains inteview (https://www.youtube.com/watch?v=iqddnwKF8HQ). One of them being reducing build time, and the switching to the language with the worst build times?? Oh well.

It depends on what's mean by a "representation of reality". Quantitatively, as in "does an average programmer do that" - definitely not. Qualitatively, as in "do things like this happen like that" - sure. So, just gotta find the right place. Trouble is, even those out-of-ass-5% don't really guarantee anything except talking about algorithms and architecture. Knowing all the algorithms and having all the skills in creating architecture does not guarantee common sense and wisdom. So in some way the situation is even worse. But the remaining 95% can still have common sense and wisdom, and apply them in their work, even though they might not care all that much about algorithms and whatnot.

I think I understand your words, but I don't really get it. Do you have an example of how a situation with a skilled person without common sense and wisdom would play out? Regarding the person with common sense and wisdom who is uninterested about code design, surely their wisdom must be vastly limited by their ignorance? Can they realistically make wise design decisions in general if they don't know what a pure function is and don't care to find out?

> Your scientists were so preoccupied with whether they could, they didn't stop to think if they should. ― Dr. Ian Malcolm, Jurrasic Park "A customer has asked us to implement feature X, here's its immaculate architecture, here's how we implement it using proper software engineering." The customer had a problem Y that they thought was going to be solved by X, but it doesn't get solved by X. X was completely unnecessary. And there can be internal customers, like upper management. Or there are existing active users of some other feature X. Feature X is so maintenance-heavy that 50% of SE times goes towards its support. But there's only 1% of customers who use that feature, and even for them it's not necessary. X is just not worth it. > Regarding the person with common sense and wisdom who is uninterested about code design, surely their wisdom must be vastly limited by their ignorance? Limits don't always impose practical constraints. I don't know most of the things about my car, but I know how to drive it, I know its limits and my own limits within the context of the car. In other words, I know enough to be effective enough. > Can they realistically make wise design decisions in general if they don't know what a pure function is and don't care to find out? Maybe, maybe not. It doesn't preclude other kinds of wisdom, as I mentioned above in this message. Of course, some might say that such wisdom is closer to management than SE. But to me it really isn't, it's still a part of SE.

Turns out people at this company barely even think about programming other than The Newest Hyped C# Feature™.

I've worked in several places and known several other places, where programmers are purely 9-to-5. They come in, work at their desk, with a few breaks, and go home after 8 hours. Day-in, day-out. They don't learn anything on their own -- just what the company mandates they learn.

I think most people are genuinely curious.

With one place, a group of us organized a meetup, literally right across the street from the office, immediately after work, and offered free pizza and beer to come learn something new about their tech stack... not one person from that office showed up. They wouldn't even cross the street to learn something outside their job.

I don't consider the folks on YT/social media to be at all typical of "programmers" in the large. Nor are communities like this.

The folks who hang out in tech spaces and learn from their peers are very much in the minority, for most technologies, esp. mainstream ones like Java, JS, Python, C#, etc.

Oh, that reminded me of basically a template of interactions with some of my colleagues of distant past: -- Hey, we chatted about X [something programming-related] recently. In case you might be interested, here's a link to where we hang out to discuss X. -- Is that place, like, for our company and I somehow missed it? -- No, it's not work related at all, just some like-minded people interested in X. -- Bloody hell, do you not get enough work during your work hours? Why would you want to work after work? Thanks but no, I'm not interested. Or another one: -- Hey, have you ever had to work with language X? -- No, I'm a Java programmer, I have only used Java. -- Why, aren't you interested in something beyond it? -- No, as a Java programmer I'm being paid to program in Java. I can do all my tasks in Java, I don't need any other language, those are only distractions from my task list. (You can read C++/Python/JS/whatever instead of Java - I've heard it all.)

I think it depends, not everyone is outspoken about their interest. Some people are more quiet thinkerers and thinkers. They won't all excitedly talk to you about everything they read or are thinking about. Others have imposter syndrome, and don't want to be outspoken, feel like they aren't sure they know enough to have strong opinions and speak them out loud. And then for some it's just a job that pays well so they studied for it.

There are also bubbles within the community. Like .NET and Windows shops tend to be their own bubble. People can get really into it, but it'll be all Microsoft tech and practices and so on.

Being genuinely curious and being genuinely curious in the same topic as other people are two different things. Some folks are interested in programming, some in sports, some in other things. Even within programming, some folks are generally curious, but are uninterested in performance optimization or type theory or compilers or whatever. > Hey, have you ever had to work with language X? I think you have to start with problems people have and work towards solutions rather than the other way around. For most people, learning a new technology or tool that doesn't seem to solve their problem isn't interesting. I don't think that means they're not curious. If you can connect a technology or tool to a relevant problem, I think you can pique their interest.

@smith.adriane I think you're very optimistic about programmers 🙂

After 45+ years doing this, I'd say the vast majority of programmers out there view it as a "job" and aren't curious about anything beyond what they need 9-to-5. And that's based on about 20 years of working in the UK, and now 27 years in the US, as well as some international consulting over those decades, as well as conversations I've heard at conferences -- esp. JavaOne once it got big and corporate. I've sat with tables of Java devs at lunch, who viewed the conference as a "perk" from work, not because they wanted to attend, and who were mostly overwhelmed by the talks about had no idea how it might apply to their job. Those were some depressing conversations.

One of the things I really like about the Clojure community is that almost everyone attracted to Clojure seems to be genuinely curious!

I was in the ColdFusion community for years (I sort of still am because I've made friends there) and the vast majority of CF devs aren't curious either. They aren't interested in learning new techniques. They only go to conferences if their company sends them (Adobe hold a 2-day event in Las Vegas every year and it's well-attended but, again, most attendees view it as a perk that their company sends them to Vegas for a weekend, not because they want to learn new stuff).

Niche programming language communities are always "better" in that regard because they self-select for curious developers who are interested in going beyond the mainstream.

And, yeah, I'm probably at the opposite end of the optimistic/cynical range to Adrian, after all those decades 🙂

I remain unconvinced

> If you can connect a technology or tool to a relevant problem, I think you can pique their interest. Not in my experience, no. At least, I personally wouldn't link that interest to curiosity, to what the OP describes as "being truly interested in software at some significant level above just getting the job done with the lowest amount of effort". Of course a person doing X will become interested in how to do X with spending less time on it, if they are paid for finishing X and not for their time. -- Hey, I noticed you check the test server status manually. We have a script for it in the common project that does everything for you, here's a wiki link to it that describes how you set it up and forget about it. -- I don't really care, it doesn't bother me. [Because of course they're paid for their day, not for how many times they can check the server status.] Bloody nobody in my last company was curious about or interested in IDEs, even though one of their flagship projects is a platform built on top of a specific IDE. -- Why do we keep using this IDE? The fact that we've been using it for years and have our main product using it doesn't really mean we as developers have to be using it. -- Why wouldn't we? -- It's slow, it crashes, it hangs. All the bloody time. -- Yeah, but... There's nothing better anyway. They are all the same. -- Have you tried this other IDE? -- No, I've never used any IDE apart from the one the whole company uses. If it were possible to make things better, people behind this IDE would've made them better already. This is an actual conversation that I had with my collagues. Only after I, despite everyone else, installed that IDE and actually showed the magical "somehow doesn't crash, doesn't hang, isn't slow", some people started switching to it. Before that - no interest, zero curiosity, zilch. Just the dumbest conviction that "things are as they must be, nothing can be better".

I have seen some programmers that are some really stale boring individuals with very little hobbies or interests at or outside of work lol. I think the very studious kind, but I believe it's that they've never had a chance to discover what they like. So they kind of just work during work hours, and work during off-work hours. And generally just stay home, but live across the office, have very little furniture, etc.

What makes them stale and boring in your eyes?

What I said, little hobbies or interests, spend most of their time doing work even evening and weekend.

And I mean, they also don't show passion for programming and the work either. At least not openly or outwardly.

It feels like they're bored honestly, and just work out of boredom and no idea what else to do. Don't tend to socialize much either.

The ones I'm talking about have a great social life outside work -- family, kids, hobbies, sports -- but they view programming as just something that pays the bills, and programming stays at the office, 9-5, never at home.

That's my wife 😝.

She's smarter than me, good at school, good at math, good social skills, chose comp-sci because she was good at math and it looked like a good career path.

She'll only learn something when she needs too for work. It doesn't mean she's not opinionated and doesn't have design chops though. But outside of work she doesn't care to talk about it, because if she could have it her way she'd probably rather do something else.

She won't be interested in trying things out, like new IDEs, new languages or what not. In a way, she's more focused on the tasks she's asked to own and deliver. It has its qualities in that it could be she's doing better work than me for example.

Anyways, I will say, there are companies with better culture that cultivate more of an interest and discussion, or have processes that themselves force design and design discussions and encourage experimentation. Then there are just lucky streaks, where you happen to be on a team where the others are all passionate too. That tends to not last long since people move around so much nowadays. So the most reliable thing is to make it your hobby. Don't expect work to fill you with the passion and love for programming, get it from the Clojure community instead clojure-spin

P.S.: Even when I've worked on "dream teams" where everyone else on the team was super passionate and godly at programming. The company ruined it not long after, stupid product idea, bad reorg, layoffs, botched project planning forcing rushed and crunch, toxic management, buyout, etc.

Wow. These are not the responses I expected. How utterly depressing. I expected to find out that my experience at this particular company had been an exceptionally poor one. At least my former colleagues were all genuinely helpful and cared about the product and their work, even if it was impossible to try to get them interested in a conversation about immutable state.

I think one component of it is that programming jobs generally come with good to excellent compensation and reasonable guarantees of job security, two things that might be, in certain people, a disincentive to curiosity and experimentation. I don't really believe that some qualitative ascription of "intellectual labor" to the practice of software engineering makes its practitioners more likely to be some species of Platonic searchers after truth or "good ideas"

In other words, the status quo among programmers is a commentary on the human condition. :D

Maybe, but I think programming is a discipline that, in addition to being attractive to thoughtful people with an engineering mindset, also exerts an influence on those people who consciously or otherwise are drawn to extremely linear, repetitive, slowly progressing labor that alternately rewards and frustrates compulsive tinkering and gives the satisfaction of "power tripping" without the apparent harmful moral or physical effects. I don't really know of any other job off hand in which that state of affairs is quite so entrenched and perhaps even implicit.

I'd say it depends on what a person does. A day job at a regular company - yeah, sounds about right. A startup or a personal project - could be the exact opposite.

> why spend time/energy that could go elsewhere? Same reason you'd spend time discussing anything else. Because it's fun. If you don't find it fun to improve at your craft, there is a problem. Many medical doctors enjoy discussing medicine in their free time. Admittedly, I don't know whether or not they are a majority. I am sure many tailors enjoy discussing tailoring too. Talk about interfaces vs inheritance during lunch break instead of football and the programmers will leave the table. For some reason, most programmers seem to resent their craft.

Were you a doctor before? I ask because it wasn't clear to me if you're speaking from first hand experience or you're just imagining that many doctors do that?

I know plenty of doctors.

That are no longer in school?

Yes

How do you know they are talking about medicine and not their day to day? For example, many doctors are way behind recent studies and practices, in many hospitals and other facilities you have to often fight to suggest and propose new ideas or new areas. Say for example, very few doctors know to prescribe aspirine to reduce risks of preclemspia in pregnant women, or won't ask for family history and so on. Till not very long ago, doctors didn't incorporate much diet in any of their recommendations, etc. What I mean is, hearing complaints about the job and they said this I think that is different from talking about new research, other cultures medicine, etc. So many programmers if you talk to them about things more direct to their day to day, one on ones, agile, annoying PMs, the business/product angle, etc. Can be more interested than talking about some new algo, data-structure, design pattern, etc.

And I think there can be other reasons as well. Doctor requires so many more years of study. To keep your license you have to perform continued education and exams. You're in a position of power and authority always. Your incentives are not to do more work, because payments are not tied to that. I think a better comparison would be nurses, lab technicians, etc. These seem more similar.

They do talk about their day to day mostly, if not entirely, yes. Not medical science. But I'd still say that's more than programmers do, in my experience. Most of my former colleagues wouldn't want to talk about work at all during lunch break or after work. I think many doctors enjoy their work. I agree with you. I see a lot of parallels between doctors and programmers, actually. I like to say that OOP bros are like doctors, but worse. Doctors are blind to basic science and follow guidelines while simultaneously being convinced that they understand why their decisions are correct. Very similar to how OOP bros are convinced that MicroserviceFactoryBuilderDecorator and nullable reference types are the way to write robust code, in my view. Keep in mind that I am not American, though, and I don't know any American doctors. It might be different there (assuming you are referring to American standard of practice).

Fair, I think what @U0BGC50RM26 says makes sense a bit. Some people fall into their biases and then it becomes a job. I'll say generally I've noticed if you work somewhere more open ended, where the team is empowered to make choices, what runtime, infra, language, there's promotion of making sure things are designed well, to limit tech dept, to scale, to be reliable, etc. It allows people to get more interested and discuss. But if you work somewhere that's expecting tasks to get done each sprint and that's all. The manager has its methods, the architecture and design someone else already put in place, or nobody cares about it. And you get assigned tasks, mostly independently, almost to the point there'd be no reason to know what anyone else is doing. And your manager just wants the task done, not to hear issues, concerns, problems, alternatives, questions, etc. Then it doesn't encourage much, because the engineers have no say in it anyways.

Kinda similar to "nobody ever gets fired for buying IBM".

There's already a lot of interesting discussion here, but I will chip in three points of my own. Firstly, it matches my experience that the median dev isn't passionate about coding. However, the median anything is not generally passionate about that thing. For example, the median driver on the road is not passionate about driving. The median person cooking food at home is not passionate about cooking. They're doing what they need to reach some goal (i.e. dinner). If you want passion, you need to look deeper. I'll also note that a lack of passion does not mean that someone cannot be very skilled. Some of the best devs I've worked with don't do any coding outside of work. Secondly, there are some industries entire built on passion, like game dev. Game dev is a multi billion dollar industry and the games are largely created by passionate people. I went to school specifically for game dev and this was clear even then. The problem with passion-fueled industries is that game studios pay less, have more layoffs, and more regularly enforce crunch time. When people burn out, there are thousands of more young, passionate people to take their place, who are yearning to make games. My point here being that passion is not necessarily a purely good thing, in the industry. Where it's found in abundance, it will be milked. Sometimes a focus on stability, ensuring nobody on call is ever called, and otherwise having boring deployments is all you need or want. Thirdly, this is exactly why people go to conferences like Clojure Conj. The conferences are full of people who have self-selected as being interested in some technology and also interested in spending three days surrounded by others, talking non-stop about that technology, community, companies using it, etc. I think a lot of us get both drained and recharged, when we're at the Conj. Perhaps you can find similar events near you, if you want to collaborate more with passionate devs in person.