We don't really have any way to know that. Considering that there may be as many stars in the sky as grains of sand on Earth, there are many many unknowns.
For another example we don't know for sure if our universe is the only one and it's entirely possible that everything that could ever happen plays out in real time across and infinite number of universes. We don't have any way to physically measure that possibility yet. We only have mathematical theories.
Similar to how Copernicus proposed the heliocentric model, maybe our universe is not even the center of existence?
With python I'd decompose that one-liner into several variables for readability. That probably ends up using more memory than it would otherwise but I generally don't work on systems where that matters much.
Scala was really nice for this syntax when I used it for Spark.
Legally, that pile of paperwork gives the Apple corporation some rights of a person. Obviously it is not a living, breathing person in the biological sense. But it is treated as one from a legal perspective.
Should it be? That's a different question. Changing that would probably upend contract law.
I'll second this too. As a former manager told me, figure out how to scale yourself. Making the end to end development lifestyle easy for peers and partner teams is one way to do that. It could just as easily be called platform or systems engineering with a touch of DevOps.
It's like UX for data people. How to make a cohesive experience among the various tools, scripts, services that people use day-to-day so they can use and maintain datasets efficiently.
A non-technical benefit is there won't be so much context to keep in your head when triaging data issues in the future.
A database table is very similar to the separation of concerns problem of core software engineering. A table really just is an abstraction for storing and fetching various data points.
Finding the right balance is part art and part science.
It is important, but when the shift to cheap compute and storage hit an inflection point it became possible to build out wide tables that combine the characteristics of facts and dimensions, and real data modeling took a back seat. That possibility led to bias toward moving quickly with less emphasis on making the data model sustainable.
I'm seeing the pendulum start to swing the other way, where the complexity of these scrappy and loosely structured data models is hampering the ability to innovate, and even slowing down the business. The models are often inflexible and hard to maintain with hidden bugs and gotchas.
I use an unscientific rule of thumb that 10-100x scaling is about the most to plan for except for exceptional cases. Anything beyond that ends up with overcomplicated bloat for a "tomorrow" problem.
Being able to handle spikes and iterate quickly is probably more important.
Some business area pivots could be into user analytics or marketing analytics. Product management even.
Data engineering could be another path to explore.
I'd view your sister-in-law's certification course as more of a first step than an end. It could open doors but still have to stay relevant with broader skills.
“We are confident that, once we show what the fossil fuel companies knew about global warming and when, and what they did to deny, delay and deceive the public, the jury will not let the fossil fuel companies get away with their reckless misconduct.”
You are confusing "service fees" with taxes. There are various tax regimes. Very few of them are proportional to the services you use.