If you decide to start a project but somehow decide to self-host a git repository, ticketing service, CICD pipelines, etc... You no longer work on said project and instead you're the system administrator of half a dozen services.

...or you register an account with the likes of GitHub/gitlab, and stay coding right away.

This. Getting rid of telemetry is ok, but not being able to use extensions adds too much resistance and can even make the app practically unusable.

Typically the higher paying jobs are in very high cost of living areas

This can't be understated. Companies like Google, Microsoft, and Amazon can pay their entry level engineers in the US around $120k/year, but some sources state that the bare minimum salary to be happy in places like Seattle, where these engineers need to be located, is around $117k/year.

It feels like they’re trying to be a sort of “wikipedia” of every programming problem and solution.

It looks to me that they could effectively address that by improving their search combined with question grooming, and not shutting down posters.

I mean, what's a naive poster asking dumb questions other than a new user wanting to contribute? Is this the people they want to insult away?

For me the real problem with Stack Overflow, as someone who was one of the earliest users of the service, is when you ask a question now you don’t actually get a good answer anymore. Often your question just gets deleted by moderators.

This. I recall that I posted some question over a framework and if it supported a feature, and the question was shut down because a moderator complained it lacked a minimum working example. Unreal.

One thing that's conspicuously absent from this announcement is real-world data on performance improvements. It's fine that the theoretical change in stores can be up to 20%, but that does not map linearly to wall time. Do those hypothetical performance improvements justify switching to an entirely new x86-derived ISA? Perhaps switching to ARM gets more bang for the buck, specially if that bang is capped so low. Surely the world can get greater performance improvements by buying AMD and stick with AMD64.

answer the stupid questions.

What do you mean by "stupid questions"?

From the article:

There are a few legitimate downsides to using SQLite. First off, the type system. It's bad. Luckily, as of a month ago, you can use strict typing instead, which somewhat improves the situation.

That's a terribly weak argument. No details, no rationale, not objective evidence, no insightz nothing. "It's bad." That's the full extent of the analysis.

Quite weak.

I think its easier for ops people to just use a proper database.

SQLite is a proper database.

For single-instance deployments, running SQLite means no overhead due to a network roundtrip, and things just work.

"Here at bold consulting we gamble away nines to give you the promise of more nines. Bold consulting: experts in high risk high reward reliability. Are you bold enough for bold consulting?"

I'm concerned about how far is Reddit willing to go with your private information. The current Reddit leadership is showing itself to be really desperate to make a quick buck even at the expense of long time users with complete disrespect and total disregard towards those who gave them for free everything they now try to monetize.

Secret Santa is pretty good. My favourite.

I think this post is too simplistic. Everyone handles good code, but as it works and doesn't cause problems nor raises eyebrows then we just glance over it and take it for granted. Developers spend a disproportional time glancing at bad code because that's where they work on, either fixing bugs or updating it to add features.

Microservices have zero to do with this. Their main features is imposing hard boundaries on independent components that are loosely coupled, and in the process end up with code that is safer and easier to change and even rewrite, simpler to deploy, and more testable. Good code is code that is easier to change, and microservices are that by design. No wonder microservices end up being better code.

I'm already happy when I read up on Elon Musk's diktat to refuse to pay services and even rent. Clearly the Hallmark of a successful and trustable corporation.

On the topic of GUI programming, I feel it's of critical importance to understand a couple of basic concepts that have a fundamental impact on software architecture:

• Application life cycle, and
• Application states.

Both boil down to one fundamental mental model that is of critical importance for developing a GUI applications: a GUI app is a big state machine, which covers not only changes in the application life cycle (i.e. startup, shutdown by the user, shutdown by the OS, minimize a window, maximize it, move it to the system tray, online/offline,etc) but also in the application state (i.e., login, launch long running task, user opens dialog box, user changes settings, etc)

Samsung 55" Odyssey in cockpit mode.

Oh god, that is awful.

I want one.

Most questions can be answered by RTFM. That does not automatically mean the questions should not be asked.

Proponents of RTFM seem to believe all manuals are written well, when that's the exception and not the norm.

If all you have to say is RTFM, everyone would be better off if you sat out the question and let others chime in. The overall posture reeks of ladder pulling.

Something tells me that if a team struggles to put together working tests, extending their test sets to support mutation tests will also offer dubious returns on investment.

Some specifics would indeed be nice, particularly when they start off by claiming "You should know when your data was last modified at the very least." I'm not sure how feasible it is to tack a timestamp to each and every data type that's exposed directly or indirectly through a HTTP endpoint, not to mention the overhead and complexity required to check all timestamps directly and indirectly associated with a request. This is feasible with some resources, but definitely not all, or even the majority of them. Maybe it's ok if all your service does is serve as a thin layer over a database, but I dare say the majority aren't like that.

And to think that the only thing Elon Musk needs to do to stop this trainwreck is to a) hand over control to any CEO at all not named Elon, b) get Elon Musk to take a break from social media.

What admin tooling do you need? You haven't defined any problem requiring a solution.

So if you go by those studies then the new grad in Seattle making $120k is minimally happy while the seasoned engineer in Germany making $90k is not.

Not really, that would be a silly comparison. Income influences happiness because it determines how/where you live, what you can afford in terms of basic needs, what's your disposable income, etc. Some countries, due to the way their society is organized, offload more living expenses to their citizens and ultimately lead low earners to simply not afford some basic services. One example is of course access to healthcare. In Germany you have access to public health care and employers are required to pay social security contributions consisting of a percentage of what they pay you, and in turn you have far more affordable and accessible healthcare. Consequently, the $90k you'd get paid in Germany will ensure you have a better quality of life right from the start by the simple fact that a single trip to the doctor won't bankrupt you.

I found this article to be strangely interesting. Coming from object oriented programming, I tend to think about objects as independent, self-contained instances, even if they are ultimately stored in a container. However, once we take padding into account, the overhead of storing objects in an array can potentially become something worth to keep in mind.

The performance gains are impressive in relative terms, but I don't think I would ever switch the default linker if the potential gains are like shaving off 5 seconds when linking a 3GB bundle of binaries.

Here's a friendly reminder that there's a TypeScript community in programming.dev.

https://programming.dev/c/typescript

Threads will only talk to Mastodon et al. for as long as the protocol remains compatible and servers allow it to federate. My guess is that one or the other of those things won’t be true for long.

It sounds like they got Threads to talk to Mastodon to use it to seed content. Once they jumpstart Threads I wouldn't be surprised if they moved from embracing either straight to extinguish or to quietly cutting it off.

A lot of entry level jobs just won’t exist anymore, because the AI will do the typing work while a small number of people manage the AI.

I don't think that's so clear-cut. The impact of AI on software development seems to be equivalent to using a refactoring tool on steroids. Even if it eliminates the carpal tunnel syndrome aspect of coding, you still need people who can write code to not only validate the output but also fix it when things go wrong, which often do.

Microservices architecture by itself doesn’t guarantee making anything better.

No one said that microservices architecture was a silver bullet. What microservices offers is loosely coupled services with very limited responsibilities and can be replaced easily and without any impact on a running service. Being loosely coupled and having narrower and limited responsibilities naturally lead to simpler projects that are both more accommodating of changes and easier to replace.

Making services smaller doesn’t automatically make easy-to-understand code.

Actually it does. Unless you somehow believe that the same people writing both a monolith and microservices would opt to write spaghetti code on microservices while their monolith is kept somehow clean, the narrower responsibilities alone result in simpler and more straight forward code implemented with a far smaller codebase. I'm not sure what leads you to assume that more responsibilities, features, and code paths can possibly make code easier to understand.

how implementations gradually diverged from the specification given corporate forces (...)

I haven't watched the video because it's a awkwardly bloated format to consume for something as straight-forward as presenting an idea.

However, I don't think the way this was phrased is honest and objective. It makes it sound as if evil corporations conspired to spread evil over something that was good and pure.

Email has been continuously exploited by bad actors, non-corporate bad actors, pressuring it to become practically unusable. I'm talking about things like falsifying email origins, unloading massive volumes of unsolicited emails, fraudulent targeted attacks preying on vulnerable users, etc. Legal recourse is also not possible as bad actors hide behind permissive jurisdictions that serve as safe havens for criminal and abusive actions.

If anything, the "corporate forces" were instrumental in eliminating all of these problems, and turned email from an unusable and fundamentally broken technology into a highly reliable and trustable global infrastructure.

It’s always fun to hear management pushing code coverage. It’s a fairly useless metric.

Code coverage can be a useless metric only if your team's pull request review process is broken and systematically approves broken code that fails to meet it's most basic requirements.

In the meantime, if code coverage requirements convince any team member to go out of their way to check for an invarant, that means introducing code coverage requirements is already a win.

It's not me I'm worried about. It's that Reddit has content generated from millions of users who posted it with the expectations it would never be used against them.

Also, given Reddit sells ads I'm sure it also tracks click paths and which content any particular user consumed, and from there deduce personal profiles.

!typescript

!typescript@programming.dev

(Testing testing, 1 2 3...)

You are on a team and that team has at least one member that isn't pulling their weight. The reasons why generally range from a lack of work ethic to a lack of talent.

I think they are pushing the incompetence angle too hard in a way that the author seems to be trying to elevate himself at the expense of others.

If your team hired and retained a guy, that means that team member passed the hiring bar you passed and justified his place in the organization. It's highly unlikely he started to underperform because he unlearned stuff or suddenly became incompetent. Odds are you're dealing with a team member that is experiencing mental health issues such as burning out.

If that's the case, the mere thought that a team member decided to devote his time writing up articles on how to stab team members in the back when they're at a low point of their life reeks of a toxic work environment.

We only get this if we do microservices correctly.

I'm not sure what point you tried to argue then. I mean, is it a valid starting point to presume the hypothetical monolith is the cleanest software project possible but the same people, when peeling stuff off to another service, suddenly unlearn how to write and manage code?

It sounds like you're trying to use very weak strawmen to criticize offloading tasks to separate services.

No, I don’t believe that. However, I also don’t believe people who write spaghetti code will start writing better code just because now they are writing smaller components.

For you to argue that, you first need to start from a point where your hypothetical monolith is a tangled mess of spaghetti code similar to the case you tried to pin on microservices. I'm not sure what would be the point of that.

Nevertheless, if you're arguing over spaghetti code, I'm sure you agree that smaller projects with smaller code bases are easier to untangle than large projects with large code bases. Once you acknowledge that fact, how exactly do you think that limiting the scope of a project wouldn't improve it's maintainability? Are we expected to believe that spaghetti code in large complex projects is as easy to maintain as spaghetti code that is a fraction of a size?

As a final note: I’m not saying microservices are bad, or monolith is better than microservices. I’m just trying to introduce some nuance.

Sorry, I don't think that's remotely relevant to the discussion. This is about monoliths, and peeling other services out of them. In your example, it would be like dialing up from zero to one or two. Even the source in your quote argues against that, and their point is also not about it. Going too far in microservices does not mean "now the monolith calls a lambda".

The real question is does belittling people in Stack overflow helps you compensate for something? Because that's supposedly a venue where people help each other, but you're just there to dump your frustrations on newbies.

There is not much dignity in belittling others in a desperate attempt to compensate for something.

If you don't want to help others then that's ok. Move on. Just don't try to pretend you want to help.

Good point. However, approaching this problem from “YAGNI” point of view is a bit misleading, I think. If you are not going to need the timestamp, you shouldn’t add it to your code base.

I don't agree it was a good point. It sounds like the blog author missed a requirement a few times, and after getting repeatedly burned in the requirements gathering stage he now overcompensates previous failing with I'll advised usages of timestamps instead of booleans.

YAGNI is always true. Always. The author's point, even when timestamps end up being required, are moot.

Also, if state changes are required them you don't tack on a timestamp to a row. You instead track events, including switching stuff on and off.

I feel this blog post is bad advise fueled by trauma.

That doesn't clarify anything at all, and in fact reflects a desire do denigrate people for asking honest questions.

How about this. SO is a conglomerate of volunteering peers, who do not work for you (...)

And that's fine. Ignore the question and move on with your life.

As you've said, you are only a volunteer. You don't own the service nor do you get to dictate what other people's doubts are worthy or not. If you want to help others them share whatever you can share. Otherwise go find a better use of your time without getting in the way of every other volunteer.

It is not a tutorial site, a help desk, or a source of free labor. It’s denigrating to treat it that way.

Stack Overflow states quite clearly in its home page that it is "A community-based space to find and contribute answers to technical challenges".

Call it "help desk" or whatever. Stack Overflow is by design a place to ask questions to technical challenges.

You do not get to dictate what other people find challenging. You do not get to abuse services to abuse people by denigrating them.