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.
Nope. They all have "discretion", and every single one could have prevented this idiocy from happening.
Plus other details: The police can refuse to take the complaint. The police can refuse to arrest someone.
The prosecutor has "prosecutorial discretion".
CPS can outright refuse, both the CPS case worker and the people actually implementing the decision.
The people implementing community service can refuse.
No this is 100% on each and every one of the government workers involved.
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.
> 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.
But you don't have to do it like this at all. I don't understand what this has to do with GraphQL, you can make the frontend never update local state and only fetch from the server if you want. That's an implementation detail not related to GraphQL, REST, or any other API format.
> 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.
I agree with you here, but for:
> 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.
Again an implementation detail, if you're the tech lead, just tell your devs (or architect the app in such a way as to) not to put business logic into the frontend.
I wasn't referring to trusting the client's logic and state changes and then sending it back in an update and storing it. But certainly some devs do that.
As a simple example, you may send an entity to be updated and then the frontend makes a decision to say, you changed this value, then alter this other value so that the update request has the values we want (ie: one property may need to be blanked if another property has a certain value). Your frontend has logic it shouldn't and you should be enforcing your data on the backend anyway.
However, I was referring more to a situation where a frontend dev has an API request that it can work with but needs in another format or structure. And then logic is added to that data based on the user inputs or to simply do client side aggregations. Maybe it takes the user's chosen store location and filters out the out of stock products from the API on the client side.
Instead of sending the inputs to the API and have the API's logic handle it and provide you with the dumb data for your frontend to render - here are the products you should render; don't think about anything. So your frontend isn't growing into this brittle thing that is doing too much and is more likely to end up with dupe code as multiple frontend devs get tasked with new but similar components and recreate the wheel.
> 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.
I'd argue that it in many cases it promotes frontend devs adding more business logic. Because your devs can query for whatever they want on the schema, transform the data, do whatever logic in the components instead of relying on an API contract for said data.
It means there's really no thought into: what does this client actually need?
So the frontend devs don't have to involve a backend dev or team to get most of their tasks done, which may be a great thing for their situation.
But the business logic gets pushed more and more into the frontend and gets bloated and brittle.
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.
I find it a little weird and off putting that thierprivate business is having its expansion funded by state funds for coronavirus recovery. I get that this is generally a good thing, and many ISPs, especially the smaller ones, receive government funds for developing and maintaining infrastructure. However, why is the Coronavirus recovery fund paying for this?
In this specific case there is an easy answer (mentioned in the article): Access to reasonably priced broadband internet was seen as one of the biggest, most easily addressable (with targeted government infrastructure funding) dividing lines between people that were able to easily work from home and those that experienced larger hardships during the height of the pandemic.
If you think his ratio of good to bad business decisions is even average then you haven't been paying attention. Tesla has nearly gone bankrupt repeatedly, and it's stock price has largely risen the most after Musk was removed from controlling the company as a result of a series of tweets that were considered illegal attempts at manipulating the stock market. In point of fact, Musk still controls SpaceX and internal memos leaked earlier this year indicate that SpaceX could very well go Bankrupt within the next 18 months. The Boring Company is generally solvent and under Musk's full control, but it is far smaller, and could be in danger of law suits for effectively failing to meet contractual obligations regarding the tunnel the agreed to provide Las Vegas. The Boring Company's future doesn't look great to me, their results don't meet public expectations which could easily lead to funding drying up.
Also, anybody who thinks accusing a rescue diver of pedophilia purely because he told them not to interfere with rescue efforts is pretty far from being a genius. Musk has been lucky his whole life, people just rarely see his failures.
Basically, his press is full of shit. The claim that he learned to program and wrote a video game at age 10 is quite ridiculous. Seriously, there are online websites where you can play his "game". It's Space Invaders, except theirs only one alien, you can't have multiple projectiles on the screen at the same time, the alien doesn't fire at you unless they get extremely close, if the alien fires at you it locks your controls making it virtually impossible to dodge and prevents you from firing back, and when you successfully hit the alien it immediately respawns at a random location which may be in range of you, resulting in you immediately dying. My own nephew programmed significantly more impressive games at age 10, will people start following him and assume he's never made any mistakes if someone who owns an emerald mine gives him hundreds of millions of dollars to invest into new technologies and the businesses don't ultimately fail?
You are basically making a claim that he is a bad businessman without mentioning that he is one of the richest people in the world. Why should anyone take your arguments seriously?
He signed a binding acquisition agreement in a $44 billion dollar deal without doing any due diligence. Bigger deals have been struck on similar timeframes, but rarely has the purchaser evidenced such obvious buyer’s remorse so quickly afterward, or embarked on the venture with as little thought as he put toward it.
That’s a pretty weighty fact on the scale of “Musk - canny businessperson, or remarkable streak of being in the right place at the right time.”
So you suggest he is a bad businessman and his success is only attributable to luck. To understand how ridiculous this claim is you first need to realize that there are infinite ways to fail and very very little ways to succeed. Good and bad decisions are not symmetric, it is not 50:50, it is more like infinite:1. But even if it was 50:50, for the thought experiment sake, if you make random decisions you quickly make a bad one, and to be successful you need to make way, way more good decisions than bad ones. Sure luck is obviously always a factor, but thinking that he created a car that he later sent to space on his own rocket is not a sign of extraordinary competence, well, to me you can as well claim that the Earth is flat.
I’m not an Elon Musk fan but it was 1981 when he was 10. There were far fewer resources for learning to program and make games in 1981 than there are today. Not to take away from what your nephew did, but there are currently hundreds of “how to make a game” tutorials available online in a variety of instantly consumable formats. There are even entire development environments focused on simplifying game development with low code workflows. In 1981 there wasn't even the concept of a widely accessible public Internet.
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.