A few years ago I start a dashboard project that was mostly raw SQL.
I then saw the team wanting to convert it to ActiveRecord, which they started. But lots of queries had to use AREL (Rails' "low level SQL AST abstraction"), since they weren't really possible or just too difficult to do in ActiveRecord.
But AREL is so incredibly unreadable that every single AREL query often had its equivalent in plain SQL above it, as documentation, so new people could understand what the hell it was doing.
In the end some junior was unhappy with the inconsistent documentation and petitioned that every query, simple or complex, AREL or ActiveRecord, had to be documented using SQL above the AREL/AR code.
Then they discovered that documenting using Heredocs rather than "language comments" enabled SQL syntax highlighting in their editors.
After that we had both: heredocs with the cute SQL and some unreadable AREL+AR monstrosity right below it.
I still laugh about this situation when I remember it.
You either start with or without an ORM, depending on your assessment of whether the project is gonna need one.
If you start without one, you still have to partition your code well enough so that retrofitting one doesn't cause a huge mess. Basically keep your "raw SQL queries" in a centralised place (file or folder), rather than strewn together in controllers/views/services. And you should do exactly the same if you use an ORM. Isolate the fuck out of it and make it "easily removable" or "easily replaceable".
Also keep the "effects" of your ORM or your non-ORM away from those other parts too: your controllers, views and services should be totally agnostic to whatever you're using in the data layer. When you add subtle coupling you lose the possibility of changing it, but it also makes your project less maintainable.
This is easier said than done: in dynamic languages or with structural typing like Typescript it's very easy: it's all objects, anyway, so ORM or no ORM it's the same. In stricter languages like Java it might lead to lots of intermediate data structures which are verbose and causes problems in itself. Or the middle ground: use primitives (lists and maps) rather than classes and objects, although ORMs like Hibernate will make things difficult for you, since they're not too flexible about how they're used and their types tend to "creep" all over your project.
-
Most unmaintainable projects don't become unmaintainable because people "forgot to prepare". They become unmaintainable because people assumed everything is permanent, so there's no penalty to using everything-everywhere. So there are "traces" of the ORM in the controllers and views, the serialisation library and serialisation code is called in models in services as a "quick hack", the authorisation library is called from everywhere because why not. You quickly lose the ability to easily reason about code.
The same applies other areas. I could make a treatise of how game developers love sticking keyboard-reading code absolutely everywhere in the codebase.
And I answered to that already on my second paragraph.
Taking the nuclear option after merely "seeing [something] as" risky without exhausting the much-cheaper remaining options is not "somewhat understandable, if not plain reasonable". And it's not "ways and quirks": it's incompetence at best or corruption at worst.
This kind of situation might be common, but it is not understandable nor reasonable.
> Your good developers are often the ones who like to tinker with frameworks, patterns and complexity. Note: good developers don't force this down people's throats, but they're always thinking about what they can apply in the future. That's not to say they can't be perfectly fine working on boring code. But they often get bored with it. They can be 5x as productive as your average developer when working on the boring code, but you're just ticking down a clock in a lot of cases.
In my experience that depends.
But the tinkering kind is often satisfied when they are able to tinker on their own code. Even (or especially!) if they're allowed to do it during working hours. But allowing engineers to literally hone their craft on the clock is something that is becoming rarer and rarer, unfortunately.
But I agree that a developer that refuses to admit failure of their experiments and wants to force their experiments on others is a problem, of course.
On the other hand, there's more to this job than coding, and a lot of people interested in "learning" will leave as soon as they find out there's nothing more about the problem-domain to learn.
Nowhere in the grandparent's post says that it was a "walled garden", or even that it was closed source. The fact that only one person was needed doesn't mean there's only one person available. OP even said he worked for a company in a reply. The rationalisation automatically assumes that the grandparent is either incompetent or lying by omission, which is very uncharitable.
Even if all those problems were true, if it was really analysed as risky, the proper thing to do is to bring in one or two more engineers, perform audits, ask for the full source if it's not available. Ask for documentation. Heck, OP said it's not minified: try to reverse engineer it, if need be. Perhaps it's not even necessary!
There's absolutely no need to bring a 9-digit-sum team to replace a working system made by one person, even if this is common practice in our industry. Not before all other rational avenues are pursued if there are problems.
What also pisses me off is that what happened on the other side might have been caused by companies like the ones I worked for. For a long time I worked for consultancies, and it was routine for sales to "translate" our feature lists into procurement rules (sorry don't know the term in english) and give that to companies and government so we would be the only ones able to answer.
And the worst part is that software engineers go on with this tune because they enjoy so much overengineering everything from scratch.
> Apple disagrees. They don't run promotions of that sort, or promotions, in fact. The price is the price, it's core to the brand.
That's not entirely true. I got my M1 in a promotion, with a discount. I also got my Watch "bundled" with the bracelet (the packages were literally bundled together), also with a nice discount. That was at a flagship Apple Store.
Also "the price" is not "core to the brand" in Brazil. It changes very frequently and is not a direct conversion of the American price.
Funnyly enough Apple's Brazilian PR team completely fumbled their response to the Ministry of Justice:
> Existem bilhões de adaptadores de energia USB-A já em uso em todo o mundo que nossos clientes podem usar para carregar e conectar seus dispositivos. [1]
> Translation: There are billions of USB-A power adapters already in use around the world that our customers can use to charge and connect their devices
Those "billions of USB-A adapters" however won't work with the cable provided in newer iPhones, which is lightning and USB-C.
One of the main criticisms I see is that low-Elo people also get show mainly high-Elo people. So there's much less chance for two low-Elo people matching with each other, the algorithm works against it.
Since you have a limited number of "likes" per day, you have to actively "say no" to people that's attractive to you.
Well, if the government wants to help people meeting offline, it's gonna cost a helluva lot more than a website... to the point it doesn't sound like a waste anymore. I don't see society going back to offline dating by itself.
To a complete outsider it feels as if Hinge is just becoming the new Tinder. Anecdotal of course (mostly from women friends), but partly supported by the growth of Hinge lately.
People looking for relationships don't want to be matched with people only looking for hookups, and people looking for hookups don't want to part of a club that accepts them. Apps have the incentive to make money so they don't really do anything.
New Reddit also fell prey to bad development practices and is without exaggeration unusable for me. It often "crashes" and the whole page goes dark-grey on my browser, and this has been happening for at least a year. After reloading I can't see all messages without navigating away, and middle click messes with the scrolling. At this point I will assume they either don't care or are fucking with me.
Well, first, it's not reliable. If the network goes down and it doesn't have some form of recovery, you gotta start from scratch. Second, it's not bookmarkable (except for the odd case), so you can't send specific pages to anyone, you often can't start navigating in it one day and continue on other, or in another device. Third, you lose navigation and exploration features, like navigating to the first page and seeing the oldest stuff, or going into the middle.
But the biggest reason people hate as a matter principle is because it is in 99% of cases done without any UX research and without any care from developers, and that's in the best case. The worst case is to cause doomscrolling, which is nefarious in its own.
It is disrespectful to users. If you don't want people seeing old content just fucking delete it.
And you're absolutely right, despite the downvotes, but here's the coldest of all hot takes: it doesn't matter if it's shit. It just has to be there.
Doomscrolling and modern web products were never about quality, but rather about giving the user the hope of potentially seeing something of quality.
Which means that my cousin magic_hamster who said "this can just be an algorithm" is also right [1]. In most cases there's no need to leverage AI here. 90% of everything is gonna be crap, and people historically often get addicted to low-quality crap anyway.
I find it personally hard to date stuff that came out or that I watched during the pandemic. To me it felt like I consumed 4 or 5 years of content in the span of each year. My sense of time is completely twisted.
I then saw the team wanting to convert it to ActiveRecord, which they started. But lots of queries had to use AREL (Rails' "low level SQL AST abstraction"), since they weren't really possible or just too difficult to do in ActiveRecord.
But AREL is so incredibly unreadable that every single AREL query often had its equivalent in plain SQL above it, as documentation, so new people could understand what the hell it was doing.
In the end some junior was unhappy with the inconsistent documentation and petitioned that every query, simple or complex, AREL or ActiveRecord, had to be documented using SQL above the AREL/AR code.
Then they discovered that documenting using Heredocs rather than "language comments" enabled SQL syntax highlighting in their editors.
After that we had both: heredocs with the cute SQL and some unreadable AREL+AR monstrosity right below it.
I still laugh about this situation when I remember it.