this post was submitted on 25 Jan 2024
329 points (97.1% liked)

Asklemmy

43916 readers
1271 users here now

A loosely moderated place to ask open-ended questions

Search asklemmy πŸ”

If your post meets the following criteria, it's welcome here!

  1. Open-ended question
  2. Not offensive: at this point, we do not have the bandwidth to moderate overtly political discussions. Assume best intent and be excellent to each other.
  3. Not regarding using or support for Lemmy: context, see the list of support communities and tools for finding communities below
  4. Not ad nauseam inducing: please make sure it is a question that would be new to most members
  5. An actual topic of discussion

Looking for support?

Looking for a community?

~Icon~ ~by~ ~@Double_A@discuss.tchncs.de~

founded 5 years ago
MODERATORS
 

Every day there’s more big job cuts at tech and games companies. I’ve not seen anything explaining why they all seam to be at once like this. Is it coincidence or is there something driving all the job cuts?

you are viewing a single comment's thread
view the rest of the comments
[–] squirmy_wormy@lemmy.world 23 points 9 months ago (1 children)
[–] mozz@mbin.grits.dev 0 points 9 months ago (2 children)

Want to have a programming contest where speed is a factor?

I actually looked this up, and the studies seem to agree with you. That one says a 55% increase in speed, and another says 126%.

All I can really say is, I'd agree with the statement that a single 3-hour task isn't real representative of the actual overall speedup, and my experience has been that it can be a lot more than that. It can't replace the human who needs to understand the code and what needs to happen and what's going wrong when it's not working, but depending on what you're doing it can be a huge augmentation.

[–] MajorHavoc@programming.dev 19 points 9 months ago (2 children)

What you're missing is that 95% of programming projects fail, and it's never because the programmer didn't code fast enough.

Speed-up isn't why I have a team instead of being a solo act.

[–] rwhitisissle@lemmy.ml 12 points 9 months ago (1 children)

There's also the pure reality that, yeah, it's easier today to get a project off the ground than ever before, and AI is good at that, but you know what AI is absolute shit at? Modifying ludicrously cumbersome, undocumented, brutally hacked together legacy code and addressing technical debt - the two most common tasks of most actual software engineers.

[–] MajorHavoc@programming.dev 8 points 9 months ago* (last edited 9 months ago)

True.

Good thing most companies aren't stuck with ludicrously cumbersome, undocumented, brutally hacked together legacy code bases. /s

I can't even type that with a straight face.

the two most common tasks of most actual software engineers.

So true.

[–] mozz@mbin.grits.dev -5 points 9 months ago (1 children)
  1. Working with GPT actually helped me write better code, because it's more familiar with good patterns in unfamiliar languages and frameworks and can write idiomatically. It got me out of one-language-centric habits I hadn't known I had.

  2. Yes, it's 100% true that the person driving the AI needs to have good design sense of what they want the final system to look like, and still work well with their team. You can fuck it up faster if you can code faster, absolutely that's true.

  3. What you said, I know that. Do the people that run these companies know that?

[–] MajorHavoc@programming.dev 1 points 9 months ago

What you said, I know that. Do the people that run these companies know that?

Yeah. Exactly. They did the same to various degrees when web frameworks first hit the scene, and numerous other advancements before and after.

But as you said, the new tech genuinely does make us both faster and better.

It just doesn't fix the crap parts of the job that the CEOs always hope it will. (As someone else pointed out, it specifically doesn't magic wand away decades of technical debt, haha.)

[–] Ephera@lemmy.ml 2 points 9 months ago

I would say a 3-hour-task isn't representative in the other way around. When you tackle a 1000-hour task, you'll probably spend more than 1000 hours working out what the requirements even are. A significant portion of my workday are meetings, not coding.

And with a long-form task, you'll go back reading existing code much more often than writing new code, too.