this post was submitted on 29 Nov 2024
122 points (80.5% liked)

Technology

60116 readers
3324 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] 6 points 4 weeks ago (1 children)

And that's actually part of the problem: your title doesn't mean anything.

Not that you're not leading, but what "lead" or "senior" actually means is completely arbitrary.

In one project I'm lead in, I wrote maybe 5 lines of actual code, because I was in meetings, wrote documentation, did release management (well, I wrote pipelines here, but that's like 200 lines), etc. The actual leg work was done by 4 or five other guys.

But in another project, I'm lead of myself and another bloke, of course I'm writing code in that one.

So it's completely possible to have a bunch of guys with the "developer" tag on their title, but they're not doing much developing.

[โ€“] [email protected] 1 points 4 weeks ago

I wrote pipelines

We have devOPs for that.

Release management for our devs is tagging repos (automated), making a few PRs (mostly automated), and informing other dev teams of the release. Product owners update their docs, support updates theirs, and project manager coordinates everything.

My involvement in the release is limited to actual dev tasks, as in tracking down logs if there's a bug or something during deployment. Total time for a release deploy (my end) is about an hour, two if things go poorly. We release 5-10 repos in a typical release, so it's not small.

We don't have the same team doing every release, we take turns. So I'll do a release about once a month (usually a release release then one or two hotfix releases), and we do a major release every month (we're doing #12 next week). Most of the release process is on our QA team, not devs.

If you have "developers" who aren't developing, you've hired the wrong people IMO. Here are some support roles we have:

  • architecture - currently two people; they give initial estimates to product team
  • QA - they do development, but only on tests (role = "QA engineer")
  • scrum master - no development, just tracking (releases, features, etc); they're the ones product and support talk to about capacity
  • project manager - cross team communication with scrum masters and product team

As a lead dev (we have one per team), I step in to keep projects on track, provide estimates, and help prioritize tech debt. If I'm available (I usually am), I'll take feature work, and I produce code at about half capacity vs our regular devs (i.e. non-junior). Our releases are usually on-time (within a week or two on a 2-3 month estimate), so I think our setup works pretty well.

When I worked at a smaller company (one dev team, no project manager or scrum master), we didn't hit targets as well, and I did even less "admin" work (my boss was the CEO and he handled everything... poorly). We had a QA team, but the devs wrote the tests instead of the QAs, which we started on after handing the release to QA for verification (took 1-2 weeks due to long term tests).

So on both ends of that spectrum, I did a lot of development as a lead. I do less now than my last role, but I still spent about half or more of my time writing code.