Auf YouTube findest du die angesagtesten Videos und Tracks. Außerdem kannst du eigene Inhalte hochladen und mit Freunden oder gleich der ganzen Welt teilen.
Eh, I’m a lead and I write at least a couple hundred lines most weeks, though some weeks I’ll write nothing because I’m in meetings or prepping a project (lots of estimates). But even if I’m mostly doing prep, I’ll still usually take some tech debt because estimating all week sucks, and I can knock out a couple hundred lines of tech debt fixes in an afternoon.
So I don’t buy it. We fired two leads before because they didn’t do actual development, one just wrote proposals (no movement on implementation) and the other just did tech debt. I do a mix of feature work, planning, and tech debt, and I think that’s how it should be. I oversee or do risky POCs and estimations, but other than that, I’m a regular dev. Oh, I also do reports because I’m also a manager, so midyear and EOY are pretty unproductive from a dev perspective for me.
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.
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.
Eh, I’m a lead and I write at least a couple hundred lines most weeks, though some weeks I’ll write nothing because I’m in meetings or prepping a project (lots of estimates). But even if I’m mostly doing prep, I’ll still usually take some tech debt because estimating all week sucks, and I can knock out a couple hundred lines of tech debt fixes in an afternoon.
So I don’t buy it. We fired two leads before because they didn’t do actual development, one just wrote proposals (no movement on implementation) and the other just did tech debt. I do a mix of feature work, planning, and tech debt, and I think that’s how it should be. I oversee or do risky POCs and estimations, but other than that, I’m a regular dev. Oh, I also do reports because I’m also a manager, so midyear and EOY are pretty unproductive from a dev perspective for me.
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.
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:
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.