I disagree with you, as it seems you tend to prioritize graphic design while overlooking other important aspects.
Personally, I find this idea alone to be very creative. Isn't a great designer someone who weaves together countless mediocre ideas to form a truly creative concept?
> Python doesn't require a requirements.txt file, but if you don't maintain this file, or neglect to provide one, it could result in broken functionalities - an unfortunate circumstance for a scripting language.
I can imagine that those who prefer a hands-on approach might spend more time understanding the problem, as they need to read through the code and debug to identify what is wrong.
It depends. For small tasks like summarization or self-contained code snippets, it’s really good—like figuring out how to inspect a binary executable on Linux, or designing a ranking algorithm for different search patterns. If you only want average performance or don’t care much about the details, it can produce reasonable results without much oversight.
But for larger tasks—say, around 2,000 lines of code—it often fails in a lot of small ways. It tends to generate a lot of dead code after multiple iterations, and might repeatedly fail on issues you thought were easy to fix. Mentally, it can get exhausting, and you might end up rewriting most of it yourself. I think people are just tired of how much we expect LLMs to deliver, only for them to fail us in unexpected ways. The LLM is good, but we really need to push to understand its limitations.
The long screen time is the main cause. The perfect glasses, light, or monitors might make you feel better in the short term, but the same environment and low activity might still lead to eye strain. I have been struggling with eye strain for a long time. The best practice I’ve found is to leave the desk and go out for a walk. I have even built an app[1] to help with that.
> Distributed locking is still really hard for some reason
I think distributed locking is hard because it only offers certain properties and requires that the application work together to achieve consistency, just like what you said about DynamoDB:
> DynamoDB is a good database (IFF your workload lines up with what it's offering)
I don't wear any glasses, but I still suffer from eye strain, especially from when I started my software engineering work years ago. I have also tried a lot of devices and medicines, but working long hours is just not good, and taking breaks is very important. So, I have even developed a macOS app to remind myself to take breaks. It is available on the Mac App Store now https://apps.apple.com/us/app/totalpause/id6482185943?mt=12, I hope it helps.
Go's error handling is not explicit because error is an interface. So, a nil MyError is not the same as a nil error, and error comparison is inconvenient because the interface constraints are so loose that people often resort to checking errors with strings.Contains.
Swift still lacks some concurrency features, even with Swift 6, but it's nice to see that atomic operations have finally been added. Besides that, I often encounter an error without knowing why: 'Failed to produce diagnostic for expression; please submit a bug report.'
I have to disagree; average is not a good way to measure. I have written approximately 6,000 lines of code (including empty lines but excluding some generated code) over the past few weeks. Yes, I write design documents before coding, and most of the code is completed within a few days. I definitely spend a lot of time debugging, but almost all of those activities have been constrained to code. Test cases are very helpful in making the process clean. I use Neovim inside iTerm2, so all those activities are done within terminal. By maximizing productivity through the use of the keyboard, I can eliminate many dependencies, such as the mouse and multiple displays. I believe dependencies are a source of distractions.
Most importantly, writing helps thinking. When I am stuck, I just write random comments (which I delete later) in the editor to help me think.