You don't need to do it, you don't even have to explicitly say no, you can just always find (or create) work that's more important to do than breaking your own morals. The worse that can happen is someone else gets the hot potato.
Later on when the engineering team was actually implementing it they thought Bird Mode sounded dumb and just called it Satellite View. And so it has been ever since.
There's a reason our satellites need station-keeping fuel. https://en.wikipedia.org/wiki/Orbital_station-keeping
Beyond LEO the drag is really negligible in the sense that other factors (e.g. gravitational abnormalities, the moon) have larger effects.
... and are therefore no longer satellites. https://www.nasa.gov/audience/forstudents/5-8/features/nasa-... https://www.nasa.gov/audience/forstudents/5-8/features/nasa-...
Some Lagrange points are stable and therefore will not decay toward the Earth outside of other factors. (Because these systems are never sufficiently isolated, in the eternal view, therefore, also still require energy, though much, much less.) Though, of course, an object at a Lagrange point may still not technically be a satellite of earth. https://solarsystem.nasa.gov/faq/88/what-are-lagrange-points (though by the NASA definition above I'd argue that they are)
As a practical matter, there's a differing relationship with atmosphere. Planes depend on air to produce lift and sustain flight, but satellites are either inconvenienced by air, or entirely unaffected by it.
Atmospheric correction however is really an issue and often results in distinct patches on the "satellite" view
The result is that satellite photographs are much more frequent and have much better coverage, while aerial photographs have much higher resolution. The dishonest naming of the Google Maps feature has given people extremely unrealistic expectations of what satellites can do, which results in difficulty in selling actual satellite photography products when they don't match what people have come to expect from GMaps.
Some of the pictures were from satellites, not airplanes.
Overlook
That's textbook bike shedding, and maybe it's why they seem to struggle with actual important things, like dealing with search spam.
I'm hearing Meta, Stripe, Google, Netflix, Lyft and Uber are hiring like crazy for amazing salaries. Not only that but one basically just needs to sort of show up half the time and surf the net 99% of the time there.
That was obviously sarcasm.
That is obviously not the case
Benchmarks are meant to be reproducible, meaning perfectly predictable. CPUs have things called branch predictors which try to predict what the software is going to do and try to do the calculation ahead of time resulting in (hopefully, if it predicted right) faster execution time. If you know which 'branches' a benchmark goes down, you can make a program which can coax the branch predictor to always make the right guesses for a given benchmark.
A program branches whenever you encounter some sort of conditional if-else statement.
Print '2' is lot less operations than (insert formula here) if you know the answer is already 2.
Caveat: this applies to perms. It doesn't apply nearly as much to contractors (as my many experiences with saying "No, but..." to managers and being canned can attest.)
Anecdata. One of my colleague got fired for not meeting expectations at his level for two consecutive halves. From what I've seen, he was competent and provided value to the project. Some companies have high turnover and are functioning with the idea that everyone is replaceable.
One of my proudest moments was about seven years ago. I was two years into my career as a junior software engineer with no academic background in programming. I was by any measure an impostor and I worked very hard to learn and impress and earn the luck I was given with that job.
A PM, one who I liked and wanted to impress all the time, came to me asking for help to get git commit history for each person on our wider team “to measure how productive everyone is being.”
Despite being anxious about “what-ifs” like being blacklisted or some other concepts I knew nothing of, I gently explained why it would be a bad metric. I remember even saying, “some of the best engineering someone can do is to write negative lines of code.” I felt so wise despite being so green.
He pressed the matter and I calmly said that I said my part and I’ll play no role in this.
I asked around weeks later and apparently he approached nobody else and the issue was dropped.
Maybe this is a mundane anecdote or I’m not telling it properly but I’m still so proud that I was even capable of seeing the ethical dilemma, let alone acting correctly on it. Those years were full of “I have no clue what normal looks like in this industry.”
I feel somewhat confident in saying that experience emboldened me to do the right thing even if it was scary. Sometimes I worry that I fly too close to the sun with my attitude of “you won’t fire me.” But so far it’s worked.
Why didn't you teach him to find people who were writing negative lines of code?
You want to aim for a plane with the right weight, but you only know what that is by working out the entire design. Similarly you want to aim for the right number of lines in your code base, but you can only know what that is by working out the entire design.
Maybe engineer A has a easy feature to do. Lots of lines of code but it's smooth sailing. Another engineer, B, has a tricky bug fix to do, which requires him to read documentation, navigate the fode, reproduce the issue, until he published a fix with a handful of lines of code.
Who's the better engineer, A or B?
Even if we consider the average over time, one may be getting more tricky features than other. Or spending time in tasks such as hiring, mentoring, etc, which is worth a lot to companies.
For example, I worked a .NET project with a central form that had close to 30K lines of code. This was 10x in comparison with anything else in the app. This is clearly a "whale" of a problem.
The lines-of-code comparison made it much easier for non-technical staff to now understand why this "one form" (really dozen of different functions contained in a single form) was troublesome in terms of fixes, enhancements etc. and also why no one wanted to touch it.
Maybe it helps you understand if you think about how easy they are to game. You could just as well create useless lines of documentation as you could create useless lines of code.
Goodhart's law says:
"When a measure becomes a target, it ceases to be a good measure".
I'm not saying "LoC is a bad metric because it can be gamed". Most metrics can, if you work hard enough.
I'm saying "LoC is a bad metric because it can be gamed by a child within a couple of minutes".
It's the difference between lock made of a tin sheet and a proper heavy-duty steel lock. People like the lockpicking lawyer can still pick the latter, but the former is so weak that it should never be relied upon.
Avoiding LOC measurement for other (non-productivity) purposes is a mistake.
This is something I've been repeating to some of my younger colleagues.
Engineers aren't really fungible resources, to the extent that these projects require. Ask any manager how easy it is to swap "allocated resources", and they'll probably sigh heavily.
People are afraid that if they don't follow their manager's every request, they will be fired. But remember that hiring is hard, and managers are loath to fire someone they've already spent so much effort finding, hiring, and onboarding. Finding someone else to do it can take weeks, months, or longer! Which in many cases risks killing the project altogether.
Even if you're at the bottom of the chain, as the person who does the actual implementation, you have a lot of power on what gets prioritized.
See also the oft-circulated OSS "Simple Sabotage Field Manual" http://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabota...