IMHO Don't blame the tools, it's about discipline, you need to own your time, calendar time for yourself and get stuff done. If management doesn't understand this then time to find a new team.
I've moved my teams away from "discipline" as a solution. How many times has someone said "I'll stop doing this" or "it won't happen again" and then it does?
Discipline might work for one person (usually the one making the rules), but I've found that it's impossible to get a team to be uniformly disciplined. Even if you can do it, it's extremely time/labor-intensive.
There are many tools demonstrating that discipline doesn't work, such as Chrome add-ons that block Facebook. Even when someone understands they need to be disciplined and want to be, sometimes they just can't.
Some examples of replacing discipline with hard boundaries:
- using only languages with static typing
- rejecting commits with messages less than 3 words long
- rejecting commits without tagged issue(s)
- formatters (similar to gofmt) instead of a style guide
"Aww, all it takes is a little discipline." Yeah or I can set myself up to succeed.
Good contribution, rdiddly.
Not if you hire veterans.
Veterans make mistakes, just like all other humans. Sometimes they're sleepy or distracted or don't have enough time to think what they're doing through.
Also, veterans are more likely to have their own ideas about how to do things, and some aren't easy to compromise with.
Either way, why should I leave it up to chance when there are automated tools that prevent mistakes before they leave someone's desk?
Apart from the checklists, which people tend to skip, most of it makes sense. Running everything through a pull request is a good example of something which slows down the process but which is still worthwhile IMHO.
That being said, I really dislike when too many of these constraints are enforced by the technology. In coding, like in driving a car, there are times when common sense overrides traffic rules. Sometimes, even in the best and most diligent teams, the build server turns red. In that situation you just need to quench the fire ASAP to keep it from spreading. You don't want to create a task in JIRA, you don't want to create a branch, you don't want to involve your colleagues in pull requests, and you don't want to wait for a hour for unit tests to pass. You just want to apply the simple fix or revert the commit.
And that's why I prefer moderate social pressure over some algorithm enforcing stuff. A good team will know why the rules are there, they'll be professional enough to stick to them 99% of the time, and they'll also be professional enough to break them the last 1% of the time.
Definitely. It's possible to override any of these things in our setup. Most of them can be overridden by the person doing the coding, but a few of them require the team leader's approval.
If the rules are overridden, it's logged in our issue-tracking system, and we can discuss whether it makes sense to keep the rule or get rid of it.
I've been seeing this meme lately on HN. First it was "Facebook is a time sink". Now it became "If you think Facebook is a time sink that just shows you lack discipline."
No, sorry. Lack of discipline might be the explanation for your private time (Facebook). But as for Slack, you DO have to be a team player. If the entire companies uses Slack you can't just not. If people are pestering me because I'm not responding, that's not my lack of discipline.
Again, Slack is just a tool. I have no problem with it, but maybe that's because I work in a company that has a healthy relationship with Slack, and I make generous use of its features to let me focus on what's relevant and interesting to me.
But, getting to the core of the matter:
> You can't mute the whole organization.
No, you can't. And you shouldn't. That's literally the whole point of organisations. If the particular mode of communication a given organisation uses isn't good enough, think about how to make it better instead of just brushing the whole thing off. We worked this out with phones, email and mobile phones. The discussion here is ripe with people saying "if it's important, they'll call me". Well, 20 years ago, mobile phones were given the Slack treatment because it was horrible that anyone could just call you.
Some bosses seem to reward underlings who respond to email at odd hours, yet nobody struggles to understand that it's toxic behaviour instead of writing diatribes about who we should stop using email altogether (although people did write those in the 90s). I heard of an organisation where the rumour was that some members of senior management would stalk employees' calendars to see if they were keeping busy. Good thing that organisation was able to end that kind of ridiculous Goodhart style management by ending the use of calendars!
Figuring out the correct balance between doing directly productive work and paying the overhead tax that goes with collaboration is hard. Just like no single tool will magically fix it (hello, Jira), no tool magically destroys it.
I don't know what kind of place you work at, but being a team player isn't measured by always being on Slack.
> > But as for Slack, you DO have to be a team player.
That was the point of my original comment: in one of these organizations, the fact that I struggle to work because I have noise coming from Slack that I'm expected to respond to is NOT my lack of discipline. The person I was responding to just took a fashionable meme on HN which was originally meant for Facebook and mindlessly applied it to Slack. Not applicable.
It's the external expectation to respond that I interpreted as "being a team player as measured by always being on Slack".
Being a team player, broadly defined, isn't incompatible with muting Slack or otherwise managing the noise, and that then comes back to the "discipline" idea. If a person don't mute Slack because they "like" the distractions, then they have a discipline problem, if the organisation doesn't let them mute Slack because a "team player" always responds in three seconds or less, they the organisation has a discipline problem.
Coming back later really doesn't help (at least for me). Because chats are interspersed throughout, you can't really follow/search anything.
I have enough friends who've hacked on Zephyr, and they tend to get such a look of horror on their faces when talking about that protocol and codebase, that I'm pretty sure that was the right approach for us. :)
It really was/is a fantastic social product, though.
TL;DR: If you proudly state on your features page that you have "First class threading on top of everything you could want from real-time chat", then give a good explanation of what makes it first-class and why it works so well. Don't assume that everyone who visits your page has already tried out a dozen other modern chat programs and therefore is familiar with all the UI idioms. I don't know if that is arrogance or naivety, but it's wrong either way.
So my goal is a quick overview of the UI and a feeling for the UX. How it all comes together, how it flows when used. I have no interest to first install it and explore it to do so, and that would require having conversations and discussions in it, and I don't feel like convincing a bunch of friends to give this a try and make them invest time in testing it.
First, the Zulip webpage (which has a broken back-button.. great). The features page proudly opens with "First class threading on top of everything you could want from real-time chat."[0] Great, so how does that work? No explanation, it just lists all the other features - the "everything you could want" bit - without every going into detail on the conversational threading UX.
Yeah, those features all look nice, but you're not telling me why the threading is better than elsewhere.
Ok, well, if I search on YouTube for videos, I'll probably find a video of some nerd trying to convince me Zulip is better than anything else and why. Although I don't like it when companies lean on that kind of "implicit crowdsourcing", so I am already slightly annoyed.
Turns out that there isn't much on YT either.
A lightning talk by one of the devs, talking about organisational structure and culture of an open source project[1]. Great, but not what I need right now; the fifteen second overview of the UI (with an implicit "you're already familiar with this stuff" tone) does little to help me.
What else? A series on how to install Zulip[2]. No discussion about the interface itself, so same problem. The remaining search results are either promotion videos of other chat platforms, or screen captures of people complaining about bugs in the Zulip app[3]. So far, the latter are the closest thing to something informative: at least it shows the app in action, and since the narration explains what is broken, you also hear what the expected behaviour is. Still not very useful.
As a last resort, I dive into the (extensive) documentation[4]. It lists everything you might want to do with the chat ("how to set up an account", "how to edit a message") and is very extensive. That is great in itself, since it lets people find answers to these specific problems, but I am still missing a good explanation of how it all comes together.
Ok, fine, I'll dig through the docs myself and try to get a picture of the app. Clicking through it I see a lot of things that are familiar from other chat apps. But when it comes to the threading, I find only a few spread-out paragraphs somewhat explaining how Zulip organises its chats:
> Zulip is a group chat app. Its most distinctive characteristic is that conversation within an organization is divided into “streams” and further subdivided into “topics”, so that much finer-grained conversations are possible than with IRC or other chat tools. [4]
> Messages in Zulip are organized into streams and topics. Streams are similar to chatrooms, IRC channels, and email lists in that they determine who receives the message. Each conversation in a stream also has a topic, which plays the role of the subject line of an email (though topics are usually shorter, e.g. "logo" or "logo design", not "feedback on the new logo design?") in that it organizes messages into threads. [5]
> In each stream, messages are sorted by topics. Topics are specific, fine-grained subjects that fit with the overall subject of the stream that they're sent to. Topics ensure sequential messages about the same thing are threaded together, allowing for better reception for users. [6]
As far as I can tell, that's it.
COME ON! So the whole thing is that you have a conversational tree that where for each topic ("streams"), you can have one extra sub-topic ("topics")? So it's essentially just forums and subfora, but with different user interface based on chat idioms?
And I can figure this out due to previous familiarity with this kind of software. I guarantee you that this is still pretty mystifying to people less tech-savvy.
OK, so now I wonder: how to start a topic then? I see pages on how to start a stream, how about topic? There is one about editing one[7], or viewing all messages about a specific topic[8]. Nothing about starting a topic though.
There has to be one, of course, since you can't use this software without this. Dig through the docs long enough, and you'll find it under "Send a new stream message"[9]. No hint that this has anything to do with starting a new topic.
What?! Why is it called "sending a new message"? I guess that in Zulip-idioms, a new message is different from replying to another message; the latter implicitly subscribing to that particular topic. Starting a new message in a stream means defining a new topic.
So in order to figure out Zulip-logic, I must already be familiar with Zulip-logic?! WHAT THE HELL PEOPLE. You cannot expect this from new users. Just call "sending a new message" what it is: starting a new topic. Or make an alias that forwards from one page to another, like merged pages on WikiPedia, or whatever, but not this.
Zulip looks like a great app, but this is ridiculous.
More developers/designers should read https://news.ycombinator.com/item?id=6429848 and ask themselves whenever they develop/design something: "would this way of explaining intimidate the elderly, or anyone else who is less comfortable with technology than me into thinking they are too stupid to use computers?" If you're not somewhat thinking about that, you're doing it wrong.
[0] https://zulipchat.com/features/
[1] https://www.youtube.com/watch?v=lXFO2ULktEI
[2] https://www.youtube.com/watch?v=-qh55hxfGDM
[3] https://www.youtube.com/watch?v=fnXZJSRPy0A
[4] https://zulipchat.com/help/
[5] https://zulipchat.com/help/getting-started-with-zulip
[6] https://zulipchat.com/help/about-streams-and-topics
[7] https://zulipchat.com/help/change-the-topic-of-a-message
I encourage vanderZwan and others to come to https://chat.zulip.org/# to talk to us. We're real people. We like the app we've developed, but we know it's far from perfect, and we especially know that our marketing could use some constructive feedback.
You have my respect for taking it in stride and listening to the critique! I already mentioned it does look like a good app, and based on skimming through that lightning talk (not to mention this reply by you), the dev community behind it looks open too.
Slack threads almost got me fired. Long story short: I requested leave for a couple of days, by posting in the #leave channel on the company slack, as is company policy. A week later I was sick and took a day off work, that same day my boss (who works remote to the rest of the team and was separate to my supervisor) denied my request, by posting a reply and starting a thread on slack. The next day, when I came into work, my Slack was filled with unread messages and comments. I checked my DMs, and just marked everything else as read since it was mostly people mentioning @channel. Because I only checked my DMs I missed this reply to my request for leave. I only discovered the day before I was due to leave that my request was denied, when one of my colleagues mentioned it to me. I then proceeded to go on leave, which work wasn't too pleased about. I was basically asked to resign, which I did because I was planning on leaving the company anyway.
There were a few problems caused by slack here (as well as my own failings).
Slack has too much noise. After only a day away, I was inundated with messages, and no easy way to sort the wheat from the chaff. This can be mitigated by good management and company policy. Using @channel to chat about your plans for the weekend is not appropriate use of @channel.
With email, I would've gotten a nice list of unread emails, which I could scan down and automatically delete the ones I don't care about, and I would've clearly seen the email titled "re: leave request". Slack DMs also lack any kind of subjects or threads, so it's not possible to send leave requests to a manager with a subject heading, if company policy required me to put leave requests in as a DM, it would sit in a single threaded conversation with my boss along with all my other messages.
I think that slack is a good tool if used properly and appropriately. @all or @here should be used sparingly, and for important messages. DMs shouldn't be used for anything serious. It shouldn't be company policy to have a #leave channel where you post your leave requests, where your boss can publicly second guess your requests for sick leave. It all comes down to how its used. Slack is great if I need to send a quick message to a colleague, or if I need to post a comment in a channel where a prompt reply isn't required.
Slack does try to advertise itself as an alternative to email though, which is BS. It's a tool to use beside email. It's just like how IRC didn't replace email, neither did Skype.
First that a company would deny a vacation request. Vacation is something that you schedule with your manager, not that you ask for. It's vacation. Of course you're going. You're just letting them know when.
Second that anybody would try to have such an obvious email conversation over slack. That doesn't seem like a good use for group chat. For the reason you describe.
Good on you for escaping that place!
I think that this solution came about because the company had a very strong dislike of email for some reason. All support was done using Intercom.io, rather than email and all company communications were done in Slack. I don't think I sent a single email in the 2 years I worked there.
Being able to create a direct message with a topic would've been the ideal solution, which is literally what email is.
One common reason is simply boots on the ground, can't have everyone take the same day off. Deadlines, if I ask for leave in the last week before a deadline.
You might be thinking from a programming perspective but imagine your whole support team taking the same two weeks off.
There are loads of reasonable, practical, reasons to deny leave. Every company policy in the UK will usually clearly state don't book tickets, etc. until approval.
Vaguely related, here in the UK there are people who get a bad rep for being greedy by blocking off certain holiday before other people as soon as the year gets 'released' e.g. booking every Friday before a bank holiday Monday off, so no-one else can. Good managers will shut down that behaviour and tell them they can only take X of them, as it causes resentments.
Even if it is there, the affordances of the UI[1] don't seem to encourage this style of conversation. There is a huge difference between something being theoretically possible for expert users, or intuitively embedded it in the mode of conversation.
Mind you, I'm not saying that hierarchical trees are a panacea. I think human conversation is much more similar to the way branching and merging works in distributed version control systems, but I can't see how one would easily make a conversational UI based on that.
> Even if it is there, the affordances of the UI[1] don't seem to encourage this style of conversation.
I agree. I never use the feature personally.
As in, it proves nothing except it's an ineffective product for what humans use it for. Same as we'd say if Slack wasn't around -- "is IRC really the best way for us to do this?"
No. Of course not. We don't live in a best-case world, however; the relevant question to their user base is "are we helping you more than alternatives?", and for an entrepreneurial community like HN, "what does the better solution that solves the same problem look like?"
It still allows you to have a conversation with the people who are there, with the added benefit of people who walk in later can still see it and chime in.