this post was submitted on 22 Dec 2024
506 points (96.2% liked)

Technology

60073 readers
2807 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 3 points 19 hours ago* (last edited 19 hours ago) (1 children)

Lmao your stance is really "every coworker makes all product lower quality by nature of existence"? Thats some hardcore Cope you're smoking.

[–] [email protected] 0 points 19 hours ago (1 children)

Every coworker has a specific type of task they do well and known limits you should pay attention to.

[–] [email protected] 2 points 18 hours ago (1 children)

Yes and therefor any two employees must never be allowed to speak to each other. You know, because it makes all of their work worse quality. /s

[–] [email protected] 1 points 1 hour ago

That's quite the extreme interpretation.

I'm a lead software dev, and when deadlines are close, I absolutely divvy up tasks based on ability. We're a webapp shop with 2D and 3D components, and I have the following on my team:

  • 2 BE devs with solid math experience
  • 1 senior BE without formal education, but lots of knowledge on frameworks
  • 1 junior fullstack that we hired as primarily backend (about 75/25 split)
  • 2 senior FE devs, one with a QA background
  • 2 mid level FEs who crank out code (but miss some edge cases)
  • 1 junior FE

That's across two teams, and one of the senior FEs is starting to take over the other team.

If we're at the start of development, I'll pair tasks between juniors and seniors so the juniors get more experience. When deadlines are close, I'll pair tasks with the most competent dev in that area and have the juniors provide support (write tests, fix tech debt, etc).

The same goes for AI. It's useful at the start of a project to understand the code and gen some boilerplate, but I'm going to leave it to the side when tricky bugs need to get fixed or we can't tolerate as many new bugs. AI is like a really motivated junior, it's quick to give answers but slow to check their accuracy.