dandi8

There are good reasons to dislike Telegram, but having "just" 30 engineers is not one of them. Software development is not a chair factory, more people does not equal more or better quality work as much as 9 women won't give birth to a baby in a month.

Edit:

Galperin told TechCrunch. “‘Thirty engineers’ means that there is no one to fight legal requests, there is no infrastructure for dealing with abuse and content moderation issues.”

I don't think fighting legal requests and content moderation is an engineer's job. However, the article can't seem to get it straight whether it's 30 engineers, or 30 staff overall. In the latter case, the context changes dramatically and I don't have the knowledge to tell if 30 staff is enough to deal with legal issues. I would imagine that Telegram would need a small army of lawyers and content moderators for that. Again, not engineers, though.

A part of it is horrible practices and a work culture which incentivizes them.

Who can be happy when the code doesn't work half the time, deployments are manual and happen after work hours, and devs are forced to be "on-call"?

Introduce Test-Driven Development, Domain-Driven Design, Continuous Deployment with Feature Flags, Mutation Testing and actual agile practices (as described in the Agile Manifesto, not the pathetic attempt to rebrand waterfall we have in most companies) to the project and see how happiness rises, along with the project's reliability and maintainability.

Oh, and throw in a 4 day work week, because no one can be mentally productive for that long.

IMO the biggest problem in the industry is that most developers have never seen a project actually following best practices and middle management is invested in making sure it never happens.

Does this really make it any less worthy of criticism, though...?

Hopefully this will enrage the users enough to go and actually vote against Trump.

As a dev, I think agile works best when there's an ongoing conversation with the users, and I usually have to fight with management to get to speak to those actual users.

That's not creepy or weird, that's horrifying.

Isn't the format literally just Twitter?

I'm hoping for a 4-day 6-hour work week in my lifetime, but it seems the world isn't ready for that quite yet, even though I'm 100% convinced productivity would not be impacted in any significant way, at least when it comes to software dev.

I think GOG gets better and better as a place to buy games.

I'm a die-hard fan just for the DRM-free offline installers they provide, but the game selection has been consistently getting wider, to the point where many AAA games release on GOG on day one.

The deals are also generally nice.

I don't think source-available licenses have any chance of outcompeting open source, or at least I hope developers won't let them.

Open source thrives on contributions. The moment you restrict what I can do with the software I'm supposed to contribute to is the moment I ask myself: "am I being asked to work for free, solely for the benefit of someone else?".

The incentive to contribute completely disappears (at least to me) when I'm asked to do it for a project which "belongs to someone in particular".

For me, as primarily a backend dev, the argument was that it's a framework, unlike React, so you get an everything-in-one solution which is quite easy to setup and use.

Given that Google still hasn't killed this one yet, it's also a mature platform with plenty of articles online on how to use it.

IIRC the license was also better than React's, at least last time I checked.

Not sure on what the landscape looks like today, but when I was making the choice, the internet didn't seem to consider other solutions to be competitive with either React or Angular.

They refused to pull out of Russia when it invaded Ukraine, though, so they're shitty in other ways.

Over my dead body.

If you have separate developers for writing unit tests, and not every developer writing them as they code, something is already very wrong in your project.

Deployment and infra should also mostly be setup and forget, by which I mean general devops, like setting up CI and infrastructure-as-code. Using modern practices, which lean towards continuous deployment, releasing a feature should just be a matter of toggling a feature flag. Any dev can do this.

Finally, if your developers are 'code monkeys', you're not ready for a project of this scale.

This comment smells of outdated software development practices.

Except "mass" is not useful by itself. It's not a chair factory where more people equals faster delivery, just like 9 women won't deliver a baby in a month. I wish companies understood this.

Are you complaining that older versions of Java don't have the features of newer versions of Java...?

Fair point!

Comments should never be about what is being done. They should only ever be about why it is being done.

If you write your code like suggested in the book, you won't need to rely on possibly outdated comments to tell you what's going on.

Any comment about "what is being done" can be replaced with extracting the code in question to a separate, well-named method.

FYI there's a fully playable unofficial port for Jak 1 and 2, and they're working on the 3rd one: https://opengoal.dev/

In my experience LLMs do absolutely terribly with writing unit tests.

Interesting! Out of curiosity, what is the source? Is there a breakdown per role?

I think that would depend on the skill of the developers and the resources they are given.

A lot of us are only ever taught to be code monkeys and those would probably not naturally gravitate towards true agile practices (which most, I would argue, have never actually seen in a real project).

Another problem is a lack of access to domain experts, which is also crucial.

However, my current project doesn't have any managers, or even business analysts, there's only the developers and the Product Owner. We have access to some domain experts and we work with them to build the right thing.

It's going great and the only problems we are facing are a lack of access to the right domain experts sometimes, as well as some mismanagement in the company around things we can't do ourselves (like the company Sonarqube not working and us not being allowed to host our own due to budget constraints).

In conclusion, I think part of the problem is educating software developers - what true agile is and what the industry best practices are (some mentioned in my previous comment). Then you give them full access to domain experts. Then you let them self-organize. Basically, make sure you have great devs, then follow the 12 Principles of the Agile Manifesto to the letter and you've got a recipe for success.

Otherwise, results may vary a bit, as I think many would tend to continue doing the Fake Agile they were taught and continue producing the poor quality, untested code they were taught to produce.

I'm fairly sure the crouch jump is part of the Half-Life 1 tutorial level.

Is it possible that you just chose the wrong abstractions?

On the one hand, mutation testing is an important concept that more people should know about and use.

On the other, I fail to see how AI is helpful here, as mutation testing is an issue completely solvable by algorithms.

The need to use external LLMs like OpenAI is also a big no from me.

I think I'll stick to Pitest for my Java code.

First part of the article sounds like what I'd expect.

The second part makes me wonder if this research was sponsored by some company which provides "Prompt Engineering" training.

Just because open source AI is not feasible at the moment is no reason to change the definition of open source.

Are the petabytes of training data included in the repo? No? Then how could it ever be called open source?

At best, some of the current AI can be called freeware.

If you're just including the trained AI itself, it's more like including a binary, rather than source.

You can't really modify Llama in a significant way, can you? You can't fork it and continue improving that fork.

Can't easily download offline installers, though.

It's no less possible than for the tooth fairy, or Santa Claus to exist.

Ah yes, let's make it even more of a hell to live in cities by paving over anything green and making people live like livestock in tiny cages. That will surely solve the problem!

Oh, and really it's the immigrants' fault! They're the ones buying up all of the houses with cash to later rent them as AirBnBs!

Why aren't LRG releasing all these classics on GOG?

Regarding mutation testing, you don't write any "tests for your test". Rather, a mutation testing tool automatically modifies ("mutates") your production code to see if the modification will be caught by any of your tests.

That way you can see how well your tests are written and how well-tested parts of your application are in general. Its extremely useful.

I have never, in my decade as a software dev, seen a role dedicated to "making sure unit tests stay functional, meet standards and fixing them". That is the developer's job, and the job of the code review.

The tests must be up to standards and functional before the functionality they're testing gets merged into main. Otherwise, yes, you may actually need hundreds of engineers just to keep your application somewhat functional.

Finally, 30 engineers can be a vast breadth of knowledge.

Isn't the entire point of federation to be able to do what you're describing?

While that sucks, it's only some games, and AFAIK they only rely on Gog Galaxy for the multiplayer features sometimes, and maybe achievements.

I'm also still holding out hope they'll come out with a Linux version of GOG Galaxy. For now, for my single player gaming purposes, running the games using Lutris (or Heroic, which I've heard is even better for this) is good enough for my Linux gaming needs.

I do, and whether I have a good time depends on whether they have written their code well, of which the book's suggestions are only one metric.

Good abstractions are important for the code to be readable. An AbstractEventHandlerManager is probably not a good abstraction.

The original commenter said that their code was "generic with lot of interfaces and polymorphism" - it sounds like they chose abstractions which hindered maintainability and readability.

Ok, but the comment thread is about people preferring Bluesky to Mastodon, hence my confusion.