galbar

Not an economist but I've heard the argument that the 5 day 40 hour work week was only possible by the increased productivity that came from the industrial revolution.

My understanding of the argument is that it doesn't deny that unions and strikes weren't instrumental but that it was only economically sustainable because of the increased productivity.

As someone that gets very annoyed when having to do LeetCode in interviews...

Knowing algorithms, data structures and their memory and time complexities is very relevant for SWE. I've had teammates that didn't understand them and everything was fine until when it wasn't (scaling and performance issues).

Or, as I put it to a teammate: "Would you rather review the PR of someone that understands the difference between a set and a list or the PR of someone who doesn't?". This was after we interviewed a candidate with ~15 YoE, on paper, that didn't know the difference.

The activity that needed and still needs to be protected is problem solving:

- Understanding the problem at hand

- Putting all the pieces together so that they solve the right problem the right way

- Making sure that the solution facilitate future extension and doesn't lead to a ball of mud two months from now... Unless stakeholders want it to be quick and dirty, then making sure they understand the costs/risks

- Planning execution a way that is incremental and testable so that we can build confidence that the system is doing what we expect of it

- if you are in a team, figuring out common dependencies so that those can be done first and unblock parallelism on execution.

Once all that is done and documented, writing the code was easy and fast.

What would sometimes happen is that some unexpected detail or dependency would be discovered as part of the writing of the code and then you are back at the beginning, figuring out how to make everything fit together.

I find that the main confusion comes from people not realizing that those are two different activities and instead calling it all "writing code".

I was just thinking about forge federation this morning. It'd be nice to base the federation on email, which has been working fine for decades (boring tech and all that), and build UIs on top of it to facilitate collaboration.

These projects quickly reach a point where evolving it further is too costly and risky. To the point that the org owning it will choose to stop development to do a re-implementation which, despite being a very costly and risky endeavor, ends up being a the better choice.

This is a very costly way of developing software.

It is my understanding that a lot of EU governments are setting up their own matrix servers.

FWIW, I have managed 10 simultaneous live transcoded streams on a ARC B580 and it could have managed a few more. With couple of them you cold be fine.

The other aspect is you could share the media storage over NFS and have multiple jellyfin instances running for different houeshold groups.

With 2 or 3 nodes like that I think you could make it work.

It's not a good look to break userspace applications without a deprecation period where both old and new solutions exist, allowing for a transition period.

Software is applied mathematics, though

But not across the Pyrenees :_)

>The fix isn't "apply traditional methods"

I would argue they are. Those traditional methods aim at keeping complexity low so that reading code is easier and requires less effort, which accelerates code review.

This article describes the body of knowledge I was taught when I joined the industry and parallels with my experience with and thoughts about AI.

I have come to the realization that most people in the industry don't know this body of knowledge, or even that it exists.

I'm now seeing the same people trying to solve their ineffectiveness with AI.

I don't know what to think about this situation. My intuition hints at it not being good.

This is something I've been wondering about...

If boilerplate was such a big issue, we should have worked on improving code generation. In fact, many tools and frameworks exist that did this already:

- rails has fantastic code generation for CRUD use cases

- intelliJ IDEs have been able to do many types of refactors and class generation that included some of the boilerplate

I haven't reached a conclusion on this train of thought yet, though.

The git plugin in oh-my-zsh has an alias for this: gbda

It also has one for squash-merged branches: gbds

Very useful I've been using them for years

I am a daily user, family and friends chatting on Matrix.

My take is that there are two layers of friction:

a) people that care about chat encryption and would be willing to change, already did, to Telegram and/or Signal. "I'm not going to install yet another chat app" is a real answer by a friend of mine

b) no one wants to either host their own server, nor pay someone to host it for them. If it wasn't for me and a one of my friends, none of the people I chat with daily would be on Matrix.

And yes, there is the matrix.org server. Out of the ~13 people I chat frequently with, 1 is on matrix.org. "What's the point of changing apps if I'm still going to be using the centralized server" is another answer I've gotten.

I don't know what the solution to this dynamic is other than us, the power users, setting it up and paying for the group of people around us.