My teammates hit the generate PR button. I'm not reading that, it's a summary of the changes that I am _already_ going to be looking at, wrapped in some flowery language about being "better architecture, cleaner code" etc.
So those PRs may as well not have a description at all as far as I'm concerned.
> so much easier to destroy things than it is to build them, so the builders are always at a distinct disadvantage
Tangentially related, there was a local property nearby that had these large, aesthetic trees in the yard. The house was sold, a developer cut them all and flipped the house for sale.
> For example the washing machine. You dont need real time information because you know how long it takes since you've done it 1000s of times and it beeps. All these things are just managed in our heads subconsciously.
Actually, this is one example of home automation that works very well. My washer will remind me that wash is ready to move to the dryer, and stops reminding me once the washer door opens.
It means that a) I don't have to put it on my mental reminders, b) it works very well with anybody else in the family that does a wash and _they_ forget to move it to the dryer.
A long time ago I was taking flight lessons and I was going through the takeoff checklist. I was going through each item, but my instructor had to remind me that I am not just reading the checklist - I need understand/verify each checklist item before moving on. Always stuck with me.
A few times a year I have to remind my co-workers that reading & understanding error messages is a critical part of being in the IT business. I'm not perfect in that regard, but the number of times the error message explaining exactly what's wrong and how to solve it is included in the screenshot they share is a little depressing.
> how do we get large text to scale at a lower rate than body text. It's great that the body text can scale up from 16px to 32px, but does heading text need to scale up from 32px to 64px? It's already huge. If you have any thoughts, please do let me know!
Android 14 has this in non-linear text scaling -
> To prevent large text elements on screen from scaling too large, the system applies a nonlinear scaling curve.
I wish Android apps were better citizens when it comes to accessibility. My friend has very poor eyesight and I set his phone up to make things bigger for him, but most of the apps are a horrible janky mess of overlapping everything.
(Also "light mode" apps are painful for him to view, and most of the major apps have skipped out on offering dark mode)
I used to dread this approach (it’s part of why I like Typescript monorepos now), but LLMs are fantastic at translating most basic types/shapes between languages. Much less tedious to do this than several years ago.
Of course, it’s still a pretty rough and dirty way to do it. But it works for small/demo projects.
Each layer of your stack should have different types.
Never expose your storage/backend type. Whenever you do, any consumers (your UI, consumers of your API, whatever) will take dependencies on it in ways you will not expect or predict. It makes changes somewhere between miserable and impossible depending on the exact change you want to make.
A UI-specific type means you can refactor the backend, make whatever changes you want, and have it invisible to the UI. When the UI eventually needs to know, you can expose that in a safe way and then update the UI to process it.
This completely misses the point of what sharing types is about. The idea behind sharing types is not exposing your internal backend classes to the frontend. Sharing types is about sharing DTO definitions between the backend and the frontend. In other words, sharing the return types of your public API to ensure when you change a public API, you instantly see all affected frontend code that needs to be changed as well. No one is advocating for sharing internal representations.
