Last year I was trying out cars for a new purchase and was excited to try out the Subaru Outback. After one drive I decided I would never buy a Subaru because of their software. Lots of annoying noises, ugly, and no physical buttons. It was terrible.
Whether we like it or not, coding is now about how you can leverage Claude/OpenAI/Gemini to do the work for you. If you don't have these skills I would focus some effort there. Are you familiar with how to use agent skills, parallelizing agent work, creating plans, etc.?
With agents it is also much easier to build out some hobby projects. These can look great on a resume and provide some talking points in an interview. Worth looking through the Who's Hiring posts here on HN to see what employers are currently looking for and try to tailor your submissions towards these needs.
We're building https://brooked.io/. In the same way that Cursor provides a lot of features on top of the base agents, we want to do the same for spreadsheets. There are many workflows that benefit from having an agent available - resolving cell values from a prompt, writing functions, sheet insights, alerting, debugging.
Anecdotal, but I'm extremely disappointed with my Hyundai Tucson purchase. It's the first car I've owned. The drive train is gone on it and the mechanic says it's a common issue. Only 140k on it, 2019. It's hard to believe I paid so much for it and got so little use.
I’ve reviewed stacked PRs a couple of times and found it pretty terrible. The only one that ends up making any sense is the first. Better off with either just one single big PR, or don’t ask anyone to look at the next PR until the first one is merged.
Disagree. Gukesh was constantly putting pressure on Ding to find defensive moves and Ding finally made a mistake. The fact that it happened when it did just makes it even more dramatic. We know from the other matches that Ding is capable of finding them, and the fact that he didn't just highlights that they're both human, both under extreme pressure and that it's not just mindless computation.
Can a bear be blamed for murder? Somewhere in between the two is where AI models currently are, and they’re going to continue getting closer to the bear scenario.
Second this. Libraries like Material UI are battle tested and cover the vast majority of components you’re going to need. You can extend or theme them to match your needs and often include a built in design system. The likelihood of building something better from scratch are low.
It’s interesting to read comment threads of people that are dead set against Typescript. It’s a tool that has very few downsides and that improves nearly every single line of code you write. Either they’re scared to learn something new, not willing to take the time, or misunderstanding how useful it is. For anyone reading these comments and agreeing with Typescript naysayers, I would think more about why the commenter and yourself feel that way. You’re putting yourself at a big disadvantage.
Seems like the gases are getting compressed either way and it's just different ways of wording the same effect. As for it being reversible or not, is it not just a matter of whether the energy was actually transferred somewhere? Like you could technically undo the shock the same as you could depressurise air in a pump no? I don't really know what I'm talking about though, fyi.
There are a some things in your comment that give me the impression that your opinions are too strong for your experience.
99% of codebases are bad. It’s the baseline condition. It’s our job everyday to slowly make them better.
I’m extremely picky about what comments are allowed to make it into the codebase since the majority of comments I see are wrong, outdated, obvious and riddled with typos.
I think it’s very easy to complain about bad code when really the best thing to do is just suck it up and fix things.
Realizing that external dependencies are regular codebases just like the one you're working on. That you can open them up in VSCode, look around and figure out any bugs or issues you're having and even open pull requests to improve them.
At that point, you lose the feeling that there are magic things out there that you will never understand and that for the most part everything is just regular old code that regular people wrote.
I think it's a good point and something I find myself worrying about as well. The hype around GraphQL and Apollo, for example, made me feel that I was losing serious time developing a REST APIs until I finally committed and decided to use it on a project. Obviously there ended up being a lot of trade-offs but in the end it was hard to tell if I saved any time at all. More generally, after falling for this a couple times of I realized that often you're just pushing problems around to different parts of the stack, or hiding complexity in places you'll eventually need to uncover. My experience says that the time consuming parts of building a product are rarely solved by adding flashy new services and libraries, and so I try to worry about these things less. On the other hand, trying out new stuff even just for an hour or two can give you a lot of insight into how much time it's actually going to save you - so worse case you just take it for a test run and see what it's actually all about.
Agreed! I got back into piano at the beginning of quarantine and it's been really interesting for learning how I learn. As you said, to make any level of progress on new pieces I need to break it up in to short 20 min exercises interleaved with breaks. My ability to motivate myself and to retain anything is also directly correlated with the amount of sleep I get. Going to check out your book recommendations as well!