7 ms·

You don't, it's not his job to care, it's yours. And just like you don't ask permission for writing down a line of feature code, you don't ask permission for m

You don't, it's not his job to care, it's yours. And just like you don't ask permission for writing down a line of feature code, you don't ask permission for maintenance work. You just do it and schedule it accordingly to business needs to the best of your ability. And make sure not to apologize for doing your work or treat maintenance work as "unimportant" because that is how it will be perceived. It does get tricky when you have a manager defining tasks and you have yet to determine whether their job is to be a technical manager (and is adequately competent) or a nerd babysitter/translator. In the former case it's good to run maintenance projects by them if they need active, dedicated time as opposed to something you can mostly do during downtime. In case it's the other kind of "manager", and you've already tried and failed to convince them to prioritize basic stuff, you have to just put it inside other estimates and rope in the rest of your team to do the same and/or polish your résumé.

pojzon 4y ago
> You don't, it's not his job to care, it's yours. Last time I checked it was the job of Project Manager to decide which tasks land on the sprint backlog as he decides the priorities of what has to be delivered. Literally written in the job description. As a developer you can create a plan/tasks about decreasing technical dept, but its never your work to prioritize that, coz you dont know whats the priority of upper management..
- polotics 4y ago
  dot dot dot Hello! you do know the priority of upper management: they prioritize their own personal best interest, and as much as the board and CEO manage the incentive structure, this will be aligned with their fat bonuses. so, dot dot dot. do the same: if something creates pain for you, dispose of it.
  - cogman10 4y ago
    I've got two choices: - I can work with the current architecture and ever inflating accruing debt (yet slowly inflating) feature times which ultimately is acceptable by PM. This will get me pay raises, bonuses, and praise. - I can work on the annoying stuff which product does NOT want me working on, does decrease feature times, and does decrease debt. This will get me chastised, if I get any praise from my local team members, I don't get it from the people paying me. Working around the system is punished. Working through the system is rewarded. I get my fat bonuses by making my PO/PM happy. I don't get fat bonuses making my life easier.
- cogman10 4y ago
  Bingo. My quarterly deliverables are defined by the product guy above me. His priorities are defined by the product org. Ultimately, the CTO/CEO are the ones that set and tell them to allocate stuff. I can RAISE issues that need to be addressed to product, but generally speaking, dev doesn't have a seat at the table when it comes to prioritizing stuff. Instead, that's all driven by sales. Sure the company SAYS they do, but the practice isn't there. Dev requests are routinely ignored to the point that dev stops making them. Perhaps this is just my org that's dysfunctional, doesn't feel that way though.
  - mixedCase 4y ago
    Your org is most definitely dysfunctional. If you meant to say your org doesn't feel too out of ordinary, then it's not wrong depending on what industry sector you're working in. I'd summarize my comment again: if management doesn't let you do job properly you can suck it up, leave, or just fix things without asking anyone. But ask yourself, do you care that much about that company to not just move on?
- mixedCase 4y ago
  It's what I tried to address in the second part of my comment. A lot of teams don't have dedicated PMs in the first place, but for those who do get those jobs there's an extremely wide and well-distributed gamut of competences and skill sets, even more than developers I'd say. And you have to figure out whether you got a proper one, in which case it's the right thing to run such tasks through them when non-trivial, and then there's the rest. It depends on which market bubbles you've worked in to determine whether this latter group is an outlier or the norm.
- lamontcg 4y ago
  > you dont know whats the priority of upper management.. well, upper management has absolutely no clue about the state of your codebase. i don't understand how anyone can think that top-down driven engineering like this is healthy or correct organizational flow.
  - cogman10 4y ago
    Unfortunately, us bottom guys don't generally get to pick whether or not the org is bottom up or top down. Guess switching jobs is always an option, but what I've gone through is basically watching as an org grows it getting switched from being a bottom up to top down org because the C level guys want more control over everything.
    - iostream24 4y ago
      Tell them WHY you are leaving when you leave. Tell prospective employers about your concerns during interviews. When you turn down a job offer be clear WHY you did so, if it’s related to a bad management scheme.
- criley2 4y ago
  In any sane system, technical debt isn't backlogged and prioritized by project managers, it's simply a tax on all work. The point of "just doing" your technical debt isn't that you're stealing time from the PM, it's that when an engineer estimates their work, story points the next feature and everyone is deciding on the time frame, that process should implicitly include ~20% of time for you to continue to fix and update and improve things. Most PM's I've worked with do not care about that 20%, in fact, they're happy that we're taking the time to do it. They just want accurate estimates so they can tell stakeholders a realistic time frame and somewhat meet that goal. All you have to do is bake your 20% in and everyone is happy. Honestly if I worked for a company that micromanaged my time so closely that I was prevented from cleaning up technical debt and fixing things, I would still clean things up and be good at my job and let them fire me for it (or be searching and leave anyway). No PM, no middle manager, and no executive can ever make me sacrifice the quality of my work. They can only replace me with a monkey that won't have the same issue.
- Lutger 4y ago
  It's the job of the PM to decide what to build. It's your job how to build it, which includes taking time for an appropriate level of quality. It's easiest to improve the codebase where and when you alter it for feature work. This is also a good control for yourself to stick to relevant refactorings. This should be your professional autonomy. The remaining like, 5 to 10 percent of the time that you need 'dedicated' tasks, should be explained to and supported by the PM because he trusts you due to having a track record of delivering. Of course, reality isn't always ideal
  - pojzon 4y ago
    > It's the job of the PM to decide what to build. It's your job how to build it, which includes taking time for an appropriate level of quality. Cyting my current Project Manager: „We are short on deadlines, dont care about quality, just deliver crap and we will fix it overtime (we will not /s)” You live in some unrealistic world. Companies have deadlines set together with clients. Deadlines are signed by the ppl who have no idea about how technically challenging it can be to build something. You are hired to deliver ON TIME. Nobody gives a demn about quality when new client is banging on the doors. Thats the sad reality of 90% of IT.
    - iostream24 4y ago
      Provide feedback. Actual reality is technical debt, it’s your poor management that is living in a dreamworld
bcrosby95 4y ago
It's tricky when it gets to the point that you need specific tasks to clean things up. But lots of developers think any amount of cleanup needs to be scheduled. No, it does not. When you build on a feature, you modify the feature so that you can actually build on it in a reasonable fashion. Lots of developers will, instead of doing that, shove round pegs into square holes. There's nothing about a task that says you have to do it in the sloppiest, shittiest way possible. It's like the plumbers that cut through your floor joists because that's the easiest way to get their drain in.
- the_gipsy 4y ago
  Gotta get their PRs merged fast to look good and be a team player (with the project/product manager).

pojzon 4y ago

> You don't, it's not his job to care, it's yours. Last time I checked it was the job of Project Manager to decide which tasks land on the sprint backlog as he decides the priorities of what has to be delivered. Literally written in the job description. As a developer you can create a plan/tasks about decreasing technical dept, but its never your work to prioritize that, coz you dont know whats the priority of upper management..

polotics 4y ago
dot dot dot Hello! you do know the priority of upper management: they prioritize their own personal best interest, and as much as the board and CEO manage the incentive structure, this will be aligned with their fat bonuses. so, dot dot dot. do the same: if something creates pain for you, dispose of it.
- cogman10 4y ago
  I've got two choices: - I can work with the current architecture and ever inflating accruing debt (yet slowly inflating) feature times which ultimately is acceptable by PM. This will get me pay raises, bonuses, and praise. - I can work on the annoying stuff which product does NOT want me working on, does decrease feature times, and does decrease debt. This will get me chastised, if I get any praise from my local team members, I don't get it from the people paying me. Working around the system is punished. Working through the system is rewarded. I get my fat bonuses by making my PO/PM happy. I don't get fat bonuses making my life easier.
cogman10 4y ago
Bingo. My quarterly deliverables are defined by the product guy above me. His priorities are defined by the product org. Ultimately, the CTO/CEO are the ones that set and tell them to allocate stuff. I can RAISE issues that need to be addressed to product, but generally speaking, dev doesn't have a seat at the table when it comes to prioritizing stuff. Instead, that's all driven by sales. Sure the company SAYS they do, but the practice isn't there. Dev requests are routinely ignored to the point that dev stops making them. Perhaps this is just my org that's dysfunctional, doesn't feel that way though.
- mixedCase 4y ago
  Your org is most definitely dysfunctional. If you meant to say your org doesn't feel too out of ordinary, then it's not wrong depending on what industry sector you're working in. I'd summarize my comment again: if management doesn't let you do job properly you can suck it up, leave, or just fix things without asking anyone. But ask yourself, do you care that much about that company to not just move on?
mixedCase 4y ago
It's what I tried to address in the second part of my comment. A lot of teams don't have dedicated PMs in the first place, but for those who do get those jobs there's an extremely wide and well-distributed gamut of competences and skill sets, even more than developers I'd say. And you have to figure out whether you got a proper one, in which case it's the right thing to run such tasks through them when non-trivial, and then there's the rest. It depends on which market bubbles you've worked in to determine whether this latter group is an outlier or the norm.
lamontcg 4y ago
> you dont know whats the priority of upper management.. well, upper management has absolutely no clue about the state of your codebase. i don't understand how anyone can think that top-down driven engineering like this is healthy or correct organizational flow.
- cogman10 4y ago
  Unfortunately, us bottom guys don't generally get to pick whether or not the org is bottom up or top down. Guess switching jobs is always an option, but what I've gone through is basically watching as an org grows it getting switched from being a bottom up to top down org because the C level guys want more control over everything.
  - iostream24 4y ago
    Tell them WHY you are leaving when you leave. Tell prospective employers about your concerns during interviews. When you turn down a job offer be clear WHY you did so, if it’s related to a bad management scheme.
criley2 4y ago
In any sane system, technical debt isn't backlogged and prioritized by project managers, it's simply a tax on all work. The point of "just doing" your technical debt isn't that you're stealing time from the PM, it's that when an engineer estimates their work, story points the next feature and everyone is deciding on the time frame, that process should implicitly include ~20% of time for you to continue to fix and update and improve things. Most PM's I've worked with do not care about that 20%, in fact, they're happy that we're taking the time to do it. They just want accurate estimates so they can tell stakeholders a realistic time frame and somewhat meet that goal. All you have to do is bake your 20% in and everyone is happy. Honestly if I worked for a company that micromanaged my time so closely that I was prevented from cleaning up technical debt and fixing things, I would still clean things up and be good at my job and let them fire me for it (or be searching and leave anyway). No PM, no middle manager, and no executive can ever make me sacrifice the quality of my work. They can only replace me with a monkey that won't have the same issue.
Lutger 4y ago
It's the job of the PM to decide what to build. It's your job how to build it, which includes taking time for an appropriate level of quality. It's easiest to improve the codebase where and when you alter it for feature work. This is also a good control for yourself to stick to relevant refactorings. This should be your professional autonomy. The remaining like, 5 to 10 percent of the time that you need 'dedicated' tasks, should be explained to and supported by the PM because he trusts you due to having a track record of delivering. Of course, reality isn't always ideal
- pojzon 4y ago
  > It's the job of the PM to decide what to build. It's your job how to build it, which includes taking time for an appropriate level of quality. Cyting my current Project Manager: „We are short on deadlines, dont care about quality, just deliver crap and we will fix it overtime (we will not /s)” You live in some unrealistic world. Companies have deadlines set together with clients. Deadlines are signed by the ppl who have no idea about how technically challenging it can be to build something. You are hired to deliver ON TIME. Nobody gives a demn about quality when new client is banging on the doors. Thats the sad reality of 90% of IT.
  - iostream24 4y ago
    Provide feedback. Actual reality is technical debt, it’s your poor management that is living in a dreamworld

bcrosby95 4y ago

It's tricky when it gets to the point that you need specific tasks to clean things up. But lots of developers think any amount of cleanup needs to be scheduled. No, it does not. When you build on a feature, you modify the feature so that you can actually build on it in a reasonable fashion. Lots of developers will, instead of doing that, shove round pegs into square holes. There's nothing about a task that says you have to do it in the sloppiest, shittiest way possible. It's like the plumbers that cut through your floor joists because that's the easiest way to get their drain in.

the_gipsy 4y ago
Gotta get their PRs merged fast to look good and be a team player (with the project/product manager).