the frontend team can write a BFF to make all pages render server-side. there is an advocacy group for keeping oauth2 clients out of browsers which gives this idea some _political_ merit. in ways more than one, SPA is not the only solution when a dedicated _frontend team_ is employed.
The separation of teams happened before the BFF pattern came into existence so all frontend engineers became specialists in frameworks like React. Unless you can do it with React, FE's won't touch a BFF or anything else for that matter.
what is often overlooked in corporate culture: if you take a step back, two coworkers refusing to cooperate, regardless of the reason, is a typical "corporate kindergarten" scenario for the manager to take care of.
To avoid rushed or incorrect decisions, conflicts intentionally move through gradual escalation. If someone behaves unprofessionally, for example by submitting a code review they do not understand, the first step is to establish the likely cause.
They may ultimately be at fault, but that does not absolve the surrounding environment. The culture may be toxic, deadlines unrealistic, or communication poor.
The best course of action for someone directly affected by uncooperative coworkers is to avoid assuming ill intent. Get them on a call and let them explain their pull request, however trivial the issue may seem. Even if the gesture is misinterpreted, you still have a far stronger position than righteous indignation.
This, I totally agree with you having a call and letting them explain the changes. One of my coworker used claude to write and push PR's and the message was so cryptic, it's not really understandable. I got him on a call and let him explain the PR. He also actually couldn't really interpret the PR message. I warned him not do this again. Now he writes by hand. I think communication between humans should be written by only humans. AI is not really good at communication.
I once worked in a place where a guy would pick on me in code reviews, he wasn't really higher position, but had been with the company longer than I was.
He was just an asshole asserting his dominance and needed to be taken a notch down by a manager and it turned out he didn't understood (or more likely didn't try to understand) the PR when confronted.
While I circumstantially agree, I hold it to be self-evident that the "optimal amount of grift is nonzero". I leave it to politicians to decide whether increased oversight, decentralization, or "solution X" is the right call to make.
A little grift is expected. The real problem for us is when it's grift all the way down, and all the way up, to the extent even the President is grifting. Leaving it to the politicians in that case just means enabling maximum, economy-scale grift.
I can't help but think that this is a "I have nothing to hide" argument. It's quite sisyphean to keep accounts perfectly segregated, therefore there's always a chance that personal information can be traced back and pieced together; which, in turn, has "boring-old security" implications: i.e., now someone possibly knows your habbits and times when you are at work
On the topic of working hours, flexitime is highly addicting and I cannot imagine anything that's better for a software developer. Clock in, have meetings, write code, commit, clock out. Overtime? Just leave early without asking your boss. It just makes sense. Plus, the negotiated working hours per week / working days / mandatory hours can be set to whatever value that makes sense.
Nobody is paying you to sit, people care about the working product.
I find it quite intriguing to introduce "language-native" matrices and 2d blocks (which I still find difficult to wrap my head around.)
The reason why most people would more intuitively consider a music score as multidimensional has to do with parallelism or concurrency.
In theory, nothing is stopping you from creating a hyperarray language a la BQN++ (or dare I say QRP). Maybe I glossed over an example, but having proper pointwise application to hyperscalars feels like a must-have.
Second idea is to introduce process parallelism, which could actually make this form of syntax into an execution graph of sorts--could be quite promising!
Looking at the software development today, is as if the pioneers failed to pass on the torch onto the next generation of developers.
While I see strict safety/reliability/maintainability concerns as a net positive for the ecosystem, I also find that we are dragged down by deprecated concepts at every step of our way.
There's an ever-growing disconnect. On one side we have what hardware offers ways of achieving top performance, be it specialized instruction sets or a completely different type of a chip, such as TPUs and the like. On the other side live the denizens of the peak of software architecture, to whom all of it sounds like wizard talk. Time and time again, what is lauded as convention over configuration, ironically becomes a maintenance nightmare that it tries to solve as these conventions come with configurations for systems that do not actually exist. All the while, these conventions breed an incompetent generation of people who are not capable of understanding underlying contracts and constraints within systems, myself included. It became clear that, for example, there isn't much sense to learn a sql engine's specifics when your job forces you to use Hibernate that puts a lot of intellectual strain into following OOP, a movement characterized by deliberately departing away from performance, in favor of being more intuitive, at least in theory.
As limited as my years of experience are, i can't help but feel complacent in the status quo, as long as I don't take deliberate actions to continuously deepen my knowledge and working on my social skills to gain whatever agency and proficiency that I can get my hands on
this depends heavily on what is easier to do: social engineering or prompt engineering.
reply