Not the author, but I'm a VP of Eng, and one of my sub-orgs is QA. Here's my take...
Aside from writing end-to-end test automation, the best SDETs add value in many other ways. They triage bugs, use their deep product understanding (frequently the best on the team) to refine requirements and build test plans, coordinate bug-bashes and large scale releases, measure and report on quality metrics, and much more. All of this takes considerable load off other members of the team (SWEs, PMs, EMs, etc), allows the whole group to ship with much higher confidence, and increases the number of defects caught before making it to production.
If you have an organization where end-to-end tests are easy to write and very quick to execute, then I think the need for QA folks is greatly reduced. In my experience, once there's enough complexity and scale to a product, it's basically impossible to have a rapid TDD loop with enough end-to-end coverage that allows devs to ship features with perfect confidence. Combine that with all the other "hats" QA folks wear, and I think it's is a role that pays dividends in product quality and the efficiency of others across the org.
I think it’s a good takeaway for something that’s sold once on an app store. If it’s junk, the rankings will tank it, and it may never recover from that. There are a few instances of games that have turned things around after the initial launch, like “No Man’s Sky”, but that’s quite rare.
Take Half-Life as an example. The team realized it wasn’t great after multiple years of development, and ended up essentially rebuilding it over the course of another year or two. To quote Gabe Newell, “Late is just for a little while. Suck is forever.”
Your take is spot on for SaaS apps and enterprise software that’s subscription based: ship early, ship often, and iterate fast.
I recently learned about The Villages, FL, which is a sprawling retirement community, and was the fastest growing metro area in the US over the past decade [0]. This feels like the perfect bike for an aging demographic living in that sort of community. This sort of e-bike will be less intimidating to use for older people, and ultimately it feels like a good move for the company. It's hard to argue with getting more people outdoors and active on bicycles.
Unless I'm misunderstanding something, I see a possible issue with the experiment setup.
> The start-of-input was measured by pressing two keys at once -- one key on the keyboard and a button that was also connected to the logic analyzer.
In order to get an accurate measurement, wouldn't you need to directly connect the analyzer to circuitry on the underside of a specific key, as well as the USB output, and measure the diff? The article addresses this by mentioning it's only possible to get average latencies with their setup, but I wonder if this is why the keyboard with the shortest measured latency is also one with an extremely low travel distance.
It’s much more egregious with ABNB. A hotel might charge you some small local taxes and fees, but with ABNB you get those plus a whopper of a “cleaning fee”, which can be hundreds of dollars, even for short stays.
It should be fantastic for towing heavy stuff relatively short distances (less than 150 miles). Electric motors make 100% of their torque from 0 RPM. This is why freight trains are powered by electric motors, with diesel engines merely generating electricity.
FWIW I find Tesla’s all-touch infotainment and climate control awful to use. I think there are many like me, who prefer dedicated buttons and knobs for common functions.
Barry Lyndon was shot with an f/0.7 lens because Kubrick wanted period-correct lighting: candlelight, which required a super fast lens with the film used. To my knowledge he wasn’t going for shallow DoF.
I'm not super familiar on the subject, but are you sure the analogy holds?
If we build enough capacity to scrub more carbon from the atmosphere than we add each year, then the problem will taper off, no? In your analogy, we'd be moving money from the high rate card to a lower rate one, and also making more $$$ than we spend annually.
If we, through some miraculous circumstance, avoid making ourselves extinct, then maybe there's a small chance the crows won't overthrow us and take over.
Aside from writing end-to-end test automation, the best SDETs add value in many other ways. They triage bugs, use their deep product understanding (frequently the best on the team) to refine requirements and build test plans, coordinate bug-bashes and large scale releases, measure and report on quality metrics, and much more. All of this takes considerable load off other members of the team (SWEs, PMs, EMs, etc), allows the whole group to ship with much higher confidence, and increases the number of defects caught before making it to production.
If you have an organization where end-to-end tests are easy to write and very quick to execute, then I think the need for QA folks is greatly reduced. In my experience, once there's enough complexity and scale to a product, it's basically impossible to have a rapid TDD loop with enough end-to-end coverage that allows devs to ship features with perfect confidence. Combine that with all the other "hats" QA folks wear, and I think it's is a role that pays dividends in product quality and the efficiency of others across the org.