My process, which probably wouldn't work with concurrent agents because I'm keeping an eye on it, is basically:
- "Read these files and write some documentation on how they work - put the documentation in the docs folder" (putting relevant files into the context and giving it something to refer to later on)
- "We need to make change X, give me some options on how to do it" (making it plan based on that context)
- "I like option 2 - but we also need to take account of Y - look at these other files and give me some more options" (make sure it hasn't missed anything important)
- "Revised option 4 is great - write a detailed to-do list in the docs/tasks folder" (I choose the actual design, instead of blindly accepting what it proposes)
- I read the to-do list and get it rewritten if there's anything I'm not happy with
- I clear the context window
- "Read the document in the docs folder and then this to-do list in the docs/tasks folder - then start on phase 1"
- I watch what it's doing and stop if it goes off on one (rare, because the context window should be almost empty)
- Once done, I give the git diffs a quick review - mainly the tests to make sure it's checking the right things
- Then I give it feedback and ask it to fix the bits I'm not happy with
- Finally commit, clear context and repeat until all phases are done
Most of the time this works really well.
Yesterday I gave it a deep task, that touched many aspects of the app. This was a Rails app with a comprehensive test suite - so it had lots of example code to read, plus it could give itself definite end points (they often don't know when to stop). I estimated it would take me 3-4 days for me complete the feature by hand. It made a right mess of the UI but it completed the task in about 6 hours, and I spent another 2 hours tidying it up and making it consistent with the visuals elsewhere (the logic and back-end code was fine).
So either my original estimate is way off, or it has saved me a good amount of time there.
They've hit the limits of iPhone sales - and upgrade cycles are slowing. Hardware products in general are "streaky" - ie. demand and sales drop in the period after a new product is released, so how often can you produce a new version and what happens if that new version isn't a hit?
Whereas subscriptions provide recurring revenue. And services, in general, can bring in more money without an equivalent increase in costs.
I recently read "Apple in China" and one of the things I hadn't realised is how many people at Apple came from IBM under Tim Cook's reign. What he's done for Apple is turn them into a predictable, consistent, revenue machine.
I agree it's not just React - I think a lot of people simply do not know what CSS can do nowadays.
I do like Tailwind (I guess it fits with how I think). But to make good use of it you _do_ need to know how CSS works (for example, using variant selectors for picking out child elements, using container queries instead of global breakpoints etc).
I remember writing a function to convert a string from snake case to camel case and calling it `humpify`. And another that would take a string and locate the constant with that name called `constantinople`.
But then, this is ruby and it's known for its unusual naming. Plus both also had sensible/boring aliases and they were for internal use only.
(slightly off-topic) Many years ago, I got a puppy to keep my older dog company (it was as disaster as she was an over-excited nightmare and in the end I gave her to a friend, where she lived a happy life with two other over-excited dogs).
The older dog was sat on the stairs, sulking, as I played with the puppy (he was always very moody).
I showed her a squeaky ball; she liked the squeak so I tried to get her to bite it and make the sound. But she just wasn't getting it. Then the other dog charged down the stairs, stamped on the ball to make it squeak, then went back upstairs to continue his sulk.
But also privacy - it would be amazing to just be able to connect to any app or service you want, interact and react to stuff that's happening _over there_.
However, do you want any old app or service connecting to _your_ data, siphoning it and selling it on (and, at best, burying their use of your data in a huge terms of service document that no-one reads, at worst, lying about what they do with that information)? So you have to add access controls that are either intrusive and/or complex, or, more likely, just ignored. Then the provider gets sued for leaking data and we're in a situation where no-one dares open up.
My favourite way to use it is to write tests first, then say "make these pass". It will generate some code, run the tests, say "oh, there's an error here ... let's fix that ... oh, there's an error there, let's fix that ..." and (most of the time) it will reach a solution where the tests pass.
I already do TDD a lot of the time, and this way I can be sure that the actual requirements are covered by the tests. Whereas asking it to add tests to existing code often gets over-elaborate in areas that aren't important and misses cases for the vital stuff.
Sometimes, when asking Claude to pass existing tests, it comes up with better implementations than I would have done. Other times the implementation is awful, but I know I can use it, because the tests prove it works. And then I (or Claude) can refactor with confidence later.
People often mix marketing and sales. For me marketing is about "understanding your market". You wanted an iPhone because His Steveness knew what many people were looking for in a phone.
(The other parts of marketing, IMO, are getting the right message across at the right time - to those right people. The storytelling is the message part).
You missed the other horror of modern marketing. Using the thing sold to you, that you paid for, to trap you in endless marketing hell.
I don't mean using it, eg to visit a social media site or whatever. I mean, the device spamming you with ads and "helpful hints' about more products to buy.
Like Google and Android not shutting up about Gemini, nagging you to try it. Or dark patterns to trick you into subscribing to a service.
Right. Yeah I often do, possibly because I only have one word (marketing) for both.
I guess the storytelling is the part that I feel is overvalued. "This genius changed the world because of how he phrased it" seems like bullshit to me.
The part where you define what a good product is, this one matters. Even though I feel like there is a whole lot more luck involved than what people want to think. "Steve Jobs was a genius" may rather be "Steve Jobs was really good, and at the same time he was lucky that what he considered a good product at the time was actually perceived as a good product by the masses".
It feels like there is a lot of survivorship bias (let me link xkcd myself before someone does: [1]) that we keep ignoring. "If Musk/Besos/Zuckerberg/<name your crazy billionaire> is where he is, that's most likely because he is the best". Ok, they probably did something right (maybe?), but they got crazy lucky as well.
> The part where you define what a good product is, this one matters
From the article "It was the story of the product. And it drove what we built."
The story is what kept the product development on track - and thus made the iPhone sell itself - the story isn't about convincing the public to buy, the story was an encapsulation of the products design - refined as time went on.
Product dev can easily go off the rails - take the recent story about Jeep having Ads popup on their infotainment systems - people wondering how anybody could think that's a good idea.
If you told a story about that product feature to your family and friends - you can be sure you'd get the 'puzzled look', and you'd remove it before the car ever shipped.
Apple doesn't really do a lot of classic sales. They have people with enterprise accounts and so forth but most of what they do to tell you about products and get people to write about them is fairly classic marketing.
But to your other point, sure. There is a saying about helping to make your luck, but, yes, there is also luck in just about any career or success.
> Steve Jobs was really good, and at the same time he was lucky that what he considered a good product at the time was actually perceived as a good product by the masses
Jobs did it multiple times, though. The iPhone no doubt overshadows everything else, but the Macintosh and iPod serve as evidence that he had a recipe for successful products.
There's a whole section in the article about experimenting with different positions and weights of the haptic feedback as the dial is moved and how to tie them in to the display on the control itself.
> But how about a dial that stops turning at the minimum and maximum
That, too, is mentioned in the article ("This means you can simulate different types of haptic feedback, like different detent strengths and hard stops.").
> and doesn't need you to take your eyes away from the road at all?
Also addressed in the article ("Showing three different data types in one dial is possible but definitely the maximum. When adding a fourth function, keeping track of your position in the interface without looking down becomes too difficult.").
My process, which probably wouldn't work with concurrent agents because I'm keeping an eye on it, is basically:
- "Read these files and write some documentation on how they work - put the documentation in the docs folder" (putting relevant files into the context and giving it something to refer to later on)
- "We need to make change X, give me some options on how to do it" (making it plan based on that context)
- "I like option 2 - but we also need to take account of Y - look at these other files and give me some more options" (make sure it hasn't missed anything important)
- "Revised option 4 is great - write a detailed to-do list in the docs/tasks folder" (I choose the actual design, instead of blindly accepting what it proposes)
- I read the to-do list and get it rewritten if there's anything I'm not happy with
- I clear the context window
- "Read the document in the docs folder and then this to-do list in the docs/tasks folder - then start on phase 1"
- I watch what it's doing and stop if it goes off on one (rare, because the context window should be almost empty)
- Once done, I give the git diffs a quick review - mainly the tests to make sure it's checking the right things
- Then I give it feedback and ask it to fix the bits I'm not happy with
- Finally commit, clear context and repeat until all phases are done
Most of the time this works really well.
Yesterday I gave it a deep task, that touched many aspects of the app. This was a Rails app with a comprehensive test suite - so it had lots of example code to read, plus it could give itself definite end points (they often don't know when to stop). I estimated it would take me 3-4 days for me complete the feature by hand. It made a right mess of the UI but it completed the task in about 6 hours, and I spent another 2 hours tidying it up and making it consistent with the visuals elsewhere (the logic and back-end code was fine).
So either my original estimate is way off, or it has saved me a good amount of time there.
reply