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 (18)
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 😂
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 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. 😅
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 😄
Side quest is the perfect metaphor and the most depressing one because side quests are optional. JIRA tickets don't feel optional.
I ve had days where I closed 6 tickets and felt nothing And days where I solved one weird bug and felt like I'd actually accomplished something The ticket count doesn't track meaning. It tracks motion.
What you're getting at the is this the main quest? question is the one that keeps me up Not because the work is hard. Because I genuinely don't know what the main quest is anymore Ship features? Close tickets? Make the graph go up? None of those feel like winning.
Maybe that's the real shift. Not from coding to prompting. But from knowing what done looks like to just doing the next ticket.
Thanks for this. It's going to sit with me. 🙌
Honestly, I’d probably enjoy moving those tickets — it’s like crossing things off a todo list, very satisfying 😄
But the moment I start thinking about all the fields I need to fill, statuses to pick, things to update… I immediately lose the motivation 😅
pushing back a bit - teams use Jira to compensate for missing async context. good docs and clear ownership would kill half those status tickets. the tool’s not the problem.
That’s a fair point 🙂 And just to clarify, I’m not saying the tool itself is the problem. I actually appreciate Jira a lot and wouldn’t want to work without some kind of tracking system.
I’m also not fully convinced that better docs or clearer ownership would solve this particular issue. From what I’ve seen, a lot of this complexity comes from the need to produce nice-looking reports and burn-down charts for management layers. And that’s how we end up with more fields, more states, and more “just one more thing”.
The observation that the best developers you know engage with Jira the least—not out of laziness, but because their attention is somewhere more useful—rings true in a way that's almost uncomfortable. It makes me wonder if the friction isn't really about Jira itself, but about who the tool is ultimately serving.
When a ticket system has three states, it's serving the team. Everyone knows what's waiting, what's moving, what's done. But each new field and status transition tends to serve someone one step further from the work—a PM who needs a chart, a stakeholder who wants a dashboard, a process person optimizing for visibility over velocity. None of that is malicious, but the cumulative weight lands on the people least likely to push back, because pushing back on process stuff somehow gets coded as "not being a team player."
What I find interesting is your point about government systems—where the stakes are genuinely high and tracking matters—actually reinforcing the case for simplicity rather than undermining it. If consequences are real, the last thing you want is a developer's mental energy being drained by tooling overhead when they should be thinking about edge cases and failure modes. Complexity in the tracker doesn't add safety; it just adds distractions in the place you can least afford them.
I'm curious: in your experience, have you ever seen a team successfully push back on Jira creep without it becoming a political headache? Or does it always require someone with enough seniority to absorb the friction on behalf of everyone else?