Comment by taspeotis
11 hours ago
I came back to a workplace, that still used JIRA. Obviously during the interview I was like oh JIRA yeah yeah yeah you still use that? I can use that.
Anyway yes, I can use JIRA. But it was a real shock to see the latest version of JIRA. It has a thousand papercuts, one of the worst is double clicking on text select stuff suddenly kicks fields into editor mode.
What I was remembering was JIRA Server 4.0, you can walk down memory lane here* - zoom in enough and you'll see each issue has a title, type, fix version, affects version, and so on, and then you end up going straight to the comments. Very straightforward.
* https://www.jirastrategy.com/wp-content/uploads/2020/04/depl...
You can find correlations with stock price and positive user perception that were held up in product.
It came with its share of paper cuts too, like going from 4.x to 6.x or literally anything challenging to the rickety boxes of OFBiz and wholly-different products skinned for looks-maxxing.
Those engineers dipped out a while back and took their $280 shares with them.
About the double click into edit mode: Yes!! So much this! So annoying. Even basic text stuff they get wrong! But you know what a project manager told me ... They _like_ that, because they never use double click drag to select whole words ... ugh. Like always more proficient computer users are dragged down by the convenience for people barely able to use a computer.
> Obviously during the interview I was like oh JIRA yeah yeah yeah you still use that? I can use that.
Hold up, did I miss something? Fall into a time hole? Why are we talking about Jira like it’s Visicalc? Not currently working for an IT company, so maybe I missed something cataclysmic in the past two years…
Depends where you work.
Asana, Notion and Linear have major penetration in small companies.
Jira is usually pushed by more corporate types who want to “control” what gets done, not understand it.
My day job doesn't require using Jira or similar tools any more, so from a perspective of genuine curiosity: what's the consensus among entire project teams (not just the nerds) for a better alternative?
Linear.
By far and away, linear.
The task tracking features you actually use, it’s fast, you don’t waste a billion years playing “who knows how to do this and has the permissions hell” that you would with Jira. The integrations work properly. The layout and UX makes sense, and all the nontechnical people I’ve used it with liked it and had no issues with it.
Another vote for Linear. The absolute craft that has gone into building this product and company I truly believe is second to none. Once you start using Linear you start seeing how strong their design and UX influence is on so many other companies. This has certainly been the case for us.
Linear is quite seriously one of the best products (in any category) I’ve ever used.
Ekso - https://ekso.app with docs at https://ekso.dev. Docker installed with PostgreSQL or SQL Server, your choice of where to host it, with a Render install. 103 MCP Tools with manual or AI-assisted resource planning. Oh, and a CLI that effortlessly migrates projects from Jira.
Linear
To give a bit longer answer: Linear.
They have a first class MCP server, and you can basically run a project from your agent. Implementing something, and you find out there's more to do later on in a separate issue? Agent creates the issue for you and off you go. It works very nicely, and also has a great UI but I mostly using it from my agent.
That version of JIRA could still easily be configured to be awful. That's the main problem with JIRA - the power to actually configure it to be sane is always reserved by a few people who don't want to bother, don't have time and don't care because they aren't really using it every day.
Well one of the problems anyway. It's also unimaginably slow, and has weird limitations like issues can't be parents of other issues.
The non-existence or non-availability of recursive features, like an issue being parent of an issue, or in Slack a thread being started inside a thread and so on, to me usually indicates, that the developers of the tool are afraid of recursion, and have never learned how to implement this easily in a database, used a programming language that easily deals with recursion, and don't know how to deal with it in other languages. They tend to think "it's too complicated". It's usually just a silly lazy excuse, but here we are, with tons of inflexible shitty tools.
Alternatively, it is a conscious decision to help prevent users from causing complicated situations.
Given a highly configurable system, users will find ways to (unintentionally) tie it into knots, so adding some guardrails can help reduce complexity demons down the line (both in the technical implementation and the user experience).
I guess I prefer to give people making things the benefit of the doubt.