the smart Siri will need buy-in from developers. Devs will tell the system about nouns and verbs that their apps know about — the semantics of the app’s data model objects, and the actions users can take upon them. Additionally, using this structured data, apps will tell the system what the user is doing right now, thus providing the context that Siri can become aware of. It’s all built on top of the existing Intents and UserActivities that apps have already been using to integrate with Shortcuts, Spotlight, and a bunch of other bits of the system. But using those is optional, and even for an app that’s got a head start, the new supercharged versions will require extra work to adopt.

Gone are the days where an eager group of independent developers would adopt every new technology springing forth from Cupertino, just because. Look at VisionOS — Apple promised the next big thing, but there’s no market for software there. (Jeff Johnson reports that in the first three weeks he only sold 21 copies of the Vision Pro version of his popular Safari extension StopTheMadness.) Beyond that, it is increasingly clear that Apple does things that benefit Apple, and many of those things do not benefit developers.

1. First and foremost: measure early, measure often. It's been said so often and it still needs repeating. In fact, the more you know about performance the easier it can be to fall into the trap of not measuring enough. Measuring will show exactly where you need to focus your efforts. It will also tell you without question whether your work has actually lead to an improvement, and to what degree.2. The easiest way to make things go faster is to do less work. Use a more efficient algorithm, refactor code to eliminate unnecessary operations, move repeated work outside of loops. There are many flavours, but very often the biggest performance boosts are gained by simply solving the same problem through fewer instructions.3. Understand the performance characteristics of your system. Is your application CPU bound, GPU compute bound, memory bound? If you don't know this you could make the code ten times as fast without gaining a single ms because the system is still stuck waiting for a memory transfer. On the flip side, if you know your system is busy waiting for memory, perhaps you can move computations to this spot to leverage this free work? This is particularly important in shader optimizations (latency hiding).4. Solve a different problem! You can very often optimize your program by redefining your problem. Perhaps you are using the optimal algorithm for the problem as defined. But what does the end user really need? Often there are very similar but much easier problems which are equivalent for all practical purposes. Sometimes because the complexity lies in special cases which can be avoided or because there's a cheap approximation which gives sufficient accuracy. This happens especially often in graphics programming where the end goal is often to give an impression that you've calculated something.

Things that eat CPU: iterations, string operations. Things that waste CPU: lock contentions in multi-threaded environments, wait states.

Companies find it incredibly hard to reliably staff positions with hard-working generalists who operate autonomously and have high risk tolerances. This is not the modal employee, including at places which are justifiably proud of the skill/diligence/etc of their employees.

Startups are (by necessity) filled with generalists; big companies are filled with specialists. People underestimate how effective a generalist can be at things which are done by specialists. People underestimate how deep specialties can run. These are simultaneously true.

The hardest problem in B2C is distribution. The hardest problem in B2B is sales.

Your idea is not valuable, at all. All value is in the execution.

nobody serious will engage in contract review over an idea, and this will mark you as clueless.