You've never had a manager or product person take estimates, even clearly communicated as low confidence or rife with unknowns, as gospel truth? Lucky you.
Engineer: “It will take me two days [of work].” Sales:”We will have your fix ready in three calendar days [today + 2].”
Actual work that week gives employee 3 hours of non-meeting time, each daily meeting adds 0.5 hours of high-urgency administrative work. Friday’s we have a mandatory all-hands town halls…
Repeat that cycle for every customer facing issue, every demo facing issue, and internal political issue and you quickly drive deep frustrations and back talking.
I think there’s a fundamental truth: no one in their right minds, not even motivated engineers, actually hears anything but calendar when getting “days” estimates. It’s a terrible misrepresentation almost all the time, and engineers do a disservice when they yield to pressure to deliver them outside the broader planning process.
Project schedules should be the only place that time commitments come from, since they’re informed with necessary resource availability.
QA and SDET has been gutted as a role more or less industry-wide over the past 10-15 years. Nobody in charge cares about quality. Devs doing their own QA is like Boeing doing its own FAA certifications. Even with the best of intentions it's a setup for failure.
Yeah a lot of QA teams weren't the best, but the solution isn't to get rid of them it's to hold them accountable and improve them. But that takes effort and costs money, easier to just cut them and shift more responsibilities onto devs. The results are predictable.
Resources or the care, tbh. FOSS is a big umbrella and a lot of it simply isn't meant for "customers". Some FOSS apps clearly are trying to build a user base, in which case yeah the points this post makes are worth thinking about.
But many other projects, perhaps the majority, that is not their goal. By devs for devs, and I don't think there is anything wrong with that.
Pleasing customers is incredibly difficult and a never-ending treadmill. If it's not the goal then it's not a failure.
If manufacturers in general were serious about improving efficiency they'd stop putting huge heavy wheels on everything, instead of chasing fractions of a percent with overcomplicated and failure-prone door handles.
Side bonus, smaller wheels with taller sidewall tires are more comfortable, less prone to damage, and the tires are cheaper and easier to replace, too!
Not everyone's ears are the same. MKBHD famously does not use Airpods because he can't get them to stay in. I have tried jogging a couple times with Airpods Pro and they pop out every time.
EarPods/AirPods designs assume that you have certain genetic feature on ears called antitragus that hugs the stem with two opposing wings. I looked mine in the mirrors and one of the wings is basically missing altogether, making it not "anti"-ing. Tim Cook visibly has a pair of bulbous ones.
I kind of have different ethnic background than MKBHD, so, it kind of makes me wonder how that design got the shape it got and how it stayed that way.
Me too, the hard part is showing that this slower, more methodical process is more valuable than the flashy, quick shallow approach. And it means I might have to chew on a problem for a bit before delivering anything, even a proposal or design much less a product. But for a longer time scale it does pay off.
Fortunately I've had a few good managers and business partners in my career that recognize the value, but it's far from universal and I sometimes have a hard time communicating it myself in the face of the common move fast agile culture that is so prevalent in most of tech.
Yes, I have also had to have many difficult conversations with managers over the years who were worried that I wasn't going to deliver. All I could do was reassure them that this was my process; it will start slowly but will then accelerate dramatically. Once they've seen it work it gets easier of course!
