Galxeagle

I had a lightbulb moment when someone said 'the point of iterative approaches is not to find bugs, it's to do something (small) successfully and build confidence+learn'. There's a subtle but important difference between the iterative approach that SpaceX takes and 'debugging through exhaustive retries', and I'm worried NASA would look like the latter (and admittedly, some of the more recent starship launches look that way too).

The ability to pick a small-but-well-defined goal as an interim milestone - and stay focused on it - is a key skill, and too often I've seen waterfall-like companies slowly scope-creep their first MVP until it's a lumbering mess. You almost always need someone with a strong personality to push team to 'get it done', and that level of ownership is really hard to come by in an organization historically built around ass-covering.

I think Commercial Crew is the right model for NASA. Pick the design objectives, provide some level of scaffolding regulation (i.e loss-of-crew calculations), and then contract out to private sector to actually 'get it done'. (Yes Starliner was a failure, but Dragon is definitely a success. A 50% hit rate and success of the program overall is better than Artemis)

Not clear to me from the article - what's the different between an 'open rotor' engine and a turboprop (https://en.wikipedia.org/wiki/Turboprop)? At face value, both seem to be jet engines with propellers used on single-aisle planes?

The key insight here is the same reason why every internal department service eventually goes to a ticket system - adding queues (and by extension delays) improves efficiency. Resources can be used at 100% capacity ('always more work to do'), you can offer good service to only those who matter (i.e exec VIPs), and you can batch work (pour 2+ cups of brewed coffee at once).

Unfortunately it means that any time you need anything from someone outside your team, it comes with a lead time of '3-5 business days' unless you know the magic words or you raise it up the chain.

One of the big design challenges with self-driving cars like Waymo is communication with pedestrians - have to have some analogue to making eye contact or waving so pedestrians know they've been seen (possibly through audio or LED message signs)[0]

It's fascinating to me that a plane in full (emergency) autonomous mode, having run an algorithm to identify airport and landing sequence, is using speech to text to broadcast over analogue radio to the humans in the area. And the tower tentatively communicating back ('Outfitter 9, if you can hear me, cleared to land...') to do the expected final step in the exchange.

https://www.theverge.com/2023/10/13/23913251/waymo-roof-dome...

well I never said their sales team was good ha

Thanks for closing the loop - always interesting to hear about any progress when stuck in a bureaucratic logjam.

Have you tried going through Sales? Account teams can usually move mountains if they can see a clear path to a paycheque - you might have luck just by going to the 'chat with me' popup on the azure home page and saying you have thousands of budget and would like to chat with a rep.

In my experience, having a fixit week on the calendar encourages teams to just defer what otherwise could be done relatively easily at first report. ("ah we'll get to it in fixit week"). Sometimes it's a PM justifying putting their feature ahead of product quality, other times it's because a dev thinks they're lining up work for an anticipated new hire's onboarding. It's even hinted at in the article ('All year round, we encourage everyone to tag bugs as “good fixit candidates” as they encounter them.')

My preferred approach is to explicitly plan in 'keep the lights on' capacity into the quarter/sprint/etc in much the same way that oncall/incident handling is budgeted for. With the right guidelines, it gives the air cover for an engineer to justify spending the time to fix it right away and builds a culture of constantly making small tweaks.

That said, I totally resonate with the culture aspect - I think I'd just expand the scope of the week-long event to include enhancements and POCs like a quasi hackathon

I've come to appreciate that using AI tools are a skill on it's own. Anything beyond auto code completion takes quite a bit of conscious effort to experiment with and then learn how to delegate to in a workflow. They often end up being valuable, but it did take some work to get out of my productivity 'local maximum' that maybe not everyone would naturally take on.

I like thinking about the ISS as primarily engineering (and operational) experiments rather than hard science. As a space platform, it's provided learning on how to contract private companies for space flights, and in turn, how they should operate, plan, etc. Or how to do internationally coordinated space operations. All of the work it takes to mature a new tech to a 7,8, or 9 on the NASA Technology Readiness Level[0] while Curiosity and Ingenuity and other long-distance (and JPL) missions focus on the hard science of 1's and 2's.

That said, I too think the main value of ISS declined several years ago or more. Looking forward to the next generation, whatever it is

[1] https://www.nasa.gov/directorates/somd/space-communications-...

I get the sense that #2 is viewed as a risk for DRM, given all the work that goes into preventing firmware downgrades to potentially insecure firmware. Specifically thinking of the Nintendo Switch[1] that goes so far as to blow fuses on each firmware upgrade!

https://news.ycombinator.com/item?id=23534793

You piqued my interest enough to go hunting - this StackExchange[1] question estimates ~19% of fuel is spent on initial climb-out to 30k feet for a 737-800 on a 5-hour LA->JFK flight.

Without doing hard calculations, it intuitively feels pretty marginal potential flight weight savings for the operational complexity it would add

[1] https://aviation.stackexchange.com/questions/47262/how-much-...

Any extra time spent during a burn is wasted fuel. Intuitively, any time before the rocket is in orbit, some part of the rocket thrust is resisting the force of gravity or else it would fall back down to earth. The longer that time is, the more thrust (and thus fuel) was spent negating that force. It's the main reason why the Falcon 9 boosters do a 'hoverslam' on return and land at close to full throttle - any extra time during that burn is less fuel efficient.

Better fuel efficiency = more payload to orbit = plenty of justification for the extra complexity.

Admittedly gravity losses are more significant at the beginning when the booster/ship are ascending purely vertically than later in second stage flight which is mostly horizontal, but definitely still a factor.

Also from a license negotiation perspective, gives the buying company the option to threaten to self-host and/or fork. Even if they never do (and I'm sure the source company is very careful to balance the value story), it can act as a ceiling for rate increases or other annoying business practices.

Why would a company ever open-source their product then? Giving up that complete leverage can be a selling point during the purchasing process, making buyers more comfortable that they won't be (completely) locked in, and be a net positive on revenue through faster sales.

Political blowback has been enough to keep the power in check - it significantly raises the visibility of the attempted action whenever it's invoked(1) and historically has been associated with a political hit. It also has a 5-year sunset/renewal requirement, and can only override certain sections.

I think everyone would generally agree a constitution would be stronger without it, but even if 'it's only a matter of time', it's played out as a pretty decent compromise to actually get the charter signed ~45 years earlier than potentially no charter at all.

Canada generally relies on trust and good behaviour more than the US system of checks-and-balances - the most obvious difference is that our Prime Minister plays the role of both US president (head of exec) and congress (technically just the House equivalent, but the senate equivalent is much weaker)

(1) https://www.cbc.ca/news/politics/notwithstanding-clause-doug...

I encounter similar behaviour as you in an entirely different genre - I've long since suspected that Spotify keeps redirecting me back to songs that are either less royalties for them to play, or located closer to me on the CDN to save serving costs.

Air traffic communication is structured and a very limited subset of English. It makes more sense if you remember that that first call in the video isn't coming out of the blue - the pilot of Delta 29 Heavy would have already been in contact to start taxiing etc and is expecting a pending authorization call, knows the format it will take ('call sign - command - modifiers/watch-for'), and then it's all read-back anyway to make sure there's no misunderstanding.

The communication gets much clearer and less staccato when something is going on that's not regular - my favourite example is an incident at JFK where a taxiway was unexpectedly blocked and you can watch the Russian pilots struggle a bit to explain[1], presumably because 'cones' isn't in the normal ATC glossary[2]

[1] https://youtu.be/YmywjMQDbos?feature=shared&t=77 [2] https://www.faa.gov/air_traffic/publications/media/pcg_4-03-...

I will often do the reverse, especially when they've repeated the same opposition point more than once or I'm feeling unheard - 'I'm worried I've miscommunicated, can you paraphrase back what you've heard my point is and I'll clear up any nuance?'. It does wonders when someone is being territorial or arguing in bad faith to watch their gears turn on how to respond while maintaining their arguments.

If it’s the interior design aspect that’s enjoyable, we’ve gotten a lot of mileage out of the Animal Crossing expansion pack

https://animalcrossing.nintendo.com/new-horizons/happy-home-...

Kerbal Space Program gets high marks for giving me a great intuitive sense of orbital mechanics, aeronautical design, and space mission architectures (‘to get to space you need to go sideways, not up’), even if the actual rocket building is simplified to Lego-like to keep it fun

My light bulb moment was when I looked at the Apollo 13 orbital paths and mentally considered a few alternatives they could have done too.

https://store.steampowered.com/app/220200/Kerbal_Space_Progr...

This is what helped me work through some perfectionism tendencies: change the target. Reframing from 'making sure this project goes perfectly' to 'maximizing my personal benefit' helped me step back a bit and prioritize balance

The key reason is that an extra second of time spent hovering or close it is another second of resisting gravity, which takes fuel, so the most efficient hypothetical ‘burn’ is one big bang ‘hoverslam’ right at the end and 0 seconds spent fighting gravity

The SpaceX Falcon 9 rocket does have throttle control, but at minimum thrust the thrust-to-weight ratio is still greater than 1, which means they have to hit 0m/s at exactly 0 feet of altitude or they start going up again. I’d imagine they time their ‘hoverslam’ to take 2x minimum thrust (or some other multiplier) and then adjust up or down through the manoeuvre.

As a SpaceX fan reading through the post-launch analysis, this was definitely more of a success than the headline applies, but 'massive' is a stretch. Most commentary I'm seeing put it at a C or B-. It's true that there was a number of areas where the risk is now retired, but three engines out at launch with three more dropping out along the way hints that their engine design still isn't as reliable as it needs to be, several years and several engine test campaigns later.

SpaceX doesn't have a test stand where they can static-fire the booster at full power or duration, which feels like an interesting gap in their usual 'hardware-rich, test-often' iterative approach. I'm betting we see something like that roll out soon.

Finding lots of value in drafting emails, especially for topics or asks I'm not as used to dealing with, like asking for extensions or blaming other teams for blockers. Obviously takes a few iterations ('be less verbose!') but I get a lot of value in seeing a couple different ways to word the request and how to frame the background facts to come to the conclusion I want.

Started using it as a coaching tool for new hires who aren't used to the world of corporate memos yet.

Copying my favorite quote from a different thread about data scientists: it's 'decision-based evidence-making'

From an individual perspective, we've really valued Google's SRE whitepapers in interrupts and incident handling. The key message is that setting up your team to enable bundling 'jumping on things' and also 'focus delivery work' makes both people happier and more productive than asking two people to do both. https://sre.google/sre-book/dealing-with-interrupts/

From a PM perspective, that also lets management pre-allocate capacity for the sprint. '2 people on prod support, and 3 people on development/project work' is a decision that can be made and pointed back to. And being allocated to 'jumping on things' means you don't have to justify your productivity/velocity/ticket count beyond responsiveness and issue cycle time.

Use 1:1s to talk about things you can't talk about in a group setting. I tend to use them for two main things: organizational gossip and negotiation.

Often times managers have much richer insight in to other managers or where the department is going, but would be unprofessional to share that candidly with a whole team. Getting some unvarnished perspective has been seriously helpful for me to understand what's coming or learn how to 'play the politics'

Similarly they've been useful for me to practice some gentle negotiation - 'what do I have to do/show to get x on my year-end review' or 'I'm looking for x raise, how can I build a business case to convince you'. Whether or not they say yes right away, it's always insightful as to how the performance review system really works.

I'm in the market for a new car after living car-free downtown for several years. Interestingly I actually have some anxiety about the resale value of ICE cars - when I sell in 5 or 10 years, the value will be inherently tied to the price of gas, and how widespread the electric car roll-out ends up being.

If gas spikes again like this year and some pending ICE sale and area bans come to fruition... I have trouble seeing ICE valuations keeping up with electric.

That said I'm a bigger proponent of investment in transit over perpetuating car dominance, but that's a different thread to pull on.

“Never wrestle with a pig because you'll both get dirty and the pig likes it" - the source of disagreement here is about whether or not policy needs to be followed, not about the details of the policy, so stop trying to argue the policy on it's merits. You need to do a quick review of roles and authorities, clearly lay out (ideally mutually agreed upon) standards, and identify the implications of not following the policies - i.e 'if not xyz as agreed, then the PR won't be approved' or 'if sarcastic/bad attitudes in meetings, then I'll work with [the people manager] and create a PIP'.

Empathy is super effective in this situation - use the magic words 'it seems___' and get their reaction. 'It seems like you're trying to get as much code done as possible and see these policies as busy work'. 'it seems like you don't think the quality of the team's output is how you'll be measured'. Sometimes there is legitimate misunderstandings (were they told they need to write x lines this year to be promoted?), other times they're missing an implication and need a reality check.

Can't speak to exactly why they didn't have it, but it was not a deliberate decision ("It's my uniform," said Master Cpl. Perry Morrow. "I'd rather wear this than no clothes at all.") from a relevant CBC article at the time about it(1))

For years afterwards whenever there was a discussion about equipment and supporting troops, it was brought up as an argument in favour of more purchases.

(1) https://www.cbc.ca/news/canada/canadian-troops-not-green-wit... https://www.latimes.com/archives/la-xpm-2002-jan-19-mn-23667...

We moved to a somewhat set release cadence and then instead of discussing timeline estimates with clients, we discussed release scoping and what was in the next release(s).

It had a helpful effect of abstracting the development team and helped shift the conversation away from button clicking towards a ‘product increment’ and all the extras it entails, but also from the customers perspective it helped engage them on a more meaningful level - prioritization of features vs the technical steps the dev team would be performing.

Then we avoided justifying timeline in favour of ‘if you wanted it for next release, we’d need to drop a/b/c or add resources x/y/z’ beyond a cursory ‘it adds some complexity with the other module’ etc.