Not every workout needs a number.
Some days the point is just to move, not to beat last week's pace or last week's weight.
Side projects are the same. Not everything you build has to grow into a business. Some things are worth making just because you wanted to make them.
Every toggle in your settings screen is a decision you didn't make.
Most users never open settings. Whatever the default is, that's your app for them.
Pick good defaults first. Add a setting only when real users keep asking for the other way.
Strength is weird. Week to week it feels like nothing is happening.
Then you look at what you were lifting three months ago and it's obvious.
Building apps works the same way. If you don't write down what you shipped, every week feels like you shipped nothing.
Airplane mode is the cheapest QA tool you have.
Five minutes offline before a release shows you spinners that never stop, buttons that silently do nothing, and a lot of "Something went wrong".
Offline isn't an edge case. It's an elevator, a train tunnel, a beach with one bar.
Hot take: "Bug fixes and performance improvements" is a wasted release note.
It's one of the few places people actually read about your app, right when they're deciding whether to open it again.
One honest line about what changed for them beats a template nobody believes.
iOS devs starting a new app today: do you support the previous iOS version, or go latest only?
Latest only means new APIs without availability checks everywhere. One version back means more people can install it.
Where do you draw the line?
The hardest part of working for yourself isn't starting. It's stopping.
There's always one more bug, one more message, one more thing that'll only take five minutes.
The work never ends on its own. You have to decide where the day does.
When a coding agent fixes the same bug for the third time and it keeps coming back, stop prompting.
By then the context is full of its own failed attempts, and it keeps building on them.
Ask it to write down what it learned, open a fresh session, paste that in. A clean start beats a fourth patch on top of three bad ones.
Asking for notification permission on first launch is wasting your only shot.
The user has no idea yet why your app would ever need to ping them, so they tap no. And on iOS that "no" is very hard to undo.
Ask right after they do the thing that makes a notification useful. Then the prompt explains itself.
Using Claude Code and Codex on the same repo? Don't keep two sets of instructions.
Write the rules once in a shared doc, and make each agent's own file a two-line pointer to it.
Otherwise they drift, and each agent ends up working on a slightly different project. How do you handle it?
I have discovered $50 amazon photo frames to be the PERFECT home display screen
They can be rooted, updated to run a modern browser, have WiFi and can be powered from USB
1280×800 resolution with a nice touch screen
I detailed how to hack these yourself in my latest video
https://t.co/QhIiKjlf9N
Rest days used to feel like lost days to me.
Then you learn the session is just the signal. The getting stronger happens after, while you're doing nothing.
Code is weirdly similar. The problem I close on Friday often looks obvious on Monday. Sunday is doing more work than it looks.
React Native tip: put a testID on every button and input, even if you don't have UI tests yet.
Tapping by visible text breaks the day you ship a second language. Tapping by coordinates breaks on the next layout change.
A stable ID survives both, and any test or agent driving the simulator can find it.
Most AI features don't need a chat box.
An empty text field asks users to figure out what the model can do. Most won't try.
One button that does one useful thing, at the right moment, beats an assistant that can do anything if you know how to ask.
Reviewing a big diff from a coding agent? Start with the test files, not the code.
If a test got weakened or deleted to make things pass, everything else in the diff is suspect.
What's the first thing you check when an agent hands you its work?
A trick for days you don't feel like training: commit to the warm-up only.
If you still want to leave after that, leave. No guilt.
Works on the task you've been avoiding all week too. Just open the file and write one line. Starting is the expensive part.
Before every iOS release, run the app once at the largest text size.
You don't need to dig through Settings. Xcode's Environment Overrides lets you crank Dynamic Type while debugging.
Clipped labels, buttons that wrap into two lines, a layout that scrolls sideways. Ten minutes, and it's always worth it.
Hot take: Expo Go is for day one, not for building your app.
The moment you touch anything native, it starts telling you things work that won't in the real build.
A development build is one setup, and then you're testing the actual app. Move early, not after the first weird bug.
Building alarms with AlarmKit? Pick the schedule type on purpose.
Fixed is an exact moment. It doesn't move when the user changes time zone.
Relative is a time of day with a recurrence. It follows the user's clock.
A wake-up alarm should be relative. Otherwise someone flies from Barcelona to New York and their 7:00 alarm rings at 1:00.