drfrank

Elon wrote: https://twitter.com/elonmusk/status/1649523985837686784

3 months ago, we started building a massive water-cooled, steel plate to go under the launch mount.

Wasn’t ready in time & we wrongly thought, based on static fire data, that Fondag would make it through 1 launch.

To me, it sounds like people that would have been considered experts (and probably still are) made assessments than turned out to be incorrect.

Naively, it seems to me that there should at least be a warning somewhere if there are declarations after a REJECT-THE-REST.

I'm not familiar with whatever language this is, but wouldn't such a construct always indicate something was being ignored?

It seems this is a one-time opportunity for some engineers to catch up with inflation. It doesn't seem that Microsoft is adjusting it's salary ranges.

Put another way, starting to work at Microsoft, this year, will still be 11% less attractive than it was two years ago.

Microsoft seems to recognize (but not acknowledge) that it's not competitive in compensation, and seems to be reiterating its commitment to its current strategy.

Has an insurance market already arisen?

I.e. can I buy insurance for some percentage of my transaction against a bug swallowing the whole value of my transaction?

Seems like an opportunity to let an economic market drive more rigorous dev and test practices by giving shops with more rigorous practices lower fees.

If you want to influence the direction of the sequel to Star Control II currently under development it seems that you can do so on reddit: https://www.reddit.com/r/uqm2/

TFA implicitly conflates "leadership" and "management", suggesting that the author is oblivious to the distinction.

Even when the author describes dividing the responsibilities of "leadership" among multiple people, they describe dividing both leadership and management responsibilities between those people.

This is an authoritarian model that makes the local despot the bottleneck for the team: Decisions end up being routed through the "leader", individual growth and development and team value is constrained within the scope of the "leader".

These constrained teams have limited potential, and so, because of the leader's limited focus and the departure of team members who feel constrained, the organization develops cracks and holes in responsibility and ability to act on opportunities.

Managers who subscribe to this authoritarian model promote authoritarians, capable technical contributors who want more control over the part of the system they and their peers have been working in.

The best managers don't have a hard time finding talent for open positions on their teams: They already have networks of former employees and peers that they can use. Indeed, the employees of the best managers recruit for their teams as soon as positions open up.

But virtually all of the job postings you'll see publicly (especially for replacement positions or incremental growth) are described solely in terms of the project and the expected technical skill requirements rather than or in addition to the attributes that make a team more than a collection of extra appendages for a "leader". E.g. team values and non-values, the existing roles and expertise of the other team members and how the open position will complement those, the team's norms around work-life-balance and communication, etc, etc.

I think that the average manager at a tech company is not a good manager, and that the larger the company the lower the average (smaller companies just fail with bad managers). But by far most open positions at any time are positions reporting to bad managers.

What was "the fasting condition" in the study? They started a fast with sugar? They ended a fast with sugar? What was the interval between the ingestion and the test?

How much sugar was consumed?

If you're having trouble concentrating on a ketogenic diet it's likely that you're not eating enough vegetables, and might be eating too much protein.

Too much protein can take you out of ketosis, but people think they can just eat lean hamburger three times a day.

If the fat/protein ratio is right, the inability to focus can be a symptom of electrolyte deficiency, particularly sodium, potassium, and magnesium. You should be getting potassium and magnesium from vegetables, but supplements can be a useful diagnostic tool: If you take 400 mg of potassium and find, an hour later, that you're thinking more clearly, that's data.

Don't overdo it with electrolyte supplements, though; too much sodium can increase the calcium in your blood enough to give you kidney stones, if you're lucky, and worse effects if you're unlucky. Too much potassium can mess with your heart.

Take regular breaks from the medication.

I'm not sure this is universally necessary. When my pre-adolescent son forgets to take his medication in the morning it's immediately obvious, so it's clearly still having pronounced effect. He's been on the same dosage of the medication continuously for five years.

A spherical Whipple shield might be able to capture debris. A 1 mm thick aluminum shell with a radius of 100 m would mass 810,000 kg. If SpaceX's Starship can achieve launch costs of 10/kg, that's $8 M per sphere.

But passive objects are only as likely to provide value as the ratio of the number of the total volume of the sacrificial objects to the total volume of assets, so you'd want a bunch of them.

Since the debris of interest is really just the material traveling in orbit, a cylinder might be more efficient, if some primitive attitude control could be included efficiently.

That handles plastic that's already floating, whereas this claims to bring plastic to the surface.

The two solutions seem complementary.

I discourage the use of "this" except for field references, in C#.

Field access and modification are the most important part of a member to consider. Mutation is a well-recognized pattern for bugs. I want the points in the method at which mutation occurs to be highlighted. The use of "this" to distinguish fields from locals makes that possible.

If you've been programming for a few years, frequently just the field access pattern gives you an intuition of what sort of member you're looking at in just a glance.

The programmer's brain holds limited context at any time. The larger the context required, the less detailed the understanding. Being able to predict what a method does in a glance means the developer better preserves their current context.

I strongly avoid inheritance, so I rarely have use of "base". Again, when I'm explicitly invoking "base", I really want that to stand out, because it's unusual.

(For this same reason, I also discourage explicit use of the "private" access modifier. Everything should be private, except for the few things that must be public. Extra access modifiers add noise, which distracts from the important information.)

Finally, I strive to make my code read as fluently as possible. In my experience, fluent code makes it harder for bugs to hide. The ability to clearly express a concept in a spoken language correlates very highly with the ability to implement that concept in a program without errors.

Compare:

if (AllChildOperationsAreComplete) { StartNextOperation(); }

if (this.AllChildOperationsAreComplete) { this.StartNextOperation(); }

The extra hiccoughs in the expression of the second form are each interruptions, each interruption increasing the chance that you drop some context while reading the code.

The U.S. doesn't have to choose between total shutdown and total opening. Targeted opening is feasible.

The U.S. also doesn't have to choose between individual destitution and death of the vulnerable. Some combination of financial support covered by bonds with freezing debt collection of various categories would provide significant relief.

As in all macroeconomic challenges a combination of approaches is necessary.

Aren't physical side mirrors also still required in the US?

Is this the phenomena described in Neal Stephenson's _Atmosphaera Incognita_?

Many telemarketers have switched to "soundboards" which use responses pre-recorded from native speakers. It's increasingly difficult to recognize that a robot is talking to you. You can ask them if they're a robot, and they have a pre-recorded answer ready for you.

They have a finite set of responses, though. Ask them what the difference is between a burrito and an enchilada.

This is the article that I share with my coworkers when I see them reaching for the Visitor Pattern: https://lostechies.com/derekgreer/2010/04/19/double-dispatch...

Seems likely it could scale with expected usage.

I don't get it. What does this do?

I don't need the numeric keypad; I'd rather have that space for my mouse. But I do need an ergonomic angle between the left and right sides.

I've been waiting for such a keyboard for 15 years.

As I understand it, this article misrepresents the purpose and nature of the Null Object Pattern ("NOP").

The author cites a comment that describes (very) vaguely a "hotel booking" example, expressing the idea that "None" is the null object. But "None" is not an instance of the NOP. None has no interface. You can't tell None to do something.

In contrast, an acutal implementation of the NOP might be in a travel reservation service which allows you to reserve both a hotel and a rental car at the same time. Somewhere in the guts of that service there might be a Trip object.

  class Trip
  {
    Car car;
    Hotel hotel;
  
    public void Reserve()
    {
      this.car.Reserve();
      this.hotel.Reserve();
    }
  . . .
  }

I've encountered this misconception frequently, and it typically stems from the common understanding of object oriented programming as programming in terms of entities which represent physical objects in the real world. I deduce that the author uses this definition from the sentence "It is also interesting to note that appearances of null objects are virtually non-existent in real life."

Objects aren't necessarily representations of physical entities. Objects are simply things other objects (or procedural code) can use to accomplish something without having to know how to accomplish that thing.

I've found the distinction that Alan Kay has (repeatedly) made useful in helping people understand this idea: Property accessors aren't for objects, they're for Data Structures.

So, when the author says that, "the basic idea of the null object pattern is exactly the same as for practices like 'use zero instead of null'", my reply is, "No, it's not called the 'Null Data Structure Pattern'." Use zero instead of null is (flawed) advice about how to write data structures, not how objects should be constructed. The NOP is not used to build objects that represent data, it is used to build objects that represent action. The author's repeated use of the GetCustomer example is inappropriate for the NOP. It's much more likely that a database record is represented using a data structure than an object.

Pragmatically, if you feel the desire to ask an object if it is the NullObject, you are not writing object-oriented code, you are writing procedural code. Instead of asking if the object is the NullObject, move the branch that would be invoked if the object were the null object into a method present in the interface that the NullObject implements. Perhaps you find that you don't actually have a NullObject, after all.

The article referenced by this article lists nine features of which eight are syntactic sugar. (Being able to declare the out parameter in place has a very minor but significant impact: Preventing abuse of a variable intended to be used as the out parameter.)

It's disappointing to see the team spend its time on so many minor features rather than tackling fewer major improvements.

I'm sure we all have our pet features. My wish would be structural typing: Very few of the C# developers I've worked with in the past couple of years have embraced isolation testing. A significant reason is the frustration with "extra" interfaces and the distractions they introduce in code navigation. Anything that eases the the uptake of isolation testing would dramatically improve software quality, which as we know, would dramatically improve our efficiency.

I wonder what a woman that spends $50,000 to freeze her eggs in her mid thirties would say about a man who spends $50,000 in his mid thirties on a sports car.