6 ms·

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 smu

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 experience and extrapolating a bit too much about trends in the industry. I found myself nodding along at times and then saying "What?" the next sentence. My thoughts: * JIRA, still heavily used in many, many places. Not even close to being replaced in them. * Evernote vs. Markdown: I have been using org mode and or plain text notes for over 20 years. Markdown was a welcome addition to the arsenal, but I tried the Evernote/Microsoft Notes back in the day... just went back to plaintext for notes+todo, it has worked forever and is good enough. Org mode is a very nice and "Fancy" tool on its own. But also easy to get started with. Just some examples. I don't mean to be overly critical, it is an interesting and fun article about the tools we use as technologists, but it could do with a lot better grounding all around.

sverhagen 5y ago
Jira still for the complex stuff, with many teams in enterprises. But maybe less than it was in simple projects, with one-to-one relationships between issues tracking and repository?
- chii 5y ago
  There's a bias in HN that favours the simple and clean. But the real world is full of bureaucracies and complications due to legacy and/or politics or some other factors (like momentum). When HN users argue that certain tools (like Jira) is too complex, they imagine that a simpler tool following a simpler process would've worked. For them, may be it would, as a greenfield project, but not for the enterprise currently using Jira or is going to adopt it.
  - samat 5y ago
    Is this complexity warranted? I mean could not the same goals be achieved by less formality and less complexity?
    - DoingIsLearning 5y ago
      Most Engineering teams would probably work frictionlessly with any simple Kanban style board. The pull force in JIRA is how much it gives PM's and other managers a feeling of air traffic control visbility. It ends up serving as a medium for less technical people to digest and participate in a project. The features that in my opinion keep Atlassian profitable is all the automatic reports and analytics features more so than the daily work functionality.
    - p_l 5y ago
      I can't defend confluence for various reasons, but JIRA? HELL YEAH. The problem is that JIRA is a powerful tool that is often misconfigured or otherwise made to suck more than it should. For example on one of my current projects, both JIRA and confluence are put behind malfunctioning SSO meaning you have extra annoying steps that sap your energy and will every time you open them. And then you have to face that someone made a royal mess in it and we have to deal with it - without access to settings to fix IT. And the final nail is that effectively we can't use any external integration, because it's all blocked, including just using the API on your own. Now, if I had the power of administrator there... We would have better work flow, with automation supporting human overrides. We could link issues with our Github Enterprise and use local clients (org-jira, gojira, etc) as well as a bit integration in MS Teams. And I would fix login so that accessing JIRA or Confluence didn't feel me with annoyance of "where is that fucking RSAID" and "goddamn fix MFA already"
    - PeterisP 5y ago
      In some cases they could and in some cases they couldn't. For a particular example, in fintech development a bunch of formal ceremonies are non-negotiable, you need to track, document and query who ordered, developed, built and tested what and why and has a change request been formally approved by someone who has the authority to do so. In other cases, the formality is optional, but it's still a choice the organization has made. However, in any case it's not a technical discussion about tools, that would be putting the cart ahead of the horse, it's about organizational change, which tends to be as slow and difficult as a rewrite of a technical product. If the organization chooses to have a particular process, then they'll switch tools if needed to support that process; and the fact that they could use a more conenient tool if they would choose less formality and less formality does not carry much importance, that choice is determined by other factors.
- closeparen 5y ago
  We undertook a migration from not-JIRA to JIRA. Our previous issue tracker would let us have the same task in different columns on multiple boards. You could do your investigation, post your comment, reassign to the reporter, and move it into your "waiting" column. Then they would move it into their "in progress" column, do their piece, and get back to you. A complex cross-org issue might show this cycle 5+ times. In JIRA it is completely impossible. A task has one project and one status. You're lucky to have view and comment rights on another team's task, forget about change-status or reassign. An admin can "move" an issue but then it's gone from your own world. The net result: the issue tracker is no longer a communications medium, but a paper trail for the bean-counters, where you laboriously log conversations and decisions that actually occurred by email or Slack. There will be a JIRA corresponding to any give issue, but reading the JIRA will not tell you the story anymore.
  - wh33zle 5y ago
    That sounds interesting, what issue tracker did you use before?
- selfhoster11 5y ago
  It works well for simple stuff too. You can just _not implement_ a complicated workflow.
jruthers 5y ago
Right. The idea that Jira has been replaced made me laugh. There's probably a crowd of people that want to move on to the next issue tracker flavour and that's fine but I've got work to do that isn't tool shuffling. I'll use the one that integrates with so many of our systems and, though flawed, does a great job.
- solraph 5y ago
  That integration piece is key. The people who want to replace Atlassian tools usually focus one part of the suite (usually Jira or Confluence), but to replace them you all you need a set of tools that work together. It's not just issue tracking, but alerting, issue management ITSM tools, source control, CI/CD, release management, documentation and I don't know what else that all need talk to each other and provide traceability from any point to another. You can do the integration yourself, but it's a gigantic PITA, and as the number of tools rises, the number of integrations you need to set up is going to rise terrifyingly fast. I have a litany of complaints about the Atlassian suite, but none of the competitors have even have the services we need.
  - mtzet 5y ago
    On the other hand, I find the integration between Atlassian tools to be pretty barebones. It feels very clear to me that Atlassian tools are really developed separately, with a separate jira task to integrate specific parts. There's no "coherency" to them. You are right that it's difficult to replace the entire Atlassian suite. The thing about Atlassian is that when there's if there's a box to check on a feature list, they've made sure to check it. If you go around the office asking everyone what features they want, Atlassian is going to check all those boxes. That's pretty hard to compete with.
    - gknoy 5y ago
      There's no "coherency" to them. It's interesting to hear you say that. With the integrations we have with Slack and Github, I see previews, summaries, etc thrown at me when I link things
toomanyducks 5y ago
Personally, I think there's generalizations both ways here. Your experience doesn't map one-to-one with the author's, and the author's won't map to yours. Neither of them are absolute when applied outside of one life. I'd judge its accuracy by how well it resonates overall with people, and judging by its position on the front page and the sentiment of your last paragraph here, it resonates quite well.
akagr 5y ago
Org mode is easy to get started with if you’re an emacs user. I am one. But before I used emacs, there was no org mode in my life. And let’s face it, while emacs and vim allow you to craft your flow, most people are gonna use something like VSCode. Emacs and Vim have not been able to escape their old school image, even with all their awesomeness. I’d argue that ease-of-starting also includes how visible something is, since you can quickly find it and find resources for it. Most text editors don’t have org mode or have a small, half baked subset of it at best. A lot of amazing adjectives apply to org mode. Ease of use isn’t it until it climbs over the emacs wall. Not trying to be combative. I’d love if more people used org. Would love to be educated here if something I said isn’t accurate.
- RajuVarghese 5y ago
  I agree with you. I had used micro-emacs in the 80's and when, about 3 years back, I heard about org mode I wanted to become a big boy and start using emacs. It was a bitter struggle and for many months I regretted that I had even started down this path. But now I can do the basics and it feels much better. I know that I will be rewarded if I persist.
coldtea 5y ago
The post is not about what this or that place or person uses or "always have used". It's well understood that some people have "always used" IDEs, and other people have "always used" Vim/Emacs. The post is about general trends. What kinds of tools were trending/rising at some point, what at another at so on. In that sense, counter-examples don't negate a statistical observation. Only whether the trends described in it is right or wrong matters, not whether some or even many buck them.
- sokoloff 5y ago
  I agree that anecdotes don’t negate a statistical observation. The original article isn’t a statistical observation though.
Firehawke 5y ago
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.

sverhagen 5y ago

Jira still for the complex stuff, with many teams in enterprises. But maybe less than it was in simple projects, with one-to-one relationships between issues tracking and repository?

chii 5y ago
There's a bias in HN that favours the simple and clean. But the real world is full of bureaucracies and complications due to legacy and/or politics or some other factors (like momentum). When HN users argue that certain tools (like Jira) is too complex, they imagine that a simpler tool following a simpler process would've worked. For them, may be it would, as a greenfield project, but not for the enterprise currently using Jira or is going to adopt it.
- samat 5y ago
  Is this complexity warranted? I mean could not the same goals be achieved by less formality and less complexity?
  - DoingIsLearning 5y ago
    Most Engineering teams would probably work frictionlessly with any simple Kanban style board. The pull force in JIRA is how much it gives PM's and other managers a feeling of air traffic control visbility. It ends up serving as a medium for less technical people to digest and participate in a project. The features that in my opinion keep Atlassian profitable is all the automatic reports and analytics features more so than the daily work functionality.
  - p_l 5y ago
    I can't defend confluence for various reasons, but JIRA? HELL YEAH. The problem is that JIRA is a powerful tool that is often misconfigured or otherwise made to suck more than it should. For example on one of my current projects, both JIRA and confluence are put behind malfunctioning SSO meaning you have extra annoying steps that sap your energy and will every time you open them. And then you have to face that someone made a royal mess in it and we have to deal with it - without access to settings to fix IT. And the final nail is that effectively we can't use any external integration, because it's all blocked, including just using the API on your own. Now, if I had the power of administrator there... We would have better work flow, with automation supporting human overrides. We could link issues with our Github Enterprise and use local clients (org-jira, gojira, etc) as well as a bit integration in MS Teams. And I would fix login so that accessing JIRA or Confluence didn't feel me with annoyance of "where is that fucking RSAID" and "goddamn fix MFA already"
  - PeterisP 5y ago
    In some cases they could and in some cases they couldn't. For a particular example, in fintech development a bunch of formal ceremonies are non-negotiable, you need to track, document and query who ordered, developed, built and tested what and why and has a change request been formally approved by someone who has the authority to do so. In other cases, the formality is optional, but it's still a choice the organization has made. However, in any case it's not a technical discussion about tools, that would be putting the cart ahead of the horse, it's about organizational change, which tends to be as slow and difficult as a rewrite of a technical product. If the organization chooses to have a particular process, then they'll switch tools if needed to support that process; and the fact that they could use a more conenient tool if they would choose less formality and less formality does not carry much importance, that choice is determined by other factors.
closeparen 5y ago
We undertook a migration from not-JIRA to JIRA. Our previous issue tracker would let us have the same task in different columns on multiple boards. You could do your investigation, post your comment, reassign to the reporter, and move it into your "waiting" column. Then they would move it into their "in progress" column, do their piece, and get back to you. A complex cross-org issue might show this cycle 5+ times. In JIRA it is completely impossible. A task has one project and one status. You're lucky to have view and comment rights on another team's task, forget about change-status or reassign. An admin can "move" an issue but then it's gone from your own world. The net result: the issue tracker is no longer a communications medium, but a paper trail for the bean-counters, where you laboriously log conversations and decisions that actually occurred by email or Slack. There will be a JIRA corresponding to any give issue, but reading the JIRA will not tell you the story anymore.
- wh33zle 5y ago
  That sounds interesting, what issue tracker did you use before?
selfhoster11 5y ago
It works well for simple stuff too. You can just _not implement_ a complicated workflow.

jruthers 5y ago

Right. The idea that Jira has been replaced made me laugh. There's probably a crowd of people that want to move on to the next issue tracker flavour and that's fine but I've got work to do that isn't tool shuffling. I'll use the one that integrates with so many of our systems and, though flawed, does a great job.

solraph 5y ago
That integration piece is key. The people who want to replace Atlassian tools usually focus one part of the suite (usually Jira or Confluence), but to replace them you all you need a set of tools that work together. It's not just issue tracking, but alerting, issue management ITSM tools, source control, CI/CD, release management, documentation and I don't know what else that all need talk to each other and provide traceability from any point to another. You can do the integration yourself, but it's a gigantic PITA, and as the number of tools rises, the number of integrations you need to set up is going to rise terrifyingly fast. I have a litany of complaints about the Atlassian suite, but none of the competitors have even have the services we need.
- mtzet 5y ago
  On the other hand, I find the integration between Atlassian tools to be pretty barebones. It feels very clear to me that Atlassian tools are really developed separately, with a separate jira task to integrate specific parts. There's no "coherency" to them. You are right that it's difficult to replace the entire Atlassian suite. The thing about Atlassian is that when there's if there's a box to check on a feature list, they've made sure to check it. If you go around the office asking everyone what features they want, Atlassian is going to check all those boxes. That's pretty hard to compete with.
  - gknoy 5y ago
    There's no "coherency" to them. It's interesting to hear you say that. With the integrations we have with Slack and Github, I see previews, summaries, etc thrown at me when I link things

toomanyducks 5y ago

Personally, I think there's generalizations both ways here. Your experience doesn't map one-to-one with the author's, and the author's won't map to yours. Neither of them are absolute when applied outside of one life. I'd judge its accuracy by how well it resonates overall with people, and judging by its position on the front page and the sentiment of your last paragraph here, it resonates quite well.

akagr 5y ago

Org mode is easy to get started with if you’re an emacs user. I am one. But before I used emacs, there was no org mode in my life. And let’s face it, while emacs and vim allow you to craft your flow, most people are gonna use something like VSCode. Emacs and Vim have not been able to escape their old school image, even with all their awesomeness. I’d argue that ease-of-starting also includes how visible something is, since you can quickly find it and find resources for it. Most text editors don’t have org mode or have a small, half baked subset of it at best. A lot of amazing adjectives apply to org mode. Ease of use isn’t it until it climbs over the emacs wall. Not trying to be combative. I’d love if more people used org. Would love to be educated here if something I said isn’t accurate.

RajuVarghese 5y ago
I agree with you. I had used micro-emacs in the 80's and when, about 3 years back, I heard about org mode I wanted to become a big boy and start using emacs. It was a bitter struggle and for many months I regretted that I had even started down this path. But now I can do the basics and it feels much better. I know that I will be rewarded if I persist.

coldtea 5y ago

The post is not about what this or that place or person uses or "always have used". It's well understood that some people have "always used" IDEs, and other people have "always used" Vim/Emacs. The post is about general trends. What kinds of tools were trending/rising at some point, what at another at so on. In that sense, counter-examples don't negate a statistical observation. Only whether the trends described in it is right or wrong matters, not whether some or even many buck them.

sokoloff 5y ago
I agree that anecdotes don’t negate a statistical observation. The original article isn’t a statistical observation though.

Firehawke 5y ago

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.