3 ms·

How does that work in organizations where everything has to be tied to a ticket and you have to do pull requests?

theamk 2y ago
You work on what you think is the most important, and then you choose a closest ticket # to put into pull request description. If there is no ticket close enough, then you make one first. Some companies like to micromanage and rob engineers from any sort of autonomy: they have non-engineers make tickets, and those tickets are very small, and they are assigned them without engineer's inputs, and managers carefully monitor that engineers only work on assigned tickets. If that's your case, then I am sorry. Also, it is not not a "senior engineers" position, even if your business card says otherwise. If you are interested in becoming a better engineers, consider a different, less disfunctional, workplace.
- scarface_74 2y ago
  I agree completely. I’ve been posting about leveling guidelines based on “scope”, “impact” and “dealing with ambiguity” here a lot over the past couple of days. https://www.levels.fyi/blog/swe-level-framework.html https://www.levels.fyi/blog/swe-level-framework.html It was more of a hypothetical question. I haven’t been in that position - ever. But I’ve heard horror stories. As a mid level developer (I’m now a staff software architect at a consulting company, I design and lead implementations from the ground up), do you really have that kind of autonomy to choose the tickets you work on outside of what was put in the sprint? I didn’t when I was a ticket taker a decade ago.
toast0 2y ago
In such an organization, there's no low hanging fruit, because everything requires a ticket writing exercise, and a group consensus managment exercise. Or you make up a blanket ticket, and self-approve your PRs. Or you start probing for process in interviews, so you can find somewhere to work without oppressive process.
- nosefurhairdo 2y ago
  I'm in such an organization, but this does not echo my experience. I write a ticket describing the work (takes no more than five minutes), open a PR, and get someone on my team to review. The engineers on my team dictate the process because we've repeatedly earned our manager's trust (and he's a great manager).
nosefurhairdo 2y ago
I write a ticket and open a PR and ask my team for review.

You work on what you think is the most important, and then you choose a closest ticket # to put into pull request description. If there is no ticket close enough, then you make one first. Some companies like to micromanage and rob engineers from any sort of autonomy: they have non-engineers make tickets, and those tickets are very small, and they are assigned them without engineer's inputs, and managers carefully monitor that engineers only work on assigned tickets. If that's your case, then I am sorry. Also, it is not not a "senior engineers" position, even if your business card says otherwise. If you are interested in becoming a better engineers, consider a different, less disfunctional, workplace.

scarface_74 2y ago
I agree completely. I’ve been posting about leveling guidelines based on “scope”, “impact” and “dealing with ambiguity” here a lot over the past couple of days. https://www.levels.fyi/blog/swe-level-framework.html https://www.levels.fyi/blog/swe-level-framework.html It was more of a hypothetical question. I haven’t been in that position - ever. But I’ve heard horror stories. As a mid level developer (I’m now a staff software architect at a consulting company, I design and lead implementations from the ground up), do you really have that kind of autonomy to choose the tickets you work on outside of what was put in the sprint? I didn’t when I was a ticket taker a decade ago.

toast0 2y ago

In such an organization, there's no low hanging fruit, because everything requires a ticket writing exercise, and a group consensus managment exercise. Or you make up a blanket ticket, and self-approve your PRs. Or you start probing for process in interviews, so you can find somewhere to work without oppressive process.

nosefurhairdo 2y ago
I'm in such an organization, but this does not echo my experience. I write a ticket describing the work (takes no more than five minutes), open a PR, and get someone on my team to review. The engineers on my team dictate the process because we've repeatedly earned our manager's trust (and he's a great manager).

nosefurhairdo 2y ago

I write a ticket and open a PR and ask my team for review.