181–190 of 401 posts
Earlier quoted context omitted.
And then you’ve got a third problem - that well north of 50% believe themselves to be in that last sentence of yours
It seems that way sometimes but maybe we're just biased as we tend to hang out among intelligentsia
I like fixing code made by AIs and others (outsourcing code is similar as someone else said already). Last week we found out some client tried to vibe some departmental tool; the result is some massive crap in nextjs that needs 10GB mem to compile, has 1000s of lint errors, dev logs in git (very noisy ones) and so on. Now we have to fix it: its basically free 10k-50k euros over and over again for this type of work. V…
Did you use AI to rewrite it?
This is such a low value article lol I'm not even sure what it's trying to say. It's just someone patting themselves on the back.
tl;dr: "Slow down and think about what you're doing when using an LLM." Saved you five minutes. I was expecting a lot more, or a worked example, or _something_ to that effect. 90% of the text is the author complaining and defining the problem, then a hand-wavy vague solution is presented in the penultimate paragraph. Barely relevant or useful, really.
There's a big difference between the two and LLMs are increasing the chasm. The Software devs are crying out because the LLMs can already do their full job. Software engineers are happy because the LLMs are removing a large chunk of the job that's low value.
Software dev using an LLM is gonna produce "slop"
Software engineer using an LLM is going to have an increase in productivity depending on how they're using the LLM tools.
This is such a low value article lol I'm not even sure what it's trying to say. It's just someone patting themselves on the back.
tl;dr: "Slow down and think about what you're doing when using an LLM." Saved you five minutes. I was expecting a lot more, or a worked example, or _something_ to that effect. 90% of the text is the author complaining and defining the problem, then a hand-wavy vague solution is presented in the penultimate paragraph. Barely relevant or useful, really.
I've met a handful of people across my life that i'd call truly brilliant. Like, holy heck how in the world is this person this smart? Two things I've noted about really smart people are (usually mutually exclusively) 1) Sometimes they do not realize how smart they are, because it's simple to them, or because they know the subject they assume everyone else, say with a computer science degree, knows and recalls and un…
> Imagine walking through life and everything is clear, obvious, easy to process and having to watch humanity make stupid choices over and over and over again when the answers have been long known... I don’t claim to be book smart or have a high IQ or whatever but I feel this way about small things that I feel are common sense. It’s maddening to me to watch people fumble around. Or do X when obviously it will result…
Just the other day I was watching a video on youtube, of someone absolutely struggling at a task that had a built-in checklist, verification steps, pictures, and basically (in my opinion) perfect guidance. This is something where, if I was doing it, I would just... do the steps. in order. and it would work, probably... 99.9% of the time, the first time, and relatively quickly, to boot.
I watched them fail to succeed like... 5 times in a row. At no point did they actually complete all the steps and verification in order. And this was a reasonable, intelligent, thoughtful, thorough person. They just could not follow a checklist, visual or written instructions, probably to literally save their life.
I kind of envy people who need to clean up after others. At least you're puzzling. My current job is genuinely just boring. It's tasks that are so simple, a junior could do it. But no, instead they needed a medior. I'm not saying I'm better than this, nor that no medior will pick it up. I just cannot push myself to care about the code this company makes. It's old, dusty and it serves no one of importance. These custo…
You are not alone. I was in this exact same position at MSFT and I put in my resignation. I am an L63 but the work I was doing, was something an L60-L61 could do and I frequently felt I was in one of those Bullshit jobs (courtesy of David Graeber). I was paid handsomely but once the sign on stock ran out, I saw that I was staying in the job just for security. I felt like one of those Hooli engineers who were sunbathi…
Earlier quoted context omitted.
Sounds like valid issues to me. Pristine software isn’t the objective of most businesses. Leaving as a problem for another day, if we’re lucky that day will come, for many businesses, products, and startups it doesn’t and the shoddy prototype usually isn’t to blame. I feel like SWE’s that make this gripe really need to step back and understand their role and the process for value creation. Because it’s certainly a pr…
It’s not about pristine software. Customers expect something that works. But changes will then be requested and the expectation is that the software will continue working. It’s hard to do that with janky code. If you have a good architecture and keep good code hygiene, then velocity is easy. Without that, everything will slow to a crawl.
You will never get the chance of "customers requesting changes" if you never ship.
The company with the janky code that shipped will. And they will iterate and get better - as described by your process.
I heard this kind of rockstar stories a lot from my friends but I never encountered one in real life. I worked in small and big companies and no one with allowed to use any obscure language or tooling. I count myself lucky.
You need a CTO to lay down the golden path.
If you're just starting to learn programming, people will tell you that maintainability is important, and they'll mention John Ousterhout's concept of the "tactical tornado" as an anti-pattern. The problem is that this approach implements features quickly but in a way that conflicts with the team's mental model, ultimately ruining the entire codebase. A lot of blog posts initially framed this as a problem. I agreed t…
I believe GNU Emacs was created in 1984 or 1985, and it's still going strong. I guess it's not easy to work on it due to the long history, but I understand it's been refactored as the developers went along.
Earlier quoted context omitted.
The day you implement the first edge case to your prototype you basically commit to using it forever or spending a lot of money to replace it.
Well, there's nothing as permanent as a temporary solution...
Heard it so many times.