3 ms·

Surely there's a balance to be found. Personally, I allow myself some not-explicitly-requested improvement work when I see what I view as low hanging fruit. I

Surely there's a balance to be found. Personally, I allow myself some not-explicitly-requested improvement work when I see what I view as low hanging fruit. I know the code and effort involved, and sometimes just doing the thing is fast enough it's not worth working it into planning. It also keeps me motivated on whatever "next thing" I'm working on when I allow myself some non-next-thing work. However, there's definitely wisdom in aligning priorities with the business. If "next thing" is deemed more important by the people who pay you, you should probably be focused on that.

scarface_74 2y ago
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.

scarface_74 2y ago

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.