I really liked their electric XC40's and tried to buy one last year, but ... I just can't figure out car dealerships. They had two on the lot, I had enough in my checking account, I go there on a Saturday morning, and ... It was just a mess. The sales guy first said electric cars are dumb and I don't want one, I actually want their biggest SUV, then he said he could only lease the electric cars (with horrible terms), not sell them. I gave up and went home to see if there is a way to buy a new Volvo online -- no. So I bought my second choice (a Tesla Y), with an app, in about 30 minutes.

They lose in every timeline. The US would have nuked them.

Any significant disability....

https://www.nytimes.com/2008/11/04/world/asia/04iht-doctor.1.17504311.html

OMG it's so good to hear that this is changing. Twenty years ago, in college, I responded to flyers around campus about a support group forming. The therapist refused because obviously the support group was only for women. No mention on the flyers. She was surprised I tried to sign up and said I'd make everyone uncomfortable.

I know we have a ways to go but I'm glad there's even a thought that maaaaaybe men need and can benefit from support, too?

So cool, thanks. As a kid I spent so much time in DEBUG, stepping through DOS's executables, and especially the Interrupt handlers. It's so neat to see the actual source code-- way easier to read and follow. I didn't know it was all written in assembly, from within Debug it sometimes seemed so messy and convoluted that I just assumed more was written in C.

Hedwig. I thought it was such a beautiful movie and about half the people in the theater left.

+1-- I'm so impressed by the "reasonably large admin team"s' thoughtfulness and transparency.

It's not your fault. Tell someone. You'll survive.

Hey, don't be discouraged.

You are a treasure and rare. There are places for folks like you. I hope you can find one where the culture fits you and knows your value.

Until then. You can try to change the culture. But if that's possible depends on more than I know for your context.

With small teams it's easier. Demonstrate competence, gain trust of everyone around you, then sell a better tomorrow where ... Stuff just works. Faster velocity, more features, fewer bugs, etc.

This is a very valued message in some places, and totally not in others.

I have a feeling that infrastructure/platform/core teams -- those making tools for other engs -- are probably more naturally aligned to quality and lower defect rates. That may be a direction for you if you aren't sure where to start aiming towards.

Is this for interviewing or promotion?

At my org the formal definition is "[demonstrated] ability to lead projects at x scope." This is how people leaders frame it.

But to individual contributors (engineering track) folks, I think we are looking for:

• Thinks. Applies themselves to the hard work of figuring things out. Reads documentation for libraries and languages to get how to use them. Doesn't vomit up random groupthink (from the wider org or web) without understanding it.
• Curious: doesn't take "this is how we've always done it" as a thought stopper -- wonders if there's a better way. Flexible, open to learning.
• Teamwork skills: communicates own level of certainty, listens to others and tries to understand -- not stubborn: honestly tries to figure out the best solution rather than trying to look smart in front of others. Has a feel for how to help everyone be heard and add their thoughts to the group decision.
• Communicates clearly-- excellent written documentation for spikes/designs/decisions is a clear stand out here. (easy win with high visibility)
• Can start to participate in meta/scope and product type conversations around "hey this is stupidly hard why don't we just do this slightly different thing that's way easier" (extra credit at this level)

How to show this when interviewing vs getting promoted is different.

I'm dealing with a new service written by someone who extensively cut and pasted from ChatGPT, got it to "almost done -- just needs all the operational excellence type stuff to put it into production", and left the project.

Honestly we should have just scrapped it and rewritten it. It's barely coherent and filled with basic bugs that have wasted so much time.

I feel maybe this style of sloppy coding workflow is better suited to front end coding or a simple CRUD API for saving state, where you can immediately see if something works as intended, than backend services that have to handle common sense business logic like "don't explode if there is no inventory" and etc.

For this dev, I think he was new to the language and got in a tight feedback loop of hacking together stuff with ChatGPT without trying to really understand each line of code. I think he didn't learn as much as if he would have applied himself to reading library and language documentation, and so is still a weak dev. Even though we gave him an opportunity to grow with a small green field service and several months to write it.

NASA has a paper on how to not poop for days. It's on the Internet. Before space toilets there was only a space bag with finger scissor/scoop holes. It didn't work, poop got everywhere. The paper goes into detail about fecal matter being everywhere after early multi-day missions.

So they figured it out. Their system works -- I've also had my own reasons.