drfrank
> 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.
I'm not familiar with whatever language this is, but wouldn't such a construct always indicate something was being ignored?
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.
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.
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.
How much sugar was consumed?
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.
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.
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.
The two solutions seem complementary.
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. 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.
They have a finite set of responses, though. Ask them what the difference is between a burrito and an enchilada.
I've been waiting for such a keyboard for 15 years.
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.
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.