samhuk

FYI: The linked video is Smarter Every Day dunking on NASA, Boeing, ULA, the pork barrel, and all that kind of stuff in-front of a bunch of big names in the space industry for around an hour.

It's a tough watch with some hairy moments, however really well captures the kind of culture and environment that led to the somewhat dire and/or depressing state of space exploration that we are at today.

Even the infrequent successes like Curiosity were billions (with a 'B') over-budget and years delayed.

Would you rather use a product that somebody treats as a vehicle to "Michelin star dinners, travelling, live music, skiing, etc.", or a product that somebody deeply cares about more than those things?

My point is not "care 100% about your job/company/product/idea and 0% about everything else", but rather striking a better balance.

To bring it back to the OP, selling Figma to Adobe was, in my view, part of an epidemic of SaaS companies valuing payout above creating a long-term sustaining business.

This is essentially what I replied to the comment with. Hard agree.

This, in my view, is quite a utilitarian (dare I say brutal) look on work and the world.

You are technically correct, in the same way "following the letter of the law" can be technically correct whilst missing the spirit.

For what it's worth, the engineers I have worked with in the past who take this utilitarian view of work often produce the poorer quality work and sometimes be really quite difficult to work with. This is because, with this view, "documentation", "design", "planning", "quality", and all those sorts of things tend to take a back seat in their mind as they become totally engrossed by "MVP", "well it works, so?", etc.

Personally, I think nuance is important here - I agree, there's a time for keeping the lights on, getting something to show, appeasing shareholders, and so on. However, there's also a time for taking a step back and taking some time to design, plan, optimize, ensuring quality, long-term stability, and hell, dare I say a bit of craftsmanship; life is short, might as well enjoy what you are doing for 1/3 of it and lavish in the art.

Takes all to make a world, I guess.

Force startups to aspire to create an actual product rather

I'm getting on to 10 years in the software industry as an engineer at the moment and in my view this is one of its most disappointing and frustrating aspects.

The whole software start-up scene just feels saturated with FIRE-obsessed individuals who prefer just about anything (money, vacation, travel, fame, ...) over company, product, real building, craftsmanship, etc.

I legitimately hear phrases like "5th time's the charm for an exit and payout!" way too often. It frequently just exacerbates the consolidation of technology, knowledge, wealth, and often hurts innovation, let alone can result in the solid team(s) of engineers left out to dry (although some can be also gunning for the payout in the end too).

In my view, there are just too many sell-outs pawning off solid products and teams to the highest bidder. I wish it wasn't that way.

This best describes my feeling.

I wouldn't expect such a sudden death from "business plan just didn't work out" though. Take Docker for example. Curious. Competition perhaps?

In a way I understand why, however I still am always perplexed when a "we are kaput" announcement drowns the message in praise for all the amazing super awesome they have done whilst not including a single character as to why, uh, perhaps the entire company/project/venture is ceasing.

To me, it only communicates that the issues were embarrassing, inconvenient, or otherwise do not shine a good light.

Am I reading too much into this, or does this kind of pithy announcement usually hide skeletons? Genuinely curious here.

Not found one yet. The linked article contains a very small amount of detail, such as the lat-long coordinate values they found within the dissassembled code, etc., but not much else unfortunately.

I'm waiting for the stuxnet-like report on this as much as anyone.

TL;DR:

* Polish train maintenance company, SPS, was getting suspicious as trains made by a company, Newag, kept on "randomly" breaking and couldn't be fixed. They was getting fined millions by Polish government as they had a contract that fined them for being too slow with repairs.

* They secretly hired literal hackers (Dragon Sector) for 2 months to dig around Newag train code.

* Hackers found out some incredible things, generally that fit under the umbrella of "late-stage capitalism", or more specifically, corporate protectionism, sabotage, ransom, etc.

Some examples of the secret code that the hackers found:

* Breaks the trains if they go into geo polygons that are right around the warehouses of 5 Polish train maintenance companies, including SPS.

* Breaks the trains after 1 million kilometers.

* Breaks the trains if they don't move for 10 days.

* Secret button press combination (basically Tekken, Street Fighter, etc.) to disable the "malfunctions".

Agree with writer, apart from a challenge on the "I get pestered at the office/on slack too much!":

I see this complaint quite frequently about flows being disrupted due to office/slack, having to "mute slack to get anything done", etc. In my experience, those who I have observed IRL complaining about this are, more often than not, those that tend to struggle writing clear and maintainable code, those that struggle writing concise and readable documentation, those that struggle writing up tasks properly, and so on. Equally more often than not, I have found that they often fit into the "Super Smart Engineer Individual Contributor" bin, who are clearly incredibly good at solving very challenging problems, sometimes performing great, field-leading feats of engineering, but fall short on the human side of the job. I know this is highly generalizing and not all fit this description, but it truly is what I have seen.

About me, I have been WFH for a long time, before the pandemic: <2019 60+% WFH, >2019 100% WFH.

* Saved 2,500 hours by no commute - around 100 extra days of life.

* Saved ~15,000-20,000 GBP by no train/car commute

* I'm quite particular about my food and drink, and invest quite heavily in it (some would say too much when it comes to tea and coffee :P). I fear hot drink vending machines, "nespresso pods" (which I disagree with on perhaps a spiritual, even cosmic level), and/or plastic "bag tea". Eeeek D:

* I'm quite particular when it comes to peripherals. My back hates Herman Miller knock-offs, generally any kind of "different" from my at-home setup to be honest. Thunderbolt, in 2023, remains at best a challenge, at worst a mystery for multi-million and a number of multi-billion companies.

* Office equipment in the last ~5 or so years has been on a somewhat downwards trajectory since 2019. Companies don't invest in quality software engineering equipment like they used to (understandable as paying for equipment that few use is a waste). This troubles me often; I fear that the pandemic has sparked a rapidly spiraling, high momentum, positive feedback doom-loop, i.e.:

1) Pandemic --> 2) WFH --> 3) Companies invest less in office equipment --> 4) More employees want WFH for better equipment --> 5) Companies invest even less in office equipment --> GOTO 3

Although LeetCode does have a strong algo slant, choosing the optimal data structure is almost always a key part in solving the problems.

If you think leetcode-like problems is always about the algo, "BFS or DFS" etc., then at best you are not realizing the data structure choices you are making, at worst you may not be so good at solving them or haven't progress that much through leetcode-like challenges.

Key take aways (for layman):

* Previous studies have used charged antimatter like positrons and antiprotons, which they imply is kind of silly because the electromagnetic force is 10^42 times stronger than gravity, so you have to set up absolutely impossibly precise electromagnetic confinement apparatus to measure the relatively tiny gravitational force

* So instead, they formed anti-hydrogen (which is neutral), and shot them (10^6 at a time, as my understanding of the text goes?) into a vertical magnetic trap

* They waited for the anti-hydrogen to either "rise up" or "sink down" to the top or bottom walls of the apparatus and measured the frequency of annihilations

* They biased the vertical magnetic field to various values, to see, at what magnetic field bias, the "top" and "bottom" annihilations were exactly 50/50.

* If anti-matter is repulsive, they would expect to need a magnetic field bias that would "help the atoms stay down" to get to the 50/50 "top" and "bottom" rate.

* They measured that they needed a magnetic field bias applied to the anti-hydrogen equivalent to "pushing them up" with 0.75g (+/- 0.25g or so), so anti-matter is attractive. No new physics.

* 10^-13 % chance that anti-matter is repulsive

* Rules out quite a lot of cosmological work that used repulsive antimatter to explain various troublesome cosmology roadblocks (dark energy, etc.)

Interesting, this was almost word-for-word how I was explaining it to a non-space-nerd friend of mine.

I'm still convinced that this theory, in a sort of occams razor way, is the most likely to be true.

If SLS was just "a jobs program", then what is the government's motivation for "a jobs program"? It keeps unemployment lower? Is that true though? If the SLS didn't exist, the engineers would just move on...no?

To me, it seems clear that it is just a knowledge preservation program; a way to keep STEM, rocket science and engineering in America, in-house.

I'm currently based in the UK, and lord knows how messed up our manufacturing sector is today because it got all exported to the rest of the world, because the government didn't inveat and ensure that we maintained a sizable manufacturing worker force. US is just doind what every other government is trying to do nowadays - keep valauble (military, industrial, etc.) skills in-house.

I used UTM extensively when creating an almost-no-touch tool for developers to setup their Macbook devices at the company I work for.

There's really no other convenient way to do this. It was awesome to be able to run the tool on a fresh MacOS install, test the effects, make some changes, then do it all over again with little fuss.

Thanks UTM!

I went down a bit of a rabbit-hole there. Apparently, the current belief is that the meaning is "If the eye is healthy, it functions as the light of the body and indicates that the owner is sincere, generous and helpful." [0]

I find it oddly reductive, unsubstantiated, and meaningless.

Perhaps I'm not the intended reader :P

[0] http://www.scielo.org.za/scielo.php?script=sci_arttext&pid=S...!

See: Gattaca

Odd statement, as it is of course always the thinker that gets the attribution, i.e. the manipulator of tools and the interpreter of results.

E.g.1: Galileo saw Jupiter, not The telescope saw Jupiter.

E.g.2: Joe built the wall, not The crane built the wall.

In this case, AI is the thinker, not a human, hence the phrasing.

A human creating the AI does not remove the attribution either, just as we never say Joe's mother built the wall just because Joe was created by his mother.

Tin foil hat: Insurance companies

Realistic: Doesn't earlier "treatment" of Parkinson's Disease yield better outcomes? I.e. dopamine supplements, etc.

When copper oxide superconductors were discovered in 1986, researchers leapt to probe their properties. But nearly four decades later, there is still debate over the material’s superconducting mechanism, says Vishik. Efforts to explain LK-99 came readily.

To me, the interesting take-away is that, right at the end. All too often we see peer-review as this slow, inching, excruciating process, particularly in social sciences where it's a de-facto afterthought. It was great to see science chugging ferociously away like a (somewhat!) well-oiled machine, such as the electronic analysis via slightly different methods (e.g. DFT) and the material synthesis efforts by the Argonne NL and Max Planck Institute.

Farewell for now, RTSC.

Side-note: Pure LK-99 is visually beautiful! Who would-a known from those crumbly grey flakes, huh?

Hey Bryan! Liked what you have done.

Big +1 for #1. A brilliant IC that has an impressive contribution history tells only a small fraction of the story. Skeletons may lay behind that green square matrix!

Also big +1 for #4. It may slow growth for some start-ups, but I think it's always better in the long term if hiring is deep, versus shallow.

As for compensation, those certainly are controversial. I believe in honesty, but your extent of it is quite...towards one end of the spectrum? Certainly interesting.

From somebody who, perhaps sometimes can be quite full-on about software quality, craftsmanship, and just generally doing good, here's what's helped me in the past when faced with a company/team that has morale, skill, or other problems:

1. "The extent to which you publicly complain about something should be proportional to the robustness of your solution and your confidence in it."

2. If you think things need to be done better, lead by example. I've found that you will be hated for saying things are bad, but loved for proving how things can be good (by example).

3. Note down your concerns (Notion is free!). Wait on them, then talk about them >=1 day later if you still feel like they are valid.

4. Ensure you have enough employable skills on the side so that you can jump ship if the company or your place within it is totally DOA.

I've always assumed that greed, particularly when it's egregious and endemic, would more rapidly unwind a start-up. My OC was more focusing on those mechanisms that tend to be at play at start-ups that cause them to gradually decline/implode.

However, I totally agree with your point. Also, sorry that happened to you!

Preface: I'm not saying that this norm is necessarily right, rather just explaining the mechanism that I believe is at play here.

Isn't part of the issue that early on in a start-up, everyone is indispensable, and often that comes with putting in extra hours and going the "extra mile" for the viability of the company?

When you are over 35, 30 even, you are much more likely to have a spouse, children, etc., and all these command more of your time that the business wants to capitalize on.

Personally, I've seen some real rock-star engineers both at 20 and at 40, however more often than not for different reasons. Honestly, not once have I ever learned a decent life lesson from engineers around my age (I'de say I'm on the younger side), however it's been several highly memorable times that an engineer on the older side has pulled me away, given me some real hard-hitting, incredibly valuable engineering and life lessons, and changed my career and sometimes life for the better.

It's a complex world!

I find it hard to imagine that it's possible to, in all likelihood, improve a too-technical leader problem from the individual team member position. There's only two ways through which that I can conceive it being solved:

1. Too-technical leader realizes they aren't fit for purpose, perhaps due to indicators like stress, missed targets, team morale, etc.

2. Higher-up leadership notices aforementioned issues and give them the ultimatum: leave or side-/demote to more technically-focused role.

I agree with sibling comment.

Also, wow, that took some courage. Personally, I deeply value this way of direct communication when everybody feels free to speak up when things go wrong, and nobody has precious egos they feel need protecting.

I think another comment made a good point - It's all about rapidly determining when the hires and promotions aren't right.

It's interesting that you have experienced both sides of the leadership problem space. Honestly a bit glad to hear that others share my experiences and that I'm not just unlucky or something.

Also, oh my do I ever have an extremely similar experience of an IC-type engineer going into a leadership position and trying to "engineer" it: put all teams, sprints, tech visions, growth frameworks, etc. in huge spreadsheets. I look back in jest now, lessons to be learned!

Thanks for your comment. Totally empathize with your experiences there.

I'll raise your spark for complete destruction.

Here's an incomplete list that I keep around of the mechanisms that I've observed so far that have played a big part in the decline/destruction of an engineering team (and product thereof):

1. Too-technical leaders:

As startup scales, there can sometimes be a mad dash to fill new leadership roles (e.g. VP of Eng, Arch, CTO, etc.). Super-star engineers present at startup phase sometimes move into these when they are not the leadership type, causing engineering team to devolve into a visionless, directionless zoo.

2. Non-technical leaders:

Inverse to the above - as startup scales, in desperation, new leadership roles are filled with non-technical individuals who have little to no engineering experience. This causes similar outcome to #1 (albiet slightly different, but equally perilous).

3. Problem engineers:

Small number of leaders lack a spine, conducting shallow interviews and let in "problem engineers" who spoil the party and wreak havoc. Lax hiring practices almost always are reflected into non-existent firing practices, leading to them lingering around.

From experience, it only takes around ~5-10% of a team being this type for it to have a large negative impact, as they tend to derail progress, dodge responsibility, reputation farm, push rubbish, all that nonsense. It harms morale, and the skies turn grey in the office...

4. Micromanagement:

Speaks for itself. Leads to red tape, demoralization, timeline slippage and frustration.

EDIT: I'de love to hear how these foot-guns have been avoided. From experience it seems really challenging, as if like magic; as if cultivating and maintaining a good engineering team and culture therein is like balancing a pencil on it's nib...