- 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.
[1] https://g1.globo.com/tecnologia/noticia/2022/09/06/ministeri...
- 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.
- Is it?
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.
- > Old Reddit
Important distinction.
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.
- That would be very interesting to know! Especially considering the two studios he mentioned aren't exactly close to each other:
- True! And that applies for every case. Even if you have 100% isolated mains with solar or battery, you'll get 50hz from neighbours (especially apartments) and power lines close by.
I remember having this issue when working in a recording studio during college, even when we switched to battery and turn the mains off, we'd still get hum in some guitars.
Funny enough I was recently reading an interview with producer Michael Beinhorn and he mentioned having some "mystery EMF/RFI event" happening in New York around 1997, coming from a specific block, and he had to relocate a recording session to Los Angeles because of how strong it was interfering with the guitar amps and other equipment [1].
[1] https://gearspace.com/board/interviews/1385579-interview-mic...
- I remember consumer devices from the 80s that allowed transmitting audio using mains. They were already outdated by the time I saw them in the 2000s.
Me and some friends tested them and tried transmitting to a neighbours house (connected to the same electrical post) and had no success at all. There was just too much noise, coming from other houses. However with digital technology I'm sure you can get a much better range.
- An on-line UPS like those used in datacenters or music studios is probably enough. They basically have rectifiers and inverters in them.
Some of them have phase-locked loops to sync the output frequency with the mains, but probably won't stray as far from 50Hz (or 60Hz) as the mains themselves seem to do. If they do, unplugging the mains and using the battery is probably enough to get pure 50Hz back!
- A lot of software has moved from using dmgs to mpkgs, and apart from some terribly written apps that need some hackery in PostInstall scripts, most of them don’t really care about it.
The UX for packages also sucks. With DMGs you just mount and then drag to the Applications folder… even the most basic macOS users have done this.
- Exactly, the modern practice is condescending. The prevalent thinking is that "users don't really know what they want", so there is zero research, zero iteration, zero respect and a lot of corralling in the application to force users into a (lucrative) workflow.
But the treatment itself is first class, unlike with sysadmins of yore.
- +1000. But in my experience the trend started not with developers, but with the other people around them: Product Managers, Designers, Engineering Managers, Steve Jobs wannabes. There was an obvious disdain for users, and they were seen as complete dunces that should be shepherded to whatever new functionality happened to pop up their heads. There was also a complete disdain for the medium: designers used to print design choosing too rigid designs that didn't really work that well on a screen, and only adapting when the market started punishing them.
At first programmers were able to resist all that and have a voice, but lately it seems that the only prestige we retained was the salary, so we must play the same tune as the rest of the band. Agile was an attempt at being "self managed" and have a bit more independence, but that was also corrupted and lots of devs hate it with a passion too, so we're mostly back to practicing non-iterative, Steve-Jobsian-gut-feeling-centric development. Programmers have bought into that toxic mentality too.
And even in better situations, such as my current job, the tasks that cause the most issues, take more developer time and annoy the user the most are always the same: non-idiomatic features (for the web or for desktop apps), often concocted by designers totally disconnected with the audience, who at most did two or three "interviews" where the user said "yeah I could see myself using that".
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.