Tag programming
24 bookmarks have this tag.
24 bookmarks have this tag.
https://lobste.rs/~emk wrote:
Similarly it can make bad code that looks really good.
I think the thing that bothers me the most is that LLMs have changed the relative price of quality.
Imagine this in terms of houses: Before, a shitty McMansion with a leaky roof and bad foundation cost 1000X. A really good house with no lurking headaches cost 2000X.
Now with LLM technology, a skilled practitioner could hypothetically reduce the price of the good house to 1500X, by having it do some of the more mechanical and easily verified construction tasks.
But the shitty McMansion? That has now dropped in price to 100X.
And so the shitty McMansions are likely to drive out the quality work in ugly ways. I don't like this at all. Personally, I'm not going to hassle the craftspeople who reduce the price of the good house from 2000X to 1500X. But I don't see what prevents the crappy 100X houses from driving anything better out of the market, creating a "lemon market", and causing customers to become much more suspicious about software in general. Lemon markets are ugly, for the reason you described: buyers have no way to distinguish quality from garbage. In software, the most famous example of a lemon market was the great video game crash of 1983, where a wave of absolute garbage video games burnt a huge number of customers and made them stop buying.
In other words, revisiting the code you've already written and making it more concise could improve its readability (and also why code review is a thing).
This also aligns with the "Writing code that is easy for others to read" chapter in the Programmer's Brain book.
Good code examples with screenshots showing what the UI looks like. Apple's documentation usually lacks screenshots showing what particular SwiftUI components look like or how they function – it's up to third-party developers to provide this information.
Just a simple demo of transforming one iOS app design to another where upon using an app we try to ask to the following questions:
- Where am I?
The app should make it clear right away, so Im not left wondering where I am or how I got here
- What can I do?
I shouldn't have to guess – actions should be clear and easy to understand
- Where can I go?
A clear sense of next steps to keep the flow going and helps me avoid hesitation or second-guessing
I wish some professional software answered those questions. As well as mine, really. Should rewatch it from time to time.
And some talk about SQL and relational models.
“Structuring your theory into a story makes it more compelling.”
The latter consequence of low expectations is the more serious one. It's something that some people may never recover from. The average career of a paramedic is 6-8 years because of the physical and psychological strain the job puts on a person. The career of a physiotherapist is about the same, mainly because they become someone's personal psychologist 8 times a day while treating back pain or a sore knee. The trajectory of a data or software engineer seems to be a bit different: they burn out from the mental stress of working in dishonest and fraudulent cultures that produce unsatisfying work, but the engineer stays in the profession. Only they're a shell of a human. How many developers or programmers do you know who are a little sad all the time? I wonder what caused them to be like that.
So much of building tech stuff is a figurative conversation - between you and the machine, you and the abstraction, you and the people who will use what you build, you and the people who will maintain it, you and those who came before you. To understand such a varied audience you need to anchor on your understanding of yourself. Improve the one tool you can never replace - you.