... but you have a staff that can come up with ideas, and now you can say yes to more of them.
"Infinite growth" framing is asking a lot, but for most of my career, I've seen teams, departments or companies solicit ideas of what to do next quarter/year/whatever, and really aggressively winnow it down -- in large part b/c there weren't enough people to do it (and we could only afford so many people).
And we were _bad_ at prioritizing; we'd often have like a list of multiple things declared P0 and a longer list of things called P1, and a stack of stuff that didn't make the cut to maybe revisit in the future.
But if the same number of people can build and ship and iterate faster, then why not do more?
You can say yes to more of them, _but they still need to be worth it._ If you have an infinite well of ideas to grow your business, awesome. But there are a lot of companies that just don't have those ideas, where their growth is limited on some other factor related to the market they're in.
I've never seen a roadmap planning process that didn't involve some component of asking departments and teams what needs to be done.
To the extent you have successful products, it's because you have product managers and engineers and data scientists and depending on the product, integration/forward deployed staff. These should be the people with a view to how the product needs to meet the needs of future customers, the challenges faced by existing customers, and the technical components needed to get there. I'm not saying you encourage them to just spitball ideas from ignorance, I'm saying you solicit their expertise on the limits and needs of your products, systems, tools, processes, messaging etc.
The personal computer, laptops, web browsers, cell phones, smartphones, AJAX/DHTML, digital cameras, SSDs, WiFi, LCD displays, LED lightbulbs. At some point, all of these things were "overhyped" and "didn't live up to the promise." And then they did.
I feel like the Ergodox was traditionally a lot of people's first wacky split keyboard -- but for those that stuck around, it was rarely their last. These days, there are so many better options that it's hard to recommend Ergodox despite its historic importance.
1. No pointless layer of "inner" keys that you never use
2. The thumb keys are closer to the main keyboard, so more of them are in a natural reach, rather than being a big stretch (this is the biggest one in usage)
3. Uses all 1u keys, so greater keycap compatibility (any ortho kit will work)
4. If you're comparing to the Ergodox EZ, construction is better, with a metal case instead of plastic
5. Takes up less desk space
And it's still QMK, still hotswappable, still has the columnar layout. I don't think the Ergodox offers anything over it.
Conversely, I'm totally sold on it. The shoulder-hunching thing is so real.
The thing I thought was ergonomic BS was the benefits of columnar/ortho layouts; everyone talked about how your fingers just moved vertically and it was so much better for them, and I rolled my eyes. But dang if it hasn't proved to be meaningfully true for me, too -- when I have to type on a legacy keyboard, I can clearly feel the pain in my fingers. (The disclaimer here is that my fingers are totally screwed up; if you don't feel pain normally, this probably matters less.)
I feel like the bigger issue is that Cruise evidently had an unsafe company culture (like Uber): It wasn't just that they had an incident, it's that they lied about the incident and tried to cover things up.
This has been a pretty consistent pattern -- Cruise was always less transparent about its safety data than Waymo, and its claims tended to be opaque and non-measurable, whereas Waymo was partnering with insurance companies to get hard data.
Waymo is going to have incidents, too, but I think they have made the (correct) decision that being open and transparent about safety stuff is the way they move past those; Cruise made a decision in the opposite direction, and it killed them.
I agree with that for programming, but not for writing. The stylistic tics are obtrusive and annoying, and make for bad writing. I think I'm sympathetic to the argument this piece is making, but I couldn't make myself slog through the LinkedIn-bot prose.
No. The Apple TV _service_ does, and you can configure that service to be some kind of weird god service if you want. But you can also treat that service like any other normal service, one that only comes up if you launch it. In that case, the home screen is just a straight icon grid with no kerfuffle.
I think he's really getting at something there. I've been thinking about this a lot (in the context of trying to understand the persistent-on-HN skepticism about LLMs), and the framing I came up with[1] is top-down vs. bottom-up dev styles, aka architecting code and then filling in implementations, vs. writing code and having architecture evolve.
reply