Asking this question is like asking when was the last time you had to search through text.
the whole point of agile is to be short term
Not really. The whole point of Agile is to iterate. This means short development cycles which include review and design rounds to adapt to changes that can and will surface throughout the project. The whole point of Agile is to eliminate problems caused by business, project, and technical goals not changing because planning is rigid and can't accommodate any changes because the process does not have room for those.
This is why this whole "things need to be planned" crowd are simply talking out of ignorance. Agile requires global planning, but on top of this supports design reviews along the way to be able to face changing needs. This requires planning in short-medium-long terms.
Don't blame Agile for your inability to plan. No one forces you not to plan ahead.
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.
Honestly, I don't mind the downvotes. What puzzles me is how some people feel strongly enough about a topic to subscribe to a community, but still feel compelled to slap down contributions in a time nothing is being submitted, as if seeing no new posts is better than seeing a post that might not tickle their fancy.
It's the difference between building up and tearing down.
Most software is built under non-ideal circumstances. Especially in the beginning there’s often tight deadlines involved.
Exactly this.
I think a bunch of people commenting in this thread on the virtues of rewriting things from scratch using the flavour of the month are instead showing the world they have zero professional experience working on commercial software projects. They are clearly oblivious to very basic and pervasive constraints that anyone working on software for a living is very well aware.
Things like prioritizing how a button is laid out over fixing a rarely occurring race condition is the norm in professional settings. You are paid to deliver value to your employer, and small things like paying technical debt are very hard sells for project managers running tight schedules.
Yet, here we are, seeing people advocating complete rewrites and adding piles of complexity while throwing out major features, and doing so with a straight face.
Unbelievable.
Upgrading a major C++ compiler version was never free in my experience, but even when working in a codebase with ~2M LOC the upgrade (e.g. 14 -> 17) was something that could be prepared in a set of feature branches by one person over the span of one, maybe two weeks.
That greatly depends on your project, what dependencies it has, and what's involved in the migration. For example, I recall a previous project I worked on that experienced a considerable amount of non-trivial issues when upgrading to C++14 due to unforeseeable curve balls. One of them was caused by a third-party dependency toggling constexpr versions of its member functions only on C++14, which caused a bunch of obscure linker errors as old symbols were no longer available.
Push notifications that aren’t specifically topically opted into get blocked so fast on my phone. I have no patience for wasting my time earning someone else advertising dollars.
I agree. The article also points out this fact. Quoting the article:
Another challenge is that irrelevant or unwelcomed pushes risk having the user disable notifications, uninstall apps, or start ignoring them due to low usefulness. This results in a permanent loss of a channel for sharing timely, useful information, leading to reduced app usage. Unfortunately, as Twitter found, most recommendation engines take a myopic view, over-optimizing on immediate user responses at the cost of long-term satisfaction.
Personally, this problem is so pervasive that I kind of developed a pavlovian reflex to notification dialogs to cancel all without thinking about it.
They’ve not been closed as duplicates or anything, just no answers.
This suggests your questions are a factor. Perhaps the topic is too niche? Perhaps the questions are too specialized?
Recently I gave SO a try with a tricky but low-hanging fruit question, and the problem I faced was the exact opposite of yours: I received too many comments and answers. The problem was that 99% of those replying were clearly clueless newbies and seemed to be piling on to try to farm reputation points. Some of them were even not reading the question at all, using a strawmen of sorts to dump the answer they had, and even presenting code snippets that were broken.
What the fuck am I reading?
Style points for the a-bun-dance of puns.
This could be a good opportunity to introduce the concept of test-driven development (TDD) without the necessity to “write tests first”. But I think it can help illustrate why having tests is better when you are expecting to make changes because of the safety they provide.
I doubt that by now the concept of TDD is unheard of to any professional team. Name-dropping concepts actually contributes to loose credibility of any code quality effort, and works against you.
Also, TDD's credibility is already low as it piles on the requirement of spending unordinate amounts of extra work effort on aspects of a project which don't deliver features, and thus it's value-added is questionable from a project management perspective.
One aspect that does work is framing the need for tests as assurance that specific invariants are verified and preserved, and thus they contribute to prevent regressions and expected failure modes. From my experience it's far easier to sell the need for specific tests if they are framed as "we need assurances that this component does not fail under conceivable usecases" and specially as "we were screwed by this bug and we need to be absolutely sure we don't experience it ever again."
Things should be put into perspective. The cost per user is actually the fixed monthly cost of operating an instance divided by the average number of active users.
In the discussion you linked to, there's a post on how Lemmy.ml costs $80/month + domain name to serve ~2.4k users. If we went through opex/users metric, needlessly expensive setups with low participation would be a justification to ask for more donations.
Regardless, this is a good reminder that anyone can self-host their own Lemmy instance. Some Lemmy self-host posts go as far as to claim a Lemmy instance can be run on a $5/month virtual private server from the likes of scaleway.