How much time did you spend this week moving tickets in Jira (or other tracking tool) instead of actually coding?
I sometimes have this feeling that my main job is not development anymore — it’s just moving things between columns.
I always say that a software developer, by nature, is lazy. That’s why we became developers in the first place — to automate everything. So maybe expecting us to not only do our actual work, but also carefully maintain every single detail in Jira… is a bit optimistic.
Quick “what’s up with me” section. My recent article
Most Apps are Slower Than They Need To Be
ended up going way beyond DEV — different newsletters, and it even got me invited to a podcast at WeAreDevelopers 🎤 First podcast in my life. Chaos, tangents… pretty much 100% me 😅
And here’s a fun part: the technical article that opened those doors had almost 6x fewer views than this one:
You're a Real Software Developer Only If... Well, turns out we all enjoy a good laugh more than GPU acceleration demos. Can’t argue with reality 😄
Anyway, back to the topic.
I’m a senior developer. Not officially a tech lead in my current company, but in practice I do a lot of that work, next to coding. Coordinating developers' work, answering questions, helping unblock people. And it’s not just the team — there are stakeholders, testers, other teams.
And the app? It’s a government system. So if something breaks, it’s not “oh no, someone couldn’t watch a show” (haha yes, I'm refering to @adamthedeveloper and his famous You're Not Building Netflix post 😁). The consequences can be very real.
After a day like that, the last thing I feel like doing is carefully updating every field in Jira.
Don’t get me wrong — I actually like having a tracking tool. I can’t imagine working without one, especially in a bigger team. Tasks need to exist somewhere, priorities need to be visible, things shouldn’t disappear into Slack threads.
I also create tickets myself all the time, or ask for them to be created. I want things tracked. I want a history. I want clarity.
But for me, a ticket should have three states: todo, in progress, done.
Everything else is… negotiable.
Stories? Epics? Fine. If it helps someone manage the process, I can live with that.
But then come the extra fields. The additional statuses. The “just one more thing” because it will make the report nicer. Because the burn-down chart will look better. Because someone somewhere wants a cleaner dashboard.
And slowly, without really noticing, we turn Jira into something that requires more mental effort than the actual development.
We’re basically the boiling frog at this point. One more field. One more status. One more small tweak. Until suddenly nobody really knows what goes where anymore, what needs to be updated, and why.
And then, of course, developers get blamed for “not keeping Jira up to date”.
At some point it starts feeling like development itself is just a side quest. If we didn’t have to deal with code at all, imagine how perfect our Jira boards could be. Beautiful burn-down charts. Perfectly filled tickets. Absolute harmony 😄
The funny thing is — the best developers I know are often the ones who engage with this the least. Not because they don’t care, but because their focus is somewhere else. On solving real problems.
I’m still managing it somehow. But I definitely feel the friction.
So I’m curious — is it just me?
Do you also feel this kind of frustration sometimes? Or did you actually manage to find a system that works without turning Jira into a full-time job?
Top comments (85)
The boiling frog analogy is correct. Nobody decided one day to make Jira a second job. It happened one mandatory field at a time, and the people adding them genuinely believed each one was reasonable. Individually, they are, but it's the accumulation that kills you.
There's also something deeply ironic about developers, people who will spend three days automating a task that takes five minutes, manually updating ticket statuses so a burn-down chart looks clean for a meeting nobody fully believes in. The automation instinct stops at the Jira board for some reason.
That said, a lot of the bloat comes from different teams trying to solve different problems with the same tool. Dev wants simplicity. Management wants reporting. Compliance wants an audit trail. Nobody's wrong exactly. The board just ends up carrying everyone's requirements at once, and somehow it's always the developers who get blamed for not keeping it tidy
I think the last paragraph pinpoints the problem.
Multiple people with different perspectives using the same tool.
Using the same ticket, using the same board.
As far as my Jira knowledge goes the solution could be to create tasks with fields everyone needs. And subtasks with the fields only the specific group needs.
Then you can create boards for every group, where they only see the relevant information for them.
The next step is to trigger subtask status changes depending on ticket movements. For example a ticket movement from a developer changes the status or text of a compliance ticket.
As a developer just add the Jira ticket to the PR, PR merge or deploy. And based on that context the Jira ticket changes status.
Only the triggering on status I haven't seen working, but I know it exists.
The tool is almost never the problem, it is the use with too little thought that creates the mess.
I could hammer in a nail with handle of the hammer, but there is a better way.
Exactly, I totally agree 🙂
And honestly, I don’t even need all that automation. I’m perfectly happy to move a ticket to “Done”. It’s actually quite satisfying, like crossing something off a todo list 😄
The problem starts when I also have to fill in a thousand fields and tweak a bunch of things just so the reports look nicer. Because in reality, people will get lost in that anyway and won’t keep it perfectly updated, which ends up making the reports look even worse.
Or it turns into managers pinging developers every day to update tickets… and we’re back where we started 😅
You might not need all the automation, but there are a lot of small things that can be automated. Not only to be developer friendly, but to have the smoothest workflow for everyone.
Also when there is no pattern when some field needs to be filled in, that is most of the times a signal the field isn't needed.
I prefer as much automatisation as possible. Only going to jira to start a new ticket is dream come true.
That’s actually very true 🙂 A lot of those things could be automated.
We even suggested a super simple “automation” once. Just make the truly required fields… actually required. But of course, there’s never time for that. It’s apparently easier to just chase developers to fill things in 😂
Yeah most companies are not good at treating their internal tools with the respect they deserve.
And that is sad.
When companies are investing in AI all those random things in their workflows are going to bite them in the ass. Because an agent it going to fill in all the things. It is the best employee that has no boundaries.
Spot on. It’s a classic case of the map not being the terrain. The folks who only live in the reporting layer are often miles away from the engineering reality. It’s easy to optimize a workflow on paper when you don't have to deal with the technical debt or the 'just one more thing' interruptions that those Jira tickets represent
I don't think is a versus story. A tool can be used for multiple purposes.
The clashes exist because the tool is used in a way that causes problems for everyone.
There have been occasions where people were trying things. And that in itself should not cause friction, even if it involves manually adding data. But there should be an expiration date for experiments. And when it is a good addition the input should happen with the least amount of effort.
Yeah, I totally get that. Different people are trying to solve different problems with the same tool 🙂
But at the same time… if my manager wants a beautiful report, then maybe they should be the one filling in all those extra fields 😄
Unless we explicitly decide that having a perfect report is more important than the software we’re delivering. In which case, fair enough, but let’s be clear about priorities 😅
I love the metaphor, but I’ll push back slightly: If development is the side quest, then Jira is the 'escort mission' that everyone hates but feels forced to play.
Your success with the 'Most Apps are Slower' article proves that people are starving for your brand of common sense. It’s ironic—the more 'process' we add to ensure quality, the more we drain the mental energy required to actually build quality. You’re doing the work of three people by absorbing that friction so your team can code. You might not have the 'Tech Lead' title on paper, but this post proves you’re the one actually leading the culture. Great read!
Thank you so much! 🙂 And yes, I think common sense is really the key here 😄
I totally get you! Between tickets, meetings, and all the theater we’re told is “essential,” it’s enough to drive anyone crazy… especially for simple folks like you and me ;)
Seriously though—how could anyone possibly survive with only three states in Jira? Without a sophisticated workflow and all that form-filling we both consider pointless, how is your app supposed to run? And more importantly—far more importantly—how else are all those Jira/Agile experts supposed to justify their salaries? :D
Hahaha exactly! 😄 The Jira experts need to earn their keep!
Obviously, nothing gets delivered without a perfectly structured process, beautiful epics and tasks, and all those carefully filled fields, otherwise how would we survive? 😉
And yet, somehow, at the end of the day I still get a million questions like:
“Sylwia, is this done?”
“Which version is it in?”
“When did we actually finish this?”
At this point I’m starting to think my memory works better than Jira’s 😅
“Sylwia, you are the company’s ultimate Jira — the Jira above Jira.”
Haha, Jira + the voice of reason in one 😄
I love this post, I feel totally same. I earned a tech lead title but that is not really important because I am alone team member for a year plus the team lead the BO/scrum master. I won that position because I am was the only person who is accept to maintane and improving a 7 years old applications chaos. But the Jira ticket playing on board even worst because we have a two boards. One for our partners company create ticket for us and one for our tem ( now we 3 developer again + uncounted agents ). Yes the coding part is not relevant for any one. Just the amount of done ticket number is the important. If we are counting on LOC then mordorjs is my right tool but the saddly truth is the solved ticket number.
The worst one is the devops team created automatic vulneralibity ticket generator. So on 2025 we are facing a 1500+ ticket. We are solved 1400+ under really fast, but that is a fake because that ticket just count on develop branch commit, but meanwhile that never deployed to production.
A final bonus is ticket micro management, where we need to write exact time we was spended on each ticket 30min precise.
Oh yesss, same here 😄 we also have to log time on tickets.
Honestly, I just don’t get it, it’s already beyond my level of comprehension 😅 One of my colleagues just starts a timer on a ticket… and sometimes forgets to stop it for like two days. So yeah, enforcing this consistently is… challenging.
What’s funny is that juniors are actually great at it. They log everything perfectly, because they need it for internal reporting and all those company processes 😄
Oh and yes, of course, a million tickets 😄
The best ones are those bugs where you close five at once with a single line of CSS. That’s when I truly feel like a top performer 😂
I see where you are coming from. Having to manage JIRA tickets more than "actual" work you have to do. It could be the case where the company is big to the point there is so many responsibilities, so therefore, JIRA tickets needs to be updated "constantly".
Finding that balance is hard because it varies by company and their goals. There isn't really much you can do about it other than adapt and finding ways where you can balance tickets and work.
It's hard to say since I don't have experience being part of a large company, so I can't say much but this is the best I could say based on what I heard from others and my personal experience. Thanks for sharing :D
In one company we actually fell deep into that Jira rabbit hole 😄 And then at some point someone wise came in and simplified it massively.
Honestly, even if the process was complex but at least stable, it would be manageable. But here… new fields just keep appearing all the time 😂
No, it's not just you. It's everywhere. Truth is, most of the time showing progress and reports is more important than doing actual work...I've been in countless times when solving the task can be done faster than creating a JIRA ticket and all the ceremonies behind it...
Haha YES!! 😄 I had a task like that too. We “analyzed” it for way longer than it actually took to implement in the end. I even pointed that out to management a couple of times… but you know how it goes 😅
I agree with "keeping Jira simple".
TODO, IN PROGRESS, DONE + maybe REVIEW, if you have analytic/tester role who checks tasks reported as completed before they are actually handled.
But I have also met devs who keep complaining about issue tracking, daily statuses and project management at large, to cover up their laziness and general incompetence. Without reasonable issue tracker and regular sync calls the project crumbles into chaos.
Haha, seriously? 😄
In my experience it’s often the opposite — the biggest slackers are also the most creative when it comes to looking busy in Jira and on calls 😂
I have to push back on one thing right away: “a software developer is lazy by nature.”
I feel personally attacked. I’m a hardworking engineer… sometimes. 😅 Do you know how much effort it takes to aggressively copy-paste prompts? That’s real work.🤣
Jokes aside, on the Jira topic, you’re definitely not alone. We often joke that we’re not really a product company, but a Jira- (and Excel-) driven organization. It’s honestly impressive how many properties and workflows people can come up with when given the chance.
About a year ago, we had a series of three 30-minute meetings for 150+ people, where a “Jira expert” introduced new states for bug tickets. We originally had five, now we have nine. Nine! Apparently, that still wasn’t enough before. 😄
All hail corporate life and our beautiful dashboards. 📋️
Haha, okay, I’ll admit, 9 states for bugs is already… impressive 😄
But honestly? That still sounds like amateur level.
In my case, when I want to close a bug and set it to “Resolved”, I also have to fill in the “Resolution” field… and there are 28 options to choose from. Twenty. Eight. 🤯
And the best part? The last one is something like “Xd11526”.
No description, no context. I’m honestly afraid to pick it in case it deploys something to production or summons a manager 😅
I had something similar in one of earlier projects.
Resolutionfield with about 10 options, but some of them had also required textarea to put more info 😂Oh yes, of course! 😄
And the best part is, no matter what you put there, if it’s anything other than “Fixed”, nobody really understands it anyway, and people will still come back asking: “so… why wasn’t this fixed?” 😂
28? 😅 Okay… I take it back. I’ll start being nicer to our Jira experts, it seems we’re still playing in the minor leagues.
That last option though… “Xd11526”? That’s not a resolution, that’s a gamble. I’d totally click it on a Friday afternoon without a rollback plan… just to see what happens. What could possibly go wrong? 😄
Exactly 😄 Tomorrow’s a holiday in Poland, so today is basically Friday energy. Very tempting to pick “Xd11526” right at the end of the day and just… close the laptop. 😅
Some time ago I discovered Task Management feature in WebStorm. It does few things:
This is beautiful 😄 The plugin just needs one more thing: a special agent that automatically fills in the remaining 100 required fields 😅
I don’t think development itself is a side quest, but in some orgs it definitely gets treated that way. Process starts dominating over actual problem solving.
Exactly, and the scary part is, it happens so quietly 😄
Some comments may only be visible to logged-in visitors. Sign in to view all comments.