CoPilot broke github actions in such a way that if too many requests to start a workflow came in at the same time it would reduce the capacity of the build server's queue until you did a full manual reboot of the build server and completely reset the queue.
Some people are saying they aren't doing testing, I know this to be incorrect in one very important way. When it comes to people, the ways in which a co-worker is going to be wrong are predictable. When it comes to AI written code, there is zero predictability as to what could be wrong.
Trying to test AI written code is like writing code with no try catch blocks, and expecting the application to not crash within 15 minutes of giving to the end user. They will try everything you didn't think to explicitly handle, and when it comes to AI there is no try catch block for subtly incorrect or incomplete logic.
A big part of the problem is that means testing is largely a waste of time. If you boost people based on income you end up wasting a huge amount of time trying to figure out where the income line should be. Even if you can find a good point to put that line, the "rich kids who just didn't test well enough" will sue because they think college admissions should be a meritocracy, and bossing anyone for any reasons is somehow descrimination. They recently won a significant court case with that exact logic.
My next statement will be controversial, and is largely anecdotal, but there is very little to no research that contradicts my opinion, so I'm going to say it anyway. Smart, capable people who simply "don't test well" are almost non-existent. Even if they did, you can't accurately identify who doesn't test well except by giving them a job and letting them prove they were capable when they aren't under testing pressure. I have met hundreds of people who claimed they simply didn't test well, and only one of them later proved it by being genuinely capable and competent.
The thing that pisses me off the most about this whole debate, is that it only really matters if you think it matters whether you went to one of the top 10 universities available to you. Frankly, most employers will throw out your application if it says Harvard School of Business. The number of management jobs that want Harvard graduates is less than half the graduating class, and Business majors have it easier than most of the engineering degrees in that respect. If you're an electrical engineer, there are fewer than 100 jobs Nation wide, and they are already occupied. If you want to be a civil engineer, straight up forget about it. The medical and legal schools are the only exception, and those are graduate schools only.
There is far too much focus on whether the top 10 university admissions are fair and equitable, and far too little focus on whether we have affordable universities that meet decent educational standards for everyone who could reasonably earn a useful degree.
We definitely shouldn't be trying to get rid of standardized tests. There are arguments that can be made about their content, especially historically, but they have merit in showing whether a student is ready for certain classes. At a normal university, they use SAT and ACT scores to decide if you can skip algebra and go straight to calculus, or if you need to take even more basic classes before algebra, and they do this for science and English courses as well. Having such a laser focus on how the top 10 or top 50 schools that actually turn away applicants because they're at capacity is a massive failure to see the actual big picture when it comes to education.
I'm not a huge fan of writing a ton of documentation about the code. I am a huge fan of requiring developers to write in-line comments explaining what they're doing so the next person can build that internal model more easily. There should be some documentation about the system, but this is much more helpful if it only explains how to get the project running locally, including configuration settings and how to interact with it (if data has to be uploaded for a process, what should the data look like and how do you upload it). From there, a mid level developer should be able to locate the code entry points and follow the online comments to find what they need.
Just because it seemed obvious what you were doing and how things worked while you were writing the code doesn't mean it is, or that it will stay that way. Especially if that code ends up getting abstracted out. In line comments demystify code for the next guy way better than any amount of well written documentation.
As for what they're making you do with the RFC documents for changes, try writing your stuff as an ordered multi-tier list. The first tier should be the "manager" description of the change. The next level should be the more technical description of changes. The third tier is the location in the code where that change needs to be made (like a file path sort of thing, but you could use name spaces and even method names if you want). The forth and final tier if you need it would be cross references to other related items in the list and implementation notes/challenges specific to the file path. I've used this approach in the past myself. It's much faster, and it allows you to write a spec doc that isn't a huge waste of your time because it allows you to half write your code at the same time. It also provides a sort of semantic map from how the manager thinks about things to how you think about them, making it much easier for a manager to discuss it with you without having to write nearly as much.
Another benefit to this is you can often use stuff from the second and forth tiers to add in line code comments.
First off, no, not everyone should be on these drugs, there are side effects as well as known drug interactions that can be dangerous and not everyone needs them.
Second, please, please, please stop listing your BMI as if it were a definitive measure of health. To begin with it doesn't correlate well with actual percentage body fat because it doesn't differentiate between fat and muscle. Second, the study which created the BMI was based on a population sample from a single town and all participants were within 4 inches of each other in height, and nearly all were effectively average height with similar lean body masses. If your lean body mass does not conform to the expected range from that study, BMI cannot accurately determine if you are obese, skinny, a body builder or just tall/short.
Finally, rapid weightloss is dangerous, and if you're eating fewer than 1k calories in a day while experiencing extreme fatigue and brain fog, you are more likely to be losing significant muscle mass than fat. This is may be extremely because your heart could be weakened, which could kill you. It's great that your cholesterol and overall weight is down, it's terrifying that you're eating so few calories while being unable to maintain enough physical activity to keep your body from canabilizing vital muscle tissues.
You're not an Indie Entrepreneur, that is complete nonsense. Indie just means independent, and given that all entrepreneurs are by definition independent, you're kind of giving me insight into why you failed. Indie only applies to 2 industries, game development and music, both of these industries are mainly dominated by major studios which people work for even if they are well known publicly.
Don't get me wrong, starting a business is extremely hard work, and I'm sure you did everything you could, but when every 5th word you say or write is essentially a buzz word, people don't respond to that. Also, if all of your advertising was digital, then you need a minimum startup capital that can pay influences to make people aware of you and your product. It sucks, but unless you have a sizable following or are yourself a really good salesman, you're more likely to fail.
This is something I've studied extensively, and it's painful every time I have to tell a friend they would suck at running their own business.
People are idiots, but the cops and everyone else in the justice system had a legal requirement to actually know the law, and letting their kid walk half a mile straight up isn't child endangerment. These people had thier lives turned completely upside down, over the dumbest shit I've heard all year.
It was extremely shitty what the neighbor did, but the neighbor had no authority or control beyond making an unfounded complaint. The cops and everyone involved after that point she be ashamed at just how much they screwed over the lives of everyone in that family. Most people don't know this, but just being arrested, even if no charges were filed will show up on your credit score and background check forever. Those parents aren't stuck with a couple of shitty weeks they can move past, they'll be explaining that arrest to every potential employer and loan officer for the rest of thier lives. That assumes they even get asked to explain it, rather than a generic rejection letter they can only assume is due to one unbelievably unqualified cop making an insane decision.
I primarily agree with you, but his primary point is mainly regarding the tendency for projects at large organizations to have a substantial number of unfished attempts to rework existing applications, which often results in serious headaches for whoever owns the code.
What I mean is that even if you've followed a specific set of programming principals, code practices and design patterns consistently across the life time of the application, there will still have been initiatives to change how things are done. Maybe they want to use a "better" authentication library, or add a material framework that has capabilities they need. The exact initiative, and how valid the request or decision is doesn't matter. These initiatives may occur one at a time, or be competing with each other for priority while being incompatible without anyone noticing. But some of them will fail to be completed, and someone has to back out the changes that shouldn't go to prod. Inevitably something will get left behind. Over 5-10 years this can have a shockingly large impact on the code base in ways engineers frequently notice but don't understand how the code got to the state its in.
This frequently means dead code, unused dependencies, comments that don't make any sense, properties on objects that are never displayed or referenced by business logic, and multiple classes/services which accept the same inputs and produce the same outputs but do the job just differently enough you can't be sure it's the same. That, and over abstractions (any piece of code which branches based on the context of "who's asking").
And frankly few things any me more than someone who felt the need to implement their own logging implementation, especially in C# (yes I know we're talking about React, but people do the same stupid crap in that case as well). Reinventing the wheel has to be done on occasion, but you need to ask yourself if it has to be you that makes it happen,and whether it already has been.
Graphql does not address the problem he's describing. When he says "transformation" his meaning is similar to transformation in an ETL process. What he means is the application loads data, the user takes an action, and the front end code handles updating the objects locally, then sends messages to the backend telling it what the new data state should be.
This is very dangerous behavior for any application. You don't want the front end to determine how much the shopping cart costs or to just tell the backend they've paid, therefore add the items to the orders list. Even if there isn't blatantly obvious security concerns, you should still never let your front end blindly determine data state changes. All such business logic belongs in the backend as much as possible.
What he's talking about is when business logic is split between the front and backend, which makes everything much harder to test on top of increasing the likelihood of duplicate code or even code which does the same thing but looks different enough to not be caught as duplication (which means changing business logic requires finding all the places it was implemented and changing them all, and if you miss any its unlikely anyone else will realize it until it hits prod).
The UI should always just be a shell that sends requests to a backend which determines which updates to make. There are exceptions like when a user makes form based changes to an object, but the only business logic in that case is "let the user decide what the value should be and persist that choice as is". If any additional changes may need to occur as a result of their change, your backend should make them. Even if you just need to determine if a change shouldn't be allowed because of related data, send a request to your backend requesting the answer and any relevant data necessary for display purposes, not the data necessary to make that determination.
There are exceptions to what I've said, but even in those cases, the backend should still verify whether the front end's result is correct. While the front end was working, a change could have gone through in the backend which invalidates that change. This is why things like concurrency/version tokens can be very important.
In any case, Graphql may have capabilities that look like they help keep business logic in the backend, but it doesn't stop programmers from putting business logic in the front end anyway. No matter how you try to look at it, spreading business logic out across your applications various layers always has unintended consequences for maintainability and even scalability.
The other day 8 looked at the IMDB score for the Rings of Power. The score was something like a 3 out of 10, but what caught my eye is the number of user reviews was nearly 200,000. That is way higher than it should be at this point. The problem is that people who haven't even seen it are creating Imdb accounts just so they can give it a negative review. This happened with the all female Gohst Busters movie as well. After the trolls got board they stopped filtering the reviews and it wound up around something like a 7, which is pretty accurate. That Ghost Busters movie wasn't amazing or bad, it was just average, and trolls who had a problem with the premise refused to watch it, which is fine, but then also gave it a 1 star user review just because they hated the idea which isn't.
The reason you found so many domains is that they intentionally take down thier spam sites and reload them under a new domain every few hours. They do this so they can't be taken down by people reporting them as spam. They literally setup the next domain while the current one starts being used so they can do a live swap to the next one without interruptions to thier spam operations. This is typically done in an effort to spread Trojan malware to anybody running computers with out of date operating systems and browsers. Windows getting people off of Internet Explorer has been a huge hit for them as it reduces the number of possible vulnerabilities someone might have when they get sent to one of these Trojan spam sites.
I'm kind of curious why he's so concerned about this? They've never managed better than ninth most relevant and in most cases they didn't even make the first page of result. Any advertising person will tell you, if you aren't in the top 3 results (basically the top result now that paid ads automatically get the top 2 spots on nearly all searches) your odds of being seen and clicked on drop to almost nothing.
Are they potentially doin harm? Sure. Have the successfully managed to trick anybody with this? I'd be extremely surprised if they're getting more than a dozen people clicking through from being the ninth result in a day,and when people see they've been redirected to an advertisement the majority of people immediately click away.
This isn't like clicking on a fake prorn site that redirects to cam girls with viruses hidden in all the downloads. It's random unrelated searches redirecting you to blatant ads for cryto currency. The kind of people who are young enough to know what crypto currency is and how to buy it, also know how to spot a redirect to a fake website.
Having conducted a reasonable amount of academic and scientific research, this metric is more likely to be mischaracterizing research than revealing any issues. This doesn't even establish a causal-link between self-citation and poor research quality, it just assumes it.
Most researchers continue to do new research on the same concept after a publication, and they will of course site their earlier work when continuing. Additionally, post-graduate researchers often have their names placed on the research of grad students they are in charge of, even though they often have minimal involvement in the research or conclusions drawn.
You might be able tell something from the ratio of other authors from all citations to the number of self-citations, but only if you could eliminate self citations that were not either inclusion by proxy or cases where they are merely continuing research on the same topic with new methodologies.
There are already methods for identifying bad research, none of which can be achieved through the use of non-human-assisted data analysis of the authors list of research. The only way to be sure is critical review and 3rd party verification of results with repeated experiments.
I'm not sure if I fully agree with your point about developers or managers not wanting to suggest they aren't needed. You're argument relies on the idea that most business needs could be sufficiently met by static html doesn't really fit how businesses works. If a business in an industry has additional functionality on their page that gives them an edge beyond just text on a page, then it is needed. Additionally, when extra functionality is needed the whole industry is going to compete on that. Most businesses don't have enough extra funds to support unnecessary or non-competitive functionality development, so while there might be something better they could be doing with their money, it's almost never the case that what's being developed is so over complicated or over architected that it would be a better financial move to build a static page or site than what they're doing because losing that competitive edge often results in the company, division or product line failing to get enough sales to continue.
You do make something of a good point about nothing preventing web development becoming over complicated, except you seem to have forgotten how much that costs. Unless there is a perceived marketable difference, people will rarely push for it to be developed at all, and given the size of the average development team's backlog that pressure to develop also has to outweigh everything in the backlog as well.
The honest truth is that web development has become so complicated because that's the equilibrium point of the supply of labor to the demand for advanced features. Developing the same features from scratch using static web development methods takes exponentially longer as a function of feature complexity, and the ability to use frameworks and other more complicated tools reduces that down to being merely linear.
Web development isn't complicated because nothing is stopping it from being complicated, it's complicated because consumers want features that they assume should be simple, but are in fact very complicated.
Some people are saying they aren't doing testing, I know this to be incorrect in one very important way. When it comes to people, the ways in which a co-worker is going to be wrong are predictable. When it comes to AI written code, there is zero predictability as to what could be wrong.
Trying to test AI written code is like writing code with no try catch blocks, and expecting the application to not crash within 15 minutes of giving to the end user. They will try everything you didn't think to explicitly handle, and when it comes to AI there is no try catch block for subtly incorrect or incomplete logic.