galbar

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.

For a casual CS server the ratio could perfectly be 1:50 and that'd be fine. That's how it used to be with, i.e., CS:Source.

Then, there are companies that ran a bunch of them, which lowered the ratio even further.

IMO, it's more effective, cheaper and easier to mod smaller forums (be it web communities or game server communities) than to do for huge ones.

They come from science. Engineering applies laws, concepts and knowledge discovered through science. Engineering and science are not the same, they are different disciplines with different outcome expectations.

Our job as SWEs is to convert the vertical slice of functionality into something that fits well and robustly in the various technical layers that need to be touched.

The process that I outlined above explicitly creates the space for SWEs to consider the wider implications of the required changes in the architecture and make robust.

Part of that is understanding what the roadmap is and what is the product vision in the mid term, so that the tech layer can be built, step by step, towards what fits that vision.

My take on this is that, from a SW development POV, user stories are not the right unit of work. Instead, I treat user stories as "Epics". Stake holders can track that Epic for progress, as the unit of work from their POV.

Internally, the team splits Epics into "Spikes" (figure out what to do) and "Tasks" (executing on the things we need to do).

- Spikes are scoped to up to 3 days and their outcome is usually a doc and either a follow-up Spike or Tasks to execute.

- Tasks must be as small and unambiguous as possible (within reason).

Hasn't balancing quality (in this context due diligence) and speed (AI code gen.) been the name of the game in the industry for ever? Management should have enough experience by now to understand the trade-off.

Python has Protocols. They work like Go interfaces

I have said many times to teammates: the only code that is perfect is the one that hasn't left our minds. The moment it's written down it becomes flawed and imperfect.

This doesn't mean we shouldn't try to make it as good as we can, but rather that we must accept that the outcome will be flawed and that, despite our best intentions, it will show its sharp edges the next time we come to work on it.

I just want to add that I also have a Docker Swarm running, with four small nodes for my personal stuff plus a couple of friends' companies.

No issues whatsoever and it is so easy to manage. It just works!

I'm not bothered by if nor def. public void can be annoying but it's also fast to type and it doesn't bother me. For import I always try my best at having some kind of autoimport. I too use vim and use macros for many things.

To be honest I'm more annoyed by having to repeat three times parameters in class constructors (args, member declaration and assignment), and I have a macro for it.

The thing is, most of the time I know what I want to write before I start writing. At that point, writing the code is usually the fastest way to the result I want.

Using LLMs usually requires more writing and iterations; plus waiting for whatever it generates, reading it, understanding it and deciding if that's what I wanted; and then it suddenly goes crazy half way through a session and I have to start over...

I'd bet that no one actually likes to write code

And you'd be wrong. I, for one, enjoy the process of handcrafting the individual mechanisms of the systems I create.

This is how I feel. I mentioned this to a couple of friends over a beer and their answer was that there are many not "decently competent programmer"s in the industry currently and they benefit immensely from this technology, at the expense of the stability and maintainability of the system they are working on.

For whatever it is worth, I have reached the same conclusion and I have been building systems like you describe for the last few years.

Recently I changed jobs. In the new team they love their ORM with all the foreign keys and direct mapping between business logic data objects and the database schema.

Needless to say, it is a mess. Despite all the automated tooling they have around migrations that "should make it easy" to change things, the reality is that the whole application depends on what the database schemas look like and migrating the existing representation to a new one would break everything.

This has become an elephant in the room that nobody talks about and everyone works around.

The most obvious one:

    with open(self.file_path, 'r') as openFile:
        for line in f:

There is definitely an argument to be made about the lack of script writing quality in the last few years.

I used to go to the cinema almost weekly, but since a few years ago it doesn't seem worth it: The stories being told are shiny but flat.

Now I just watch the "good ol' movies" at home...

I believe they are referring to what The Critical Drinker (a youtuber that does movie and TV shows critics) calls "The Message". He explains it here: https://youtu.be/F2ngB-zjVmM?feature=shared&t=105 (starting at 1:45, he defines it for 1 minute and 20 seconds)

I've had good results using https://github.com/Lightricks/pyformance