231–240 of 630 posts
I am a software developer and mainly a programmer for decades now. I love programming. I love to be "once" with the computer. I will never give this joy up. If I need to sell shoes at daytime, I will program real computer programs in the evenings. If it won't be possible with modern machinery anymore, I will take my Commodore 64. I am a free man. Edit: Corrected since/for. :-)
Earlier quoted context omitted.
> If an LLM is typing that code - and it can maintain a test suite that shows everything works correctly - maybe we don't need that abstraction after all. I've had plenty of junior devs justify massive code bases of random scripts and 100+ line functions with the same logic. There's a reason senior devs almost always push back on this when it's encountered. Everything hinges on that "if". But you're baking a tautolog…
> "LLM as abstraction" might be a possible future, but it assumes LLMs are significantly more capable than a junior dev at managing a growing mess of complex code. Ignoring for a second they actually already are indeed, it doesn’t matter because the cost of rewriting the mess drops by an order of magnitude with each frontier model release. You won’t need good code because you’ll be throwing everything away all the ti…
What exhausts me isn’t “falling behind.” It’s watching the profession collectively decide that the solution to uncertainty is to pile abstraction on top of abstraction until no one can explain what’s actually happening anymore. This agentic arms race by C-suite know-nothings feels less like leverage and more like denial. We took a stochastic text generator, noticed it lies confidently, wipes entire databases and hard…
I think AI-assisted programming may be having the opposite effect, at least for me. I'm now incentivized to use less abstractions. Why do we code with React? It's because synchronizing state between a UI and a data model is difficult and it's easy to make mistakes, so it's worth paying the React complexity/page-weight tax in order for a "better developer experience" that allows us to build working, reliable software…
Does any of you bother the fact that now you have to pay money in order to do your job? I mean AI model subscriptions. Somehow it feels wrong for me to pay for tools that are trying to replace me.
Earlier quoted context omitted.
I hardly ever open an IDE anymore. I use Claude Code and Cursor. What I do: - use statically typed languages: TypeScript, Go, Rust, Python w/ types - Setup linters. For TS I have a bunch of custom lint rules (authored by AI) for common feedback that I've given. ( https://github.com/shepherdjerred/monorepo/tree/main/package... ) - For Cursor, lots of feedback on my desired style. https://github.com/shepherdjerred/scou…
> make at least 20 searches to online documentation Lol sometimes I have to spend two turns convincing Claude to use its goddamn search and look up the damn doc instead of trying to shoot from the hip for the fifth time. ChatGPT at least has forced search mode.
Earlier quoted context omitted.
The good ones don't accept. Sadly there's just many more idiots out there trying to make a quick buck
Delving a bit deeper... I've been wondering if the problem's related to the rise in H1B workers and contractors. These programmers have an extra incentive to avoid pushing back on c-suite/skip level decisions - staying out of in-office politics reduces the risk of deportation. I think companies with a higher % of engineers working with that incentive have a higher risk of losing market share in the long-term.
Earlier quoted context omitted.
> Why do we code with React? ...is a loaded question, with a complex and nuanced answer. Especially when you continue: > it's worth paying the React complexity/page-weight tax All right; then why do we code in React when a smaller alternative, such as Preact, exists, which solves the same problem, but for a much lower page-weight tax? Why do we code in React when a mechanism to synchronize data with tiny UI fragments…
Yeah, I share all of those questions. My cynical answer is that most web developers who learned their craftsin the last decade learned frontend React-first, and a lot of them genuinely don't have experience working without it. Which means hiring for a React team is easier. Which means learning React makes you more employable.
That's not cynical, that's the reality.
I do a lot of interviews and mentor juniors, and I can 100% confirm that.
And funny enough, React-only devs was a bigger problem 5 years ago.
Today the problem is developers who can *only* use Next.js. A lot can't use Vite+React or plain React, or whatever.
And about 50% of Ruby developers I interviewed from 2022-2024 were unable to code a FizzBuzz in Ruby without launching a whole Rails project.
Earlier quoted context omitted.
I think you may have misunderstood something here. When paying for Claude Max even at $200/month there are limits - you have a limit to the number of tokens you can use per five hour period, and if you run out of that you may have to wait an hour for the reset. You COULD instead use an API key and avoid that limit and reset, but that would end up costing you significantly more since the $200/month plan represents suc…
Thank you for the explanation, but I did fully understand that is what you were saying. What I don't fully understand is how you can characterize that as "not limited" with a straight face; then again, I can't see your face so maybe you weren't straight faced as you wrote it in the first place. Hopefully you could see my well meaning smile with the "absolutely right" opening, but apparently that's no longer common so…
That's why I said "not limited" as opposed to "unlimited" - a subtle difference in word choice, I'll give you that.
Earlier quoted context omitted.
For moment you an use `date-fns` and tree shake. I'd rather have LLMs build on top of proven, battle-tested production libraries than keep writing their own from scratch. You're going to fill up context with all of its re-invented wheels when it already knows how to use common options. Not to mention that testing things like this is hard . And why waste time (and context and complexity) for humans and LLMs trying to…
Every dependency carries a cost. You are effectively outsourcing part of the future maintenance of your project to an external team. This can often be a very solid bet, but it can also occasionally backfire if the library you chose falls out of date and is no longer maintained. For this reason I lean towards fewer dependencies, and have a high bar for when a dependency is worth adding to a project. I prefer a dozen w…