Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Return of Fancy Tools

macwright.com

Post reply on HN
Print view View original

201–210 of 224 posts

Re: The Return of Fancy Tools

#201

Post by ddingus »

laurent92 wrote: post #161
rkangel wrote: post #159

Earlier quoted context omitted.

> I don't know if it's possible to have an adequately fast installation of Jira That's not my experience of Jira. The cloud version is the best, and our current on-prem installation is perfectly fine. I agree that Jira isn't the snappiest tool to use, but I don't sit there consciously waiting for it to do stuff.

> I agree that Jira isn’t the snappiest tool It is forbidden in the ToS 3.3 to “(i) publicly disseminate information regarding the performance of the Cloud Products“. https://www.atlassian.com/legal/cloud-terms-of-service

Anytime I see similar language, I know I do not have to look very hard to understand why someone felt it worth producing.

They might as well say it:

Will be slow, we feel that does not impact the value proposition.

Our license revenue is super necessary and this is not a race.

Ya, slow now because we need users and features now, go faster later.

If you need it to be more performant, pay us more and make the hardware investments we tell you to...

I personally would respect those more than a blanket gag attempt.

Re: The Return of Fancy Tools

#202

Post by [deleted] »

john-aj wrote: post #113
noobermin wrote: post #109

Earlier quoted context omitted.

Not to drag on the OP but I really wonder about people who are the subject of these articles who supposedly migrate from x to y to z, because at least for me I'm still using emacs like I did 10 years ago. The things I focus on is more about doing work than what tool I'm using. Do people really migrate or is this more about growth in a user-base? A higher rate of growth of one user-base relative to another user-base i…

Exactly. I'd guess that a majority of VS Code users are relatively new to programming. Not to say that there aren't experienced people who have switched, especially among the TextMate/Sublime Text crowd, but the incredible growth in users? I think that's largely a result of new programmers choosing the same editor, not old programmers switching.

[deleted]

Re: The Return of Fancy Tools

#203

Post by Firehawke »

bitexploder wrote: post #44

First, this is an interesting take, and I think there is some kernels to consider in it. However, the author is painting very broadly with a large brush and smudging a lot. I have been happily using PyCharm/IntelliJ since what feels like the dawn of time. It is a perfectly complex and rewarding Fancy Tool. People still use IDEs for C/C++ this whole time, etc. I think the author is taking their personal journey and ex…

At least in my own specific case, I have neurological damage that has swiss-cheesed my memory. I get that not everyone needs nor wants smart tools, but I prefer to have at least a moderate safety net.

The fact that there's such a wide range of options doesn't hurt. I'm currently using Logseq for note-taking (yeah, I actually had to look up the name. That's how bad my memory is) and it's been a considerable help there. VSCode, well, I use it with custom task setups that script as much of the manual work that I'd be likely to slip up on as possible.

Not everyone needs that sort of thing. I didn't 20 years ago.

So, yeah, I agree with what you're saying-- different tools for different needs.

Re: The Return of Fancy Tools

#204

Post by Viliam1234 »

michaelt wrote: post #175
rkangel wrote: post #159

Earlier quoted context omitted.

> I don't know if it's possible to have an adequately fast installation of Jira That's not my experience of Jira. The cloud version is the best, and our current on-prem installation is perfectly fine. I agree that Jira isn't the snappiest tool to use, but I don't sit there consciously waiting for it to do stuff.

No doubt it depends on how you use it, but I find it very slow. For example, I just tested following a permalink to a comment on a ticket. After 1.3 seconds I see the ticket - but it takes more than 7 seconds until I'm scrolled to the right comment, all the ticket details are loaded, and so on. And the slow-ass lazy loading means you daren't click something between 1.3 seconds and 7 seconds, because at any moment a n…

I used to complain about Jira for similar reasons. Then we switched to Azure DevOps, and now I have tears in my eyes and cry "I want my simple and fast Jira back!"

Re: The Return of Fancy Tools

#205

Post by laurent92 »

anoncake wrote: post #176
laurent92 wrote: post #161

Earlier quoted context omitted.

> I agree that Jira isn’t the snappiest tool It is forbidden in the ToS 3.3 to “(i) publicly disseminate information regarding the performance of the Cloud Products“. https://www.atlassian.com/legal/cloud-terms-of-service

Even if that clause is enforceable, you can just tell people about it instead. No company would try to prevent talk about their products' good performance.

Actually, I’m obviously not talking about Jira but imagine some made an issue tracker in cloud mode and programmed it using microservices, the speed of each microservice would vary a lot depending on workload, time of the day, location, time since last access of the document/attachment/screen/userdata, configuration of the instance, importance of this customer (maybe I would give privileged speed to a good customer, or to one whom I’ve had problems with on other features) and it would vary so much that performance for one person would be hardly representative of another person’s experience.

That would be one legit reason for thinking about writing this clause. Because it’s really curious to think about writing that.

Re: The Return of Fancy Tools

#206

Post by jeddy3 »

rkangel wrote: post #159
randallsquared wrote: post #154

Earlier quoted context omitted.

> I've got work to do that isn't tool shuffling. Is most of that work waiting for Jira to respond to your action so you can take the next action? I don't know if it's possible to have an adequately fast installation of Jira (since I've never seen one in a decade of Jira use at various places), but I do notice that people who have to put a lot of things into Jira seem to mostly use text editors or word processors to a…

> I don't know if it's possible to have an adequately fast installation of Jira That's not my experience of Jira. The cloud version is the best, and our current on-prem installation is perfectly fine. I agree that Jira isn't the snappiest tool to use, but I don't sit there consciously waiting for it to do stuff.

> but I don't sit there consciously waiting for it to do stuff.

100% of the time I want Jira to do stuff is when I'm interacting with it, and thus absolutely waiting for it.

Re: The Return of Fancy Tools

#207

Post by CRConrad »

AlotOfReading wrote: post #184
Kinrany wrote: post #108

Earlier quoted context omitted.

They probably meant seconds. A website that takes seconds to open is unusable.

I wish I was mistaken, but I do literally mean minutes. I've measured it with a stopwatch before.

Better tell your Jira admin that something is terribly borked with your company's install, then.

Re: The Return of Fancy Tools

#208

Post by CRConrad »

yjftsjthsd-h wrote: post #78
bradknowles wrote: post #55

Earlier quoted context omitted.

Jira is very sensitive to the configuration you build for it, and the hardware it is running on. The full configuration for Jira would make an Encyclopedia look small. Get that wrong (as many places do), and it is hard to use and dead-dog slow, at the best of times. But if you have a real Jira wizard who can configure things correctly, then it can easily be the fastest and easiest way to organize your development and…

On the one hand, I actually do agree with you. On the other hand, if nobody can use the tool right, then it's not the user at fault.

The GP's point was precisely that some can use the tool right.

Re: The Return of Fancy Tools

#209

Post by CRConrad »

eyelidlessness wrote: post #94
madeofpalk wrote: post #10

Earlier quoted context omitted.

Sliding in here with the hot take, but Jira can actually be pretty good! Github is terrible at project management. The problem with Jira (or at least used to) is that it has so much complexities that let people make it overly complicated.

I hate that I agree with this but... I soured on Jira because my first experience with it was a horrible Rube Goldberg configuration on a self hosted instance. Years passed, I tried a bunch of different ways to use GH Issues as a primary tracking tool. It works but it’s... blah. It’s a good outward facing tool, it’s not good for tracking internal work. Because there’s no organizing principle. My last job forced me to…

> The only thing I couldn’t sort out to make it habitable: I really wanted to disable the “sprint” concept and have a single board without gymnastics. I don’t know if that’s just baked in or something the company configured.

FWIW: We have sprints in JIRA at work -- but at my previous job we didn't. I doubt they've been added to the product in the couple of years since I left my previous employment, so I'll guess it was configured not to use sprints there, and still could be now.

Re: The Return of Fancy Tools

#210

Post by CRConrad »

aunty_helen wrote: post #40
dragonwriter wrote: post #32

Earlier quoted context omitted.

> If jira didn't have the ability to make it crap Then your managers would buy a tool that did instead. > maybe just try not to smush existing ms CRM workflows into a tool for devs. If your employer wants a tool into which those workflows can be smushed and wants devs integrated into those flows, that’s what they’ll get. Blaming a tool for supporting your management’s desires is...missing the people obviously respons…

Jira existed as a better product before this and gained popularity without this functionality. I used and championed old jira in this business but hadn't used it for some time. A better realisation would have been that one tool isn't going to integrate everything in your business from developing software to dealing with customers billing.

Sure, but that still sounds like it was your management that should have had this realisation -- but didn't. That's a fault with your management, not the tool.
Post reply on HN