So you were a "star developer" at some previous workplaces, but now you're not, and just produce at a "mediocre grind"? Why is that? And why work there now and not that the previous places?
I suspect this is the common tale of poor compensation: despite being a star developer, employers won't pay for properly for this, just a mediocre annual raise, so you move on after a couple of years to another place, which offers you a huge raise (new starting salary compared to the previous job's salary). And the new place, while giving you a poor environment that hampers your productivity, still pays much better than the previous places where your productivity was much higher. And because of this common workplace dynamic, it's usually not worth it to put in much effort to be a star employee, unless you find the rare employer that actually rewards you for it. Is my guess correct?
My self observation is my performance is relative to how rushed I am to complete something. So I tend to perform much better at places that develop features on a 1-3 month cadence rather than somewhere that expects development progress to occur on a day/week basis. Even when the overall amount of time spent on development is the same.
I think having to show my unfinished work to people takes its toll on my confidence. I know it's crap because it's not finished, and I spend so much time talking about what's missing/poorly designed that I come away from demos thinking, "I just showed everyone how terrible I am at this."
My goal is always to be a star employee. Since I benefit from doing a great job just as much as my employers do.
>not worth it to put in much effort to be a star employee
it isn't even possible at the places like i'm currently in, at least for me. I mean, i'm still rated as high performing employee, just a regular one at that. You do your components in a very large platform product, make sure that they aren't source of pain, and just coast under the radar.
The difference between high performance in a trusted environment and high performance in an environment that lacks trust is significant. The problem isn't Jira - it's peer reviews and QA and gates to show both that the process is followed and that the quality is sufficient. The "high performer" is granted the trusted environment -- or at least the organization structures itself to minimize the pain to the "high performer."
So, someone can do the same amount of work but not achieve the same results because of the system.
So, then the logical answer is to throw the processes out! Get rid of Jira and PR and don't let quality block release! That works in a small environment, but the moment your company needs to generate SOC audits you will fail and you won't be able to sell. Or you will never be able to go public because your SOX auditor won't pass you. (And we won't even talk about PCI compliance!)
So, then, you end up in a push/pull. One of the part time jobs of management is monitoring the system and balancing the constraints. Here are some ways people have tried to balance the constraints:
* Pair programming. You reduce the theoretical output by 50%, but you fix that by putting QA and PR into the process. (You also have a feedback loop from two people reducing blocks and can stop interruptions by only interrupting half of the pair.)
* Mob programming. You reduct the theoretical output by 25% (assuming team of 4) but you drop QA and PR and you always have someone available to unblock. If you have a team of specializing generalists, you can always have the experience to solve the problem.
* Surgical team. You have a series of junior developers who support a staff engineer. In this model, the staff engineer figures out the hard parts and feeds the rest to a series of junior engineers. Junior engineers are also available to write tools and tests and qa. It seems like you have fewer people working on the key problems, but one person having it all in their head and unblocked continuously can compensate for the lack of theoretical output. (In this model, it is hard to hire seniors because one bad senior can tank the entire team.)
* Team of seniors. You still have the reduced output of the process, but since they work in a high trust environment, PRs can be glossed over and QAs are just there to cover the release management. (One new developer can slow everyone down until they're up to speed, and a bad performer can tank the whole team as it devolves into mistrust as processes have to be applied to all.)
* Hierarchical teams: A combination of seniors and juniors where the seniors take harder problems and juniors support seniors and take less complicated problems. mid-level are senior-light. These teams look like they're working closer to theoretical maximum but end up being slowed down by the processes of mistrust.
* Scrum Master/Project manager. For complex projects requiring a lot of interaction and a large number of people, take the money allotted to developers and give it to non-developers who take care of those parts. People complain about this here because it's often misapplied.
* Star Developer autonomy. For people who have proven themselves, the organization warps around them. It's like the surgical team, except these people are often tied to multiple teams. Instead, the other teams work being unblocked by these star developers or clean up the messes/maintain the work of the star developers after the fact.
All of these can be valuable. Some of them are not "agile." But the bigger the organization, the more difficult the problems get because they're problems of interaction and trust.
And none of them are about the amount of work, but rather the amount of perceived productivity by a given person.
I suspect this is the common tale of poor compensation: despite being a star developer, employers won't pay for properly for this, just a mediocre annual raise, so you move on after a couple of years to another place, which offers you a huge raise (new starting salary compared to the previous job's salary). And the new place, while giving you a poor environment that hampers your productivity, still pays much better than the previous places where your productivity was much higher. And because of this common workplace dynamic, it's usually not worth it to put in much effort to be a star employee, unless you find the rare employer that actually rewards you for it. Is my guess correct?