«гр.» is for grams

Senior backend engineering definitely doesn’t see 99% windows adoption rate.

Well, they do it Japanese style - by forcing developers to leave due to burnout.

I’m working with a legacy codebase for the last few months, where a simple PR often ends up crossing a 1000 lines count due to testing and commenting, and I can’t stop apologizing for those.

Yet there are people out there bragging about 10x changesets.

Kids the days… are entirely relatable.

I made my statement as a BDD/TDD practitioner.

The code goal of software engineering is not to deliver said code, but to deliver it in a framework that lets others—and consequently me in a week’s time—to contribute easily. This makes both future improvements and bug fixes easier.

Dumping a ~25000 lines changeset with a git history that’s almost designed to confuse is antithetical to both engineering and open source.

The size of that changeset means that it’s inherently unreviewable.

The commit history is something I’ve seen only in the PRs that even the most dysfunctional companies would demand a rewrite for.

Also, 2-3 weeks review? PostgreSQL support could be added in that time without the need for a damn „vibe check”. Hell, it would probably take less time than that.

Soviet development that was driven purely by economic considerations tends to have all the issues of modern development. Well, except car centric planning, but we know why that wasn’t a consideration ever.

Apartment complexes that didn’t focus just on economy, tended to be way better. And that is missing from modern considerations almost always.

Still, there’s a reason pre-Soviet areas to this day remain some of the most sought out ones.

Men: ^

How exactly does discussion of failures of a society help those who struggle right here right now?

When you see a burning building, it’s not a good time to start a discussion on merits of various building materials. Here’s a bucket, start hauling.

Oh the fucking irony!

Did you lose track of the written words after the first question mark perchance?

Not voting is a vote for the winner by default. I highly doubt that every single person that didn’t vote did so due to being unable to.

Every bit of code a maintainer accepts becomes their responsibility to maintain. Considering that half the time „improvements” don’t even have tests to help maintaining them, feel free to maintain your own fork.

„How do you know” is such a powerful question.

I especially like the Electrolux one. It’s simple, memorable, and once you see a butt and bikini, you can’t unsee it.

Thanks, I hate it!

I’ve been hoping for it to become widely available since first reading about it somewhere south of 2010. But I guess it would need to become easily manufacturable in local pharmacies for procedure to become widespread.

Power users rebase with squashes and fixups multiple times a day. Especially if the job’s integration process isn’t enforcing long living branches.

Reflog is useful then, because you literally rewrite history every rebase.

This is one of those times when the attempt to address the wrong part of a statement immediately goes into Ackermann-like recursion.

The only irony present is the pretense of validity of the supposed contradiction.

However you like, REST doesn’t dictate anything there. Just be consistent and use hypermedia.

JSON APIs almost never follow REST because they almost never use JSON as hypertext. Worse, no complete stable hypertext JSON standard exists. There’s JSON-HAL, but it lacks a way to represent resource templates (think HTML’s <form>).

Therefore, with JSON APIs ignoring one of the most basic idea behind REST, why would anyone expect them to follow another idea of REST - consistency?

REST is a deceptively simple concept. Any time you build an HTML website a human can navigate without consulting documentation, you’re doing it better than vast majority of swagger documented corporate APIs.

JSON API almost always means “not REST”. In other words, it works as intended.