lysdexic @ lysdexic @programming.dev

Posts

65

Comments

357

Joined

2 yr. ago

I've been working with Agile for years and I worked with people who burned out, but there was not even a single case where Agile contributed to burning out, directly or indirectly. In fact, Agile contributed to unload pressure off developers and prevent people from overworking and burning out.

The main factors in burning out we're always time ranges from the enforcement of unrealistic schedules and poor managerial/team culture. It's not Agile's fault that your manager wants a feature out in half the time while looming dismissals over your head.

It's not Agile's fault that stack ranking developers results in hostile team environments where team members don't help out people and even go as far as putting roadblocks elsewhere so that they aren't the ones in the critical path. Agile explicitly provides the tools to make each one of these burnout-inducing scenarios as non-issues.

it’s about deploying multiple versions of software to development and production environments.

What do you think a package is used for? I mean, what do you think "delivery" in "continuous delivery" means, and what's it's relationship with the deployment stage?

Again, a cursory search for the topic would stop you from wasting time trying to reinvent the wheel.

https://wiki.debian.org/DebianAlternatives

Deviam packages support pre and post install scripts. You can also bundle a systemd service with your Deb packages. You can install multiple alternatives of the same package and have Debian switch between them seemlessly. All this is already available by default for over a decade.

I feel this sort of endeavour is just a poorly researches attempt at reinventing the wheel. Packaging formats such as Debian's .DEB format consist basically of the directory tree structure to be deployed archived with Zip along with a couple of metadata files. It's not rocket science. In contrast, these tricks sound like overcomplicated hacks.

Logging in local time is fine as long as the offset is marked.

I get your point, but that's just UTC with extra steps. I feel that there's no valid justification for using two entries instead of just one.

It might be just me, but I think key bindings should definitely not be easily configurable or even changed across release. They should.be standard, pervasive, and set in stone.

For those who really want configurable key bindings in Firefox I think there are already a couple of extensions that do this for you.

This is a really important principle of making APIs that people don’t really talk about. There’s a fine balance between hardcoded literals and full-gui options menu.

I think this principle might fly under some people's radar because it has been a solved problem for decades.

Even Makefiles don't require changes to the file to be configured. They take environment variables as input parameters, an approach that directly and indirectly permeated into high-level build systems. One example is the pervasive use of the VERBOSE flag.

After all these years I only had to tweak build config files by hand when I wanted them to do something that they were not designed to do. All build tools I know don't require it. The ones linked with IDEs already provide GUIs designed with this in mind.

Fair enough.

Because you’d have to stash your modifications to be able to switch branch.

OP said nothing about stashing, only committing WIP commits to feature branches. I don't think none of your remarks apply, because if you really need stuff from the WIP commits you can also cherry-pick them or checkout specific files.

git switch and git restore were introduced way back in 2019. I don't think they count as new.

When you have 1000+ Cypress tests, for example, it takes time to run, plain and simple.

It's one thing to claim that tests need time to run.

It's an entirely different thing to claim that the time it takes to run tests is proportional to test coverage.

More often than not, you have massively expensive and naive test fixtures in place that act as performance boat anchors and are massive bottlenecks. Thousands of tests run instantly if each test takes around a few milliseconds to run. For perspective, the round trip of network request that crosses the world is around a couple of hundreds of milliseconds. A thousand of sequential requests takes only a couple of minutes. If each of your tests takes that long to run, your tests are fundamentally broken.

Why do you think test times are proportional to coverage rates?

If anything, I thing Stack Overflow replaced Usenet as the source of informal technical advise.

Never heard of Experts Exchange beyond the jokes.

The report of the bug is not the problem.

People in this thread are arguing otherwise.

The prioritization, (...)

Users filing tickets do not prioritize jack shit. That's not how it works. At best they mention an issue is important to them. Not even in big corporations dealing with internal tickets things work like that. The responsibility of prioritizing work lies on the project owners, exclusively.

and demand that it be fixed quickly (...

Literally what each and every single user affected by a problem asks in their bug reports.

Again, why do you feel this is something that warrants your outrage?

That’s not even the issue. Nobody cares that MS is using ffmpeg.

You surely haven't been paying attention to this thread.

It’s just rude to have as much money as MS does (...)

Seriously? Is this the argument you're going with?

Unbelievable.

special treatment for free

They filed a bug report, with a reproducible bug.

Some guides on how to contribute to FLOSS projects even go as far as listing this as one of the main ways to contribute to projects.

But here you are, describing a run-of-the-mill bug report, filed among hundreds of bug reports, in a ticketing system explicitly opened to the public so that everyone and anyone in the world could file bug reports, as a request for "special treatment for free".

Do you think every single person filing a bug report is asking to be given special treatment for free? Everyone's bug is very important to them too. What makes you think this case is special or even any different?

This is really not about "corps".

You eager-to-be-outraged types are desperately trying to make a storm in a tea cup over a normal bug report filed among hundreds of bug reports.

Again, if you replaced the name of those filing the bug report with "random joe", would you still have faked all this outrage? Would you throw the same tantrum if it was even any other business?

They made a demand, based on a product launch time line.

If you read the same bug report I read, you wouldn't make that claim. They expressed their personal needs, which are their own and theirs alone, and don't extend beyond their personal roadmap.

This is absurdly rude (...)

The issue stated they found a bug that they had to get fixed. They said it was important to them for their own personal reasons. It's laughable to describe what amounts to a run-of-the-mill bug report as "absurdly rude".

Do you actually work on software for a living?

treating open source like slave labor

I'm sorry, what? Do you even pay attention to what you're writing?

I have experience contributing to a semi successful FLOSS project, one that I’m 100% certain you use daily.

I'm not talking about contributing. A drive-by PR does not make you a maintainer, nor gets you to triage bugs. The problems I mention are the bread and butter of maintainers engaged in community support, which you would know if you had any semblance of experience in the subject.

And the truth of the matter is that your choice to use weasel words as seaways to a rant to go off on a tangent demonstrates your complete lack of insight and experience in the subject.

All of the other things you mention can be solved with money. In terms of the things that are easy and hard, this very much the former.

I don't think you know what you're talking about, or have any experience working in a corporate environment and asking for funding or extraordinary payments to external parties to deliver something. I even personally know of cases where low-level grunts opt to pay for licenses out of pocket just to not have to deal with the hassle of jumping through the necesssry hoops. You just don't reach out for the cash bag and throw money at things. Do you think that corporations work like hip-hop videos?

The maintainer is a human that needs to eat every day, and not just whenever their services are needed.

That's perfectly fine.

But the maintainer is indeed explicitly making his work available to the public for free and without any expectation of retribution of any kind, isn't it?

And this isn't exactly something new or recent or novel, right? That's been going on for many years.

What changed? Did anything changed at all, even?