Comment by cabraca

I think you write about people who mention that they can get 2-3 hours of actual work, which in turn they count as "actually writing code in editor".

I can easily imagine how it goes - because pushing tickets over takes time, bunch of meetings during the day takes time, explaining stuff to junior devs takes time, reviewing pull requests and answering to comments takes time, clarifying things with QA/BA/PO, figuring out which libraries to use by googling takes time.

I saw devs that think these things that I have listed don't feel like "real work" but it is. There is also no way to automate meetings or discussions over PRs.

I think the low hour anecdotes come overwhelmingly from Europe, where 45K is considered a high salary

It sounds like SOC2 compliance requirements unfortunately. Plus process overhead on who can raise tickets.

I've found compliance makes it harder to write good code. If you get a PR approval with optional suggestions you're heavily disincentivised from actually addressing those comments since if you push those changes you now need to wait for review again.

Like everything process and compliance it's designed by low-confidence managers with an inate distrust of their teams.

I like this in a certain light. It's not so much a problem that PRs should be associated with tickets, it just sounds like the gatekeeping involved in getting tickets into an iteration is horribly overbearing. There _should_ be work happening that is driven by technical wants and needs, and the PO should be amenable to that.

Yeah - team members are also stakeholders and improving dev experience by allowing refactoring is something that needs to be taken into account.

Unless company does not want to have any devs working on that project in the future. But it would be just like not wanting customers to use that project.

Do your non tech colleagues need to have approval before saving a spreadsheet or writing a doc? Do they need to plan it out in tickets weeks ahead of time and get sign off before starting their work? Then report status daily on their progress?

One of my friends is a technical writer and she is amazed we put up with this on the engineering side. No one would ask it of other professionals.

>Guess how much would get done if you learned to explain why that work is important to a non-technical colleague? Lots.

From my experience, this is more a cop-out than anything else. At some point I'd expect you understand children with a track record of doing as they are told and informing you of important details do not need to be strictly parented around every corner. To expect that very thing from adults with way bigger incentives to behave feels off.

This is like needing to ask to go to the toilet. It's degrading. Utterly disrespectful. You expect people to stick around?

Explaining why maintenance is necessary time and time again (tech evolves fast) is soul-crushing and quite frankly rather demeaning. I need x amount of hours for maintenance work every sprint, or the codebase will slowly become outdated and undesirable to work with. Again, tech evolves and changes rapidly, open source packages die quite often. Maintainers abandon their packages (my PO likely has no idea that we rely on free open source software to ship features), there are security issues with using abandoned packages… To sum up: when I see issues, I want to fix them. If I have to go through a corp process and ask for time to fix the issues… I sort of tend to lose the apetite/mood. This right here is the core issue.

> spending a week catching up on refactoring now will save 4 sprints of work in a year's time will get you the time.

In my experience that’s very rarely if ever the case. Managers will always favor features over fixes in the kind of company that ends up with a crippling tech debt problem. They got there by not listening to engineers and having salesmen managers. These companies never change and no manager wants to be the one who’s fixing things for the next manager after they get promoted. People are idiots (maybe) but they respond to incentives. And very often the incentive is that problems that may arise in a year or two are someone else’s problems so not worth fixing now.

But when something major breaks, and the answer to the question of "why?" is ... "well, I just thought i'd make that change, but nobody asked for it" what happens then?

I wouldn't want to be accountable in that situation.

Every change carries risk.

You wrote: <<I don't believe this is how it is actually implemented in _most_ companies.>>

I would say for non-tech companies with a strict set of IT guidelines, this is mostly true. Please ignore non-tech companies with weak or zero IT culture. It will be the 'Wild West' at those places! Nothing will be maintainable beyond a certain size because there will be so much key person dependency.

For pure tech or tech heavy (banking, insurance, oil & gas, etc.), there is frequently more flexiblity, including "dummy Jiras" just to track a non-QA'able code change like upgrade C++ / DotNet / Java / Python library, or refactor some code. In my experience, 'Jira-per-commit' rule isn't awful, as long as tech debt does not require non-tech approval, and the ticket is just a tracking device. (A few different vendors offer very nice total integration between issue ticket, bug ticket, pull request, code review, etc.) Just a one liner in the Jira should be enough. In my experience, the best teams try hard to "do what works for us", instead of be a slave to the Jira process. Yes, I realise this is highly dependent upon team and corporate culture!

Finally, I would be curious to hear from people who work in embedded programming -- like automotive, aeronautical, other transport, and consumer electronics. I have no experience in those areas, but there is a huge number of embedded programmers in the world! Do you also have a very strict 'Jira-per-commit' rule?

> But the actual ticketing/PR system? Change requires control.

The ticket system isn't for engineers. If it were for the engineers, they wouldn't be continually forced to use it. The ticket system is for the legibility of management or sometimes compliance (other flavors of management). This visibility is at the expense of the productivity of the engineers themselves.

> Change requires control

No, fundamentally, change is gated by control. The more control, the less the change, with sufficient levels of "control" leading to no change.

Requiring a "non-tech PO" to upgrade a package is just broken, though. PMs are good at some things, but giving them power over every minute of an engineer's day is a recipe for badness.

> Change requires control.

But code, unit tests, git commit messages and merge requests are already providing 4x documentation of code changes. Adding Jira tickets and production deployment documentation gets you to 6x documentation.

In my experience, if your company's problems weren't solved with 4x documentation, they won't be solved by going to 6x documentation.

In my company it depends on the repo but worst case is you get arrested for making unapproved changes to regulated sports betting systems.

You wasted time on something that doesn't get you out of PIP, into promotion, or a higher salary. At companies that micromanage, I would imagine your direct manager is the sole owner of your performance rating.

Why would you do that?

Worst case, you get criticized for doing unauthorized work.

Best case, you spend your time on a task that gets unnoticed, and now you have to do overtime to do stuff that you are assigned to and actually supposed to do.

You just gave a bunch of examples of problems that are in no way fixed by ticket bureaucracy, only hidden.

At my old place they just overestimated my tasks complexity by 200-300%. I wasnt going to be the one saying no... So i had plenty of time to fix whatever.

My take is that it's always going to come with an implicit expectation of some "business value" resulting if it's time granted to you by your management. If you say "let us hack, we could come up with something that makes millions of dollars!" they're going to wonder constantly when exactly you're going to come up with those millions.

This is really important. At my first job, in 2010 or so, we were using Servlets. Not just Servlets, but Servlets with some home-rolled shims to make it act like Servlets 1.0 in a distinctly post-1.0 world. Doing pretty much anything in there was slow, and I realized it at the time. So during a hack week I built an MVC layer on top, with routing that didn't involve XML files and just--made it generally better. Or so I thought at the time. To their credit, the team took it seriously and gave it a try, and while in a vacuum it was a better system I hadn't understood how the people on the team thought about web development and it wasn't a better fit for them. They didn't feel like there was a problem, so a solution didn't make sense. It could've been technically amazing (it wasn't, but it was fine), but it didn't solve a real problem, so it was an academic exercise at best.

Other refactors and systemic expansions, like a slot-based system for advertisement placement, worked a lot better, because I'd learned a little about how to dig into what problems actually existed and how they were causing aggravation to people.

When I was a non-senior eng., I interacted with plenty of senior engineers, found that I easily possessed the skills to work at their level / do their job.

My company at the time laid off my entire division. I decided it was time, needed a job of course, and so applied for and landed a job as a "senior SWE".

Ideally with guidance/mentorship though. There's a lot of stuff I learned the hard way that I wish I didn't have to!

You're both right, unfortunately - which makes it hard to ever consistently choose a path. Many people are stuck in the middle of the two sides in lots of orgs.

Your tedious tasks are important. But some of your research/autonomous work is important as well. But both are sometimes hugely wasteful as well. I'm regularly reminded that someone more senior can ascribe "business value" to something and push that to the top of your priority list even when that thing isn't valuable.

To me, as a manager, it's worth thinking about it from the perspective of praise. People might feel better if you're reminding them that the tedious stuff IS actually important, IS actually valuable (and why), and etc. And it's important to tell folks to share their side/research efforts as well. I've neglected to share so many of these little efforts over the years, but feel that they're almost always well received.

Last part said a different way. Share something, get the response, and then do what you can to connect and make it more relevant to a real problem or issue if it's not already.

I see this a lot at my current job. The tech stack is ridiculously complicated and I think a lot of it is due to this sort of motivation. They let developers run wild and build using whatever tools or new hotness that they wanted. But ultimately we sell Widgets. And the 3rd refactoring of an application to use some immutable data library doesn't do anything to help us sell more Widgets.

So yes, we have happy developers that have good morale. But we also have probably twice the number we need because nobody put their foot down and said "this is work, not play".