Hacker News Reader

Comment by dustedcodes | Hacker News Reader

Someone should make job board where people can filter out companies that use Teams instead of Slack or Discord.

Use of Teams has a been a deciding factor about not taking a job before. It's got to be pretty bad when it makes me nostalgic for HipChat.

I used HipChat for years and never actually saw what the thing looked like. Any XMPP client just worked, no hassle whatsoever. When we later switched to Slack it was actually a downgrade from my point of view. :-/

Unfortunately, at least in my experience, if the company shows any signs of success then incoming Finance/IT execs will force a change to Teams to "enable growth". If they begin to struggle, then incoming Finance/IT execs will force a change to Teams to "consolidate and streamline". I've experienced both of these. Resistance is futile.

Throw JIRA into the mix while you're on it.

Wait, what's wrong with JIRA?

Atlassian is an asshole company for their stance against selfhosting it.

What stance? You simply purchase a license and selfhost it.

See https://www.atlassian.com/migration/assess/compare-cloud-dat...

Newsflash: Jira Server end of sales was in februari 2021. Support will completely end in februari 2024.

You better start scheduling your migration.

Maybe for insane prices. But that too will go away.

People that don't need Jira but are forced to use it just hate it.

Same as any other product in the world.

Subpar at what it's supposed to do, extra features don't add a whole lot, mostly made and configured for managers instead of developers. Largely the same reasons people dislike Teams. Has even worse integrations with the Atlassian stack than Teams with the MS stack.

JIRA, just like Teams, is slow, bloated, still won't fix basic issues and largely exists to appease managers. You have to actively work to make JIRA a pleasant experience. It's too easy for most management to make it hell.

I personally find that the more I have to use JIRA, and the more magical ephemeral rules that are set up in it to take actions in response to my actions with it, the more terrible it is to use.

I've worked on teams where I just threw info into a card, and it was acceptable to use, and I've worked on teams where commits had to have a JIRA tag associated or the commit got rejected, including in instances where bitbucket was timing out it's call to JIRA. In the latter cases, I prayed for Atlassian's swift destruction, but alas, was never answered.

So like a lot of tools, it's how you use it, mostly. That said, as far as universal problems, cloning cards has to be one of the worst UX experiences I run into on the job with any frequency that I can't just fix myself. If the web app needs to await a successful or failed clone of a record (or series of them), I'm not sure why they can't implement a modal or a spinner or other component to tell the user that something is happening, then either navigate the user to the new card, or ask the user if they would like to view the new card. Shooting off a process that you say could take an indeterminate amount of time then dropping eventually a completion notification and link in the bottom left panel is just about the least helpful way to communicate that information.

edit: unrelated meta comment, but it's funny as hell to me that this question got 4 replies in the few minutes it took me to write this reply, all within 10 minutes of the original. People are really out here just waiting for a chance to complain about JIRA. Myself included it seems. Makes me feel a bit bad, hate to pile on to popular sentiment when others have already commented in a similar direction.

I'm trying to cleanup a Git tree right now where people haven't put JIRA tags in their commit comments, it is impossible to find out why a change was made, it isn't a totally stupid requirement.

Yes, "let's tie our codebase to the choice of ticket system forever as a means to commit documentation"

You can have both. Also, let's not pretend developers are wholly committed to writing comprehensive commit messages. A ticket number is useful if the change was relatively recent. If the organization moves to a different tool, chances are they are well aware of the potential history they are leaving behind.

and... I've never yet been in a team/project where being able to track/view/find issue/code pairings from years ago was ever remotely useful or helpful. If it was something in the last few months, sometimes people could dig in and try to understand a bit more by asking relevant people.

Finding a 'bug' introduced by someone from 4 years ago who doesn't work there any more, then finding the particular ticket that spawned it... this has never been high on the priority list of anyone I've ever worked with.

As an architect working on maintenance & refactoring, I find regular value in being able to understand the context (issue tracker ticket) in which a commit was made.

Also more than mildly useful for devs doing porting work.

Commit comments are rarely substantive enough, and "asking relevant people" is nice but not an actual substitute for keeping meaningful records.

I can recall multiple times I've determined why the current logic in the code should be not simplified as part of refactoring or fixing a bug after tracking down the original ticket associated with a commit. That original ticket is quite often a bug report, and sure enough, there was actually a good explanation for why the code is written the way it is, which is almost never going to be captured in commit or inline comments. While having an associated unit test is arguably a better way to capture the reason for such code changes, there are many reasons that's far less likely to exist than a JIRA ticket or equivalent.

"It's impossible to find out why a change was made" is a completely separate issue. Either the code is documented or it's not, completely polluting your history with JIRA tags isn't the answer - not least of all because like a sibling commenter said you're now forever tied to JIRA, or if you ever move off of JIRA, now get to choose between bringing JIRA tag information into the new ticketing system, or rewriting your entire git history again.

The project has just moved to JIRA from Bugzilla. The original convention was to put the Bugzilla issue ID in commit comments, these IDs were carried forward when moving to JIRA so people can still search for them.

It's definitely a concern to rely on the ticket system, but the commit message and the comment can't (and shouldn't) contain every bit of info about a change.

Commit message: "Improved clarity and detail in error message"

Ok, that's obvious what's happening, and as a standalone change that's absolutely fine. But the question it doesn't answer is why did someone actually put that effort in?

If the commit message mentions a ticket, then you can go look that up, and now you can find out, for example: it was a ticket that was an unknown bug being experienced by one specific customer, and so the error message was being improved as part of tracking down the bug. You also see who the customer was, internally who reported/escalated it, how long this has been an issue for, and if the bug was found and eventually fixed or not.

I'd argue absolutely none of that belongs in comments in the code, and it's way too onerous for a dev to constantly put that level of detail into every commit message. It's a balance: it's only useful to lookup that info on a small fraction of commits; it takes a lot of time to figure it out when missing (especially if it was many months ago); and putting a ticket number in each commit message is very low effort.

Or you just write sensible commit messages. Commits together with the messages should require as little out of band information as possible.

I'm a big fan of this personally, but I've also lived with the experience of completely useless commit messages, so I understand both arguments. Here's the most recent commits for a project I'm working on:

Counts

Log entries

missing package json

ttl in seconds

cache back on

Still, I'd rather try to convince people to write useful messages than hard bind my remote code repository to my system for managing work, and often times (but certainly not always), single line commits are self explanatory.

Bullshit. "Fix performance issue in listing page for customer support".

Which customer? Is it the same issue as the one this other customer is reporting? How does the support person know the fix has been released?

Unless you are expecting devs to copy paste a tonne of info into commit messages, it's way easier to just put the god damn ticket number in the commit title.

If you really need to commit something with no ticket, just have a dummy ticket placeholder like DEV-0000.

99/100 it's just laziness on the devs part... It's way easier to add a ticket number than write super detailed commit messages, and every case of missing Jira numbers of seen, there has never been a detailed commit message in its place... /Rant over

> Unless you are expecting devs to copy paste a tonne of info into commit messages, it's way easier to just put the god damn ticket number in the commit title.

Yes, that's what devs should do. Or link to an issue from the git provider. Commit messages shouldn't contain customer information, they should contain fine grained information why the change fixes a particular issue and other technical minutae.

What you doing here is conflating business information and technical information. Business knowledge has no reason to be in commit messages. The code base should be 100% understandable without specific knowledge about what customer wanted what. It would be a huge red flag for me to see those things talked about in the context of the commit messages as a regular thing.

I hate to break it to you, but code is usually written in support of a business objective and does not exist in a vacuum of technological purity... I say this as someone who's written everything from x86asm to python and everything in between for decades. If it really upsets your sensibilities to insert a reference to that business objective in a commit message then I don't know what to tell you...

A business objective is generally translatable to a use case, user story or requirement that can be understood without knowing "Mr. Smith from Company Thingamajig struggles to do x and is willing to pay sums of money to have it fixed". Your developers absolutely should NOT be knowing or dealing with business objectives.

As always there can be exceptions but if this is normal operating procedure for your company I would run far and fast.

> If you really need to commit something with no ticket

I'm of the opinion the only time this should ever happen is if it's a critical fix to allow ci builds to succeed. E.g. unit tests with hard-coded assumptions about the external world (current date etc.) that stop being true. Or errors in pipeline scripts that occur due to changes in a build agent.

The best thing about cross-linking between Git and an issue tracker is that when you have multiple commits for one ticket (very common), they can all link back to one ticket. Having the extra context from discussion is useful, but obviously that can be summarised in the commit message. So being able to instantly get a list of commits that link to the one ticket is the really invaluable feature that I don’t know of any good way of doing another way.

This assumes that writing a ticket causes people to explain their rationale better than a commit comment does. That might be the case, but it often isn't because tickets are filed by developers themselves, or by PMs who just write tickets like: "A system requirement is that users be able to do X" without further explanation.

So people put the ticket number in the message and then don't write a useful commit message. Congratulations, you just added one roundtrip per commit to the slowest website in existence to every single time you want to look at git history.

Did I mention that you can't look at JIRA from a mobile phone?

What's good about it?

Jira doesn't really work well out of the box. It needs a lot of work to configure. I love Jira now, but it's been hell in the other startups. It's probably why stuff like Trello and Asana took off.

There's lots, but I think it comes down to two main things: It has bad defaults, and it can be customized to have really draconian workflow rules.

If you configure it to be reasonable -- keep the workflows very simple with few to no validation rules -- it can be fine to use. The temptation seems to be locking down admin access to managers, and then the admins going crazy building workflows like "these 19 custom fields must be filled out to start" "items must go through a QA step" "QA users are the only people that can approve that step" and "PMs are the only ones that can close a ticket". This quickly gets out of hand and makes it horrible to use.

It also depends on the people using it -- garbage in garbage out, as they say. If people write good tickets (concise titles, format the body, remove irrelevant crap, and properly fill out meta fields like fixVersion) it is much more useful. JQL is awesome, and embedding tickets and JQL queries of tickets into Confluence is awesome (hint: easy way to make release notes) -- but both of these require non-garbage ticket content.

JIRA implementations I've seen don't help people see what's ahead; they focus on what's been done to date. If you're on a single, small team that has minimal dependencies on other teams, that can work, but if the project has any significant dependencies on other teams, it becomes very hard for anyone to understand how things are going.

That’s literally the point of the kanban board. I don’t understand how these projects were configured for that to be true — did they hide the backlog?

Also can I choose my own OS or am I stuck with the "approved" one or two.

You can choose which job to take and you can ask what OS they'll allow you to use before you sign any offer.

It's the first line on my LinkedIn bio. I've gotten no shortage of recruiter inboxes saying they don't use Teams.

I'd rather have Team that Slack or Discord.

After my company switched to Teams, my IT department became much more productive because the amount of needless interaction with other people decreased.

And we were not affected by that shit, since we share the same office anyways. Who needs a messenger when you can shout ;)

How did Teams do that that slack or discord couldn't do? 90% of the features are overlapping. And Teams performs by far the worst at that 90%.

I think this:

> And Teams performs by far the worst at that 90%.

is exactly the reason for:

> the amount of needless interaction with other people decreased.

Simply put: nobody wants to touch teams, so they only do this when absolutely necessary (and even then chances are they will just send an email).

It's not about the specific technologies a company uses, but rather how that choice gets made.

Teams is chosen in companies where the organization is so big that "unification" is seen as a big plus.

What you're out after, are smaller organizations where choices are made based on what people working with those things actually want to use.

So look for headcount rather than what chat program they use, because the headcount will affect more choices than just what chat program you'll end up having to use.

> It's not about the specific technologies a company uses, but rather how that choice gets made

But sometimes specific products are simply less than ideal no matter how they're used. I consider Teams to be one of those.

why on earth would you use Discord in a company setting?

I would rather just go back to IRC.

I've always regarded Slack as "IRC, but non-geeks will use it as well."

This model is not by any means entirely accurate but it's been an extremely effective heuristic.

Slack is worse than Teams, no thanks.

I've used both. IMHO Teams is by far worse than Slack.

This doesn't mean that Slack is better than anything else, it's just better than Teams. Truth be told, even sending a letter by mail is better than Teams.

My company uses both. That doesn’t improve things much but it does give me a good view of both.

- slack great for - huddle collaboration - chat threads - searching chats - focused chat layout

- teams great for - sharing video of eachother - taking control of screen share (no need to futz with asking someone to stop sharing when they already vocally told you to share, most sharers aren’t trying to steal the screen from you as devs) - reactions / emojis when you want to react silently

"surely you're joking, Mr. Feynman"

Teams seems to consistently make me think I’m fat fingering things and I have to go back and type again when I open a new message and start typing. I seems like it’s storing something in a buffer then spewing it async out all at once in the wrong order when it catches up with my input. This happens multiple times a day on a 2017 i7 laptop.

Maybe Teams is an Intel make work program? Have it run slow on all but the most expensive new Intel processors?

Reply on news.ycombinator.com