shalmanese

That may be a theory but there's a much more mundane theory that explains the crunch of the last few years:

Tesla sold about 100,000 Model 3/Ys to Hertz for rental in 2021.

Hertz rented a ton of EVs to people who were only used to the acceleration curve of ICE cars.

A ton of those people unexpectedly crashed those cars [1].

This clogged up Tesla's repair channels and blew out the timeline for everyone else.

[1] https://edition.cnn.com/2024/01/18/business/why-do-people-ke...

It's a market for lemons but it's also an incredibly inefficient market for lemons. It's amazing just how much gold is randomly lying on the ground on the lemon market you can just occasionally pick up.

The classic story is some engineer who got picked up by a company when they were 22, did well and got promoted a few times and then runs into a terrible boss that makes their tenure untenable at 29 and goes out onto the market any interviews exactly like a 22 year old again by just shooting off random resumes from LinkedIn. I've had to slap so many of my tech friends on the head and be like, no, look, there's a so much more pleasant path you can now go down.

But like, why wouldn't it be that way? The median number of hours any engineer spends thinking about how to get hired in any one year is zero, there's an extreme minority who love the system and think about it all the time and they all talk to each other so they think everyone else is an idiot but the majority of good engineers spent most of their time getting good at engineering, not being hired.

I have an alternative theory which I call the "5th most important problem syndrome". At any company/department/team/individual, we have all the aspirations in the world but we really only have the bandwidth to work on our 1st & 2nd and maaaaybe 3rd most important problems. Getting better at hiring usually slots somewhere around the 5th most important problem which is a dangerous space to be because we oh so aspirationally want to get around to it this quarter but life inconveniently gets in the way so it gets pushed onto the backburner where it will forever be the 5th most important problem.

Startups have to be super careful to make sure they're not solving the 5th most important problem in their user's lives because the initial feedback will be overwhelming that this is definitely one of the top 10 most important problems the company/user faces and everyone is gung ho about fixing it but every time it's time to make forward progress, some "unexpected" emergency appears that derails the project.

Working on technical debt is a classic 5th most important problem which is why it's a perennial topic for debate in engineering circles. Startups that aim to optimize your cloud cost, IMHO, also run into this quite a bit. I've seen so many of them come and go throughout the years and my conversations with them tend to all follow this same trajectory.

I've found the opposite. When users feel like a lot of work has gone into something, they'll restrict their critiques to minor elements that seem easy to change because they are worried about causing you too much rework. Putting it in a sketch format makes it seem like it was easy to generate and gives them much more freedom to make more radical suggestions.

The key though is you also have to present them at least 2 - 3 very radically different versions of the same thing.

Each tool has a different purpose at different parts of the design stage. When I'm in blue sky ideation phase, I don't want users to be thinking about colors and proximity (although I do, even at that stage, care deeply about information hierarchy and hate sketch tools that make information heirarchy hard to design for). It's when I'm more in the narrowing down stage that I'll move to more higher fidelity tools.

A lot of the good blog posts were invested in during the ZIRP era because it was viewed as a differentiated hiring tool. Now that the supply/demand curve has totally shifted, we might see a drought of great new corp blogs for a while.

That may be your opinion but we have plenty of social media conversations about it when the voice first came out 7 months ago, before any of this was a controversy, and the only two names that are consistently brought up are Scarlett Johansson and Rashida Jones for who the voice reminds them of.

> But if everyone confirms his bad decisions instead of pointing flaws out, then they are all part of the problem.

They are part of the problem but they don’t have to be part of the solution. It’s the CTOs job to realize they’re not getting accurate information from below and work to fix it, that’s why they’re getting paid the big bucks. It’s not like it’s especially hard to figure out but building the trust to create an atmosphere of psychological safety is the job of executives and takes a lot of hard internal reflection but that’s what you sign up to when you sign up to do the job.

Doesn't take much digging to figure out that Gunter Kuhnle has been funded by Mars Inc [1] and Peter Rogers has been funded by Sugar Nutrition UK (fka: British Sugar Bureau) [2][3] and their names appear all the time in the popular press always defending the interests of big food.

Remember, a lot of the big food people came from big tobacco once the government started cracking down and they're just running the same playbook.

[1] https://www.linkedin.com/posts/gunter-kuhnle-13aba0171_a-who...

[2] https://www.bristol.ac.uk/people/person/Peter-Rogers-be40b6c...

[3] https://www.independent.co.uk/news/science/study-that-said-d...

A junior fat fingers a command line and accidentally deletes prod. Do you

a) Immediately fire the junior, yell a bunch and send company wide messages that anyone else making the same mistake will face the same consequences

b) Do a retro, figure out process changes that can avoid the same mistake happening again and thank the junior for discovering a flaw in our processes that leave room for improvement?

Five million will drive you un poco loco, my fine feathered friend.

I don't expect anything from the conference organizers apart from what's typically given. My point is, I despise presentations that could have been a Youtube, if you're going to give a presentation, make the experience unique to the people in the room, view the prepared sections as just enough to kickstart your intended impromptu part. This is a skill in and of itself and you just need to practice it to get better but most people aren't aware/don't try and I view it as a massive missed opportunity.

Hard disagree, the point of the talk is the Q&A, otherwise I can just watch it on YouTube. I design my talks so the rehearsed content is only the preamble. The rest of the time is spent in discussion. For an allocated amount of time, I create a talk that is 1/3rd the time and then supplemental material that can fill another 1/2 if the crowd can’t be warmed up.

But there’s an art to Q&A that’s as hard as public speaking but practiced by 1/10th the people. A simple hand vote is the most basic tool. After a Q, I’ll summarize it and ask how many people face this problem? Etc. why get an audience of people in a room if you don’t use them?

I think the biggest hump to get over for software engineers is that the physical world doesn't have the same kind of abstractions because of the inconvenient realities of real materials. Software engineers have the luxury of playing around in purely constructed environments where a lot of the complexity is accidental complexity (like CSS frameworks or how email delivery is a mess due to long legacy) but there's some pure abstraction lurking around in the background crowded by our imperfections as a species. A lot of software engineers pride themselves on the ability to glean out that hidden, pure abstraction.

You get smacked in the face over and over again moving into physical that the real world just doesn't work that way. You can take something as simple as a flat sheet of metal and there's a half dozen different processes to make it (hot roll, cold roll, cast, milled etc.) that each have different properties but there's nothing abstract underlying it.

Here's what I suggest you go: Buy two big totes and then go to a second hand store and buy an arrangement of the most random items ever (eg: a clock radio, a fork, a teapot, a book, a tv, a sweater etc). Break each item down into constituent components and put them all in Tote A.

Pick something random from Tote A that you're curious about and the hard bit is actually finding the noun of what the manufacturing process is (ie: injection moulding, Surface Mount Pick & Place etc.) to have made that thing.

The thing I really like after that is to go to youtube and find companies trying to sell machines/services using youtube as sales collateral (random example: https://www.youtube.com/watch?v=9uet6TNtUXI). They're talking about their process in the terms the customer cares about and it helps you get into the mindset of the customer about what's important in this manufacturing process.

Eventually, as stuff moves from Tote A to Tote B, get a 3rd Tote and move stuff to Tote C when you understand the upstream process as well. If you do this often enough, eventually you start seeing a "grammar" of the physical world. You can look at a thing and understand how it was probably built and why certain choices were made to accomodate the realities that not every single manufacturing process is as easy to pull off (vs in software, you delete one library and replace it with another and you don't really think about it) and you just need to know these things to make anything.

You can specialize down at any point in this process and inevitably will but I think the fascinating thing about starting general is that you eventually just start doing a mental teardown of any engineered product you encounter in the world and builds into a lifelong practice. You instantly spot the others who share the practice via all their little tells in the world and you find a secret club of people where membership is via geeking out about physical design.

> always seems to be some agile race to the bottom where we try to fix as little as possible as simply as possible.

Yeah, that's not agile. The entire point of agile is that you close the loop and the reason you break your work into smaller chunks is so you can deliver them faster in order to gauge the feedback of that chunk and better understand what should be delivered in the next chunk.

If you're not closing the loop, you're not doing agile, you're just doing waterfall with more bureaucracy.

I would argue the complete opposite. One of Michael Hobbes' persistant cri de couers is that the media is overwhelmingly only capable of covering the meta-conversation around the reactions to various claims and seem totally incapable and incurious about digging into the meat of the claims themselves, despite it being methodologically trivial to do so.

One of their most recent episodes was on the Claudine Gay plagiarism scandal where they systematically dug into every one of the 54 cases of plagiarism and demonstrated just how much of it was bad faith right wing bullshit that didn't stand up to even the slightest intellectual scrutiny. But the larger point they were making was not about the right, for which they expected intellectual dishonesty, but the complicity of the left & mainstream media in only ever talking about the scandal in terms of who is saying what about it and why and not on the meat of the facts on the ground.

They took the exact same approach to the lab leak episode where they said let's ignore all of the media meta-narrative and look at just the plain facts on the ground and they found that, like most things, it was a sandcastle built of air that collapsed when you even looked at it funny.

And all of them have far worse user experiences than the Apple Watch for that exact reason. The Apple Watch is a platform, not an app. It defines the type of communication iPhone and AW apps can have in ways that provide tightly integrated experiences.

Again, there exists a totally different hardware product Apple could build for Android that runs on Android OS expectations but it wouldn't be an Apple Watch.

Was there a more than 23% increase in risk due to climate change happening in a single year? 23% is an insane amount for insurance to grow on an annual basis!

I mean, the technical limitations are pretty obvious if you are even remotely familiar with the architecture. The watch offloads significant computation and communication to the phone in an extremely tightly integrated manner to have an acceptable computational and power consumption envelope.

I don't see how they could have done it without significant co-operation from the Android OS team far deeper than even two allied companies are typically able to communicate. The other alternative would have been to design a totally different piece of hardware that operates according to the Android OS expectations but that's hardly "bringing Apple Watch to Android".

I've always (n = 5) had good landlords and I think the key is selecting landlords that prioritize having good tenants over maximising rental yield. I've had the privilege of lots of external legible markers of success that make me appear as a "safe" candidate for lots of landlords.

2 of the 5 landlords lived in the same building where I lived alone and we became decently close over time and 3 of the 5 we rented the whole house but we were a group of grad students/working professionals that were an attractive demo.

As with anything on the internet, "This went mostly fine" is a perspective you rarely see so the prevalence of problems appears grossly exaggarated.

Placebos can sometimes have more harmful side effects than actual drugs: https://www.ox.ac.uk/news/science-blog/harmful-placebos

You bought that computer at the exact right time when the bulk of the industry talent went into trying to make mobile processors more power efficient rather than making desktop processors more powerful.

> all of a sudden it was the 4th century CE (i.e. about 1600-1700 years ago)

This, at least, narrows it down a bit.

One gamble he ultimately won.

How much would it have cost back then to buy a broken, used FP3 with a cracked screen as a donor phone?

People on both sides of the table have the common misconception that coding challenges are about solving the problem. They're not, coding challenges are there for me to gain an insight into how you think through problems and the questions you ask are 100x more important to me than the code you write.

I have a colleague who, every coding challenge, immediately started by writing a bunch of tests and asking questions around the edge cases so that he could clarify the exact specs of the task he was being asked to perform. Any interviewer who didn't roll with that was a sign to him that there probably wasn't an engineering maturity culture fit and helped eliminate a lot of companies.

The story he was trying to tell was that he was an engineer that considered understanding the problem to be a much more important task than understanding the solution and he managed to tell it via the way he approached whiteboard coding.

The absolutely low hangingest fruit, highest ROI activity I recommend every candidate do as they're gearing up for a job search is to meticulously go through their past work history month by month or even week by week and dredge up the memories of all the things they've actually done leading up to this point in their career and then find another person and do the physical act of explaining each of the things so they know if they can even tell the story in a way that makes sense or not.

The reason I believe it's the highest ROI activity is because I keep on suggesting it to people and most people think it's a great idea and then they don't do it. It's gotten to the point where, for the people I really care about, I have to schedule a 3 hour block with them on a weekend and sit down with them just to actually have them do it and after it happens, everyone agrees the result is transformative but people have a weirdly high activation friction to actually doing this.

It should get to the point where I can quiz you on a "tell me of an example where you X" and they should be able to rapid fire answer back to me what example they would pick and we can do a round of 30 of these in 10 minutes. If they find themselves having an esprit de l'escalier moment of wishing they had picked different examples, that's a sign they should go back and revise more.

I have so many friends who have done so many awesome things in their career but then freeze up in the interview and just plain forget to mention the perfect relevant anecdote and they think it's some defect on them but, surprise, all of our recall is terrible and we all constantly forget details of things that happened years ago and the only way to get good is with discipline and practice.

Another technique I encourage every candidate to master is the classic politician technique of transforming every question into the question you wished the interviewer had asked in a seamless enough way that they don't notice. eg: One of my close friends who I coached was absolutely terrible at hypothetical scenarios, she would totally freeze up because that's not how her brain worked. I trained her so that whenever an interviewer asked:

"How would you design this theoretical feature for this made up example"

Her templated reply would go something along the lines of:

"Oh yeah, we faced quite a similar problem when I was working on [...] at [...]. The way I approached it was [...] because [...] and it meant that [...] for [...] stakeholders. So I guess in this scenario, I would apply those same techniques [...] to make sure that [...] met [...]'s requirements.

At the end of the day, we're generally all in denial about how much interviews come down to vibes and how vibes is a very trainable skill that it's very possible to reduce the error rate through practice (note: this is different from presenting a different vibe from how you actually are IRL which I generally advise people is long term counter productive). Engineers especially have a lot of emotion invested in how interviews "should" be that isn't at all concordant with any version of reality and they have hangups about investing skillpoints in things that empirically improve their interview performance because it goes against their mental model of what should improve their interview performance.

> The guys who are trying to make Messenger an everything app are probably some random MBA grads who have done nothing of significance in their life and real world.

The head of Messenger when this happened was literally the ex-president of PayPal.

https://time.com/2850224/paypal-david-marcus-facebook-messen...

This feels like a wild misreading of the situation based on a simplistic good/bad dichotomy. People were mostly stunned at how poorly the board handled things and that sama probably wasn't as bad as the board was trying to make him out to be which is wildly different from him being good.

Even the worst criminal in the world should be declared "not guilty" if they were caught for a crime they did not commit for which the prosecution did not make a convincing case. In law, there no "innocent", only "not guilty" and most people surmised that sama is not guilty in this context irrelevant of a larger backstory.

I think OPs point was that this was sama finding the line of what was the most egregious thing that is acceptable to admit in public which is almost certainly not the most egregious thing he's done and could be a large part of the explaination of why people's opinion of him knowing certain private actions diverges so much from everyone else.

This has been tested by researchers: https://www.npr.org/2019/06/20/734141432/what-dropping-17-00...

If you haven't seen it yet, I highly recommend checking out the story of MyHouse.wad: https://www.youtube.com/watch?v=5wAo54DHDY0

If you want to go in spoiler free, I'd recommend downloading the WAD and playing it through blind. But if you don't have the time for that, there's a ton of great youtube videos that covered the topic.