Servo: Parallelizing the Browser - <AUTHOR> http://www.joshmatthews.net/fosdemservo/ <comment><USER2> I wonder if Servo is advanced enough to get some performance numbers on large pages compared to other engines. In any case, I'm looking forward to see what becomes of it. Like Rust, it seems a well thought-out approach to solving difficult problems.

<comment><USER3> My intern, Laleh Beni, gave a talk last week where she compared the performance of Servo on a synthetic benchmark to that of Firefox on Android: [https://air.mozilla.org/servos-power- struggle/](https://air.mozilla.org/servos-power-struggle/)

We're not publishing comparisons with other engines for now because we don't support the full web platform yet in Servo and it doesn't make for a fair comparison against them. Certainly, we benchmark against other engines internally and try to ensure Servo's page load times are at least as fast as the other engines. That said, we don't have incremental layout yet, so Servo is _way_ behind on any measurement involving dynamic page updates.

Lots of good progress, but we also still have lots of work to do!

(shameless plug to solicit contributors: [https://github.com/servo/servo/blob/master/CONTRIBUTING.md](https://github.com/servo/servo/blob/master/CONTRIBUTING.md) )

</comment></comment><comment><USER4> Video: [https://archive.fosdem.org/2014/schedule/event/servo_buildin...](https://archive.fosdem.org/2014/schedule/event/servo_building_a_parallel_web_browser/)

</comment><comment><USER5> (slides)

</comment><comment><USER6> I just don't understand the justification for this.

> pre 2000

I'm pretty sure a lot of good technology is written pre-2000. Why you'd want to throw it away is beyond me. Just because something is old doesn't mean it's outdated.

> difficult to experiment or fundamentally change

Generally with mature products this is true, so the solution is to use an immature product? Why not just take the time to learn the existing products so that you can experiment or make your changes.

> security and performance are hard

It's always been that way, and it always will be. I doubt a new library/platform will change that. The only thing it will do is make the developer an expert on the system (since she designed it).

The diagrams don't make sense, and seem to miss the point. Not all scripts will cause the layout to change. Some may, but the renderer shouldn't be controlling the script, except in extreme or very specific cases.

<comment> vertex-four It's a research project. Maturity has nothing to do with it. There's literally no plans for Servo apart from research.

> It's always been that way, and it always will be. I doubt a new > library/platform will change that.

Except that we have ridiculously few memory-safe systems programming languages. Rust is one, I _believe_ Ada is another. Provably memory-safe code means no more stack/buffer overflows, no more writing to random bits of memory, and in Rust's case it can be for almost free.

<comment><USER7> Ada isn't memory-safe with dynamic allocation (unless you use GC). Dynamic allocation is essential for a Web browser.

</comment></comment></comment><comment><USER8> Holy crap, the background image for that presentation slides is 780KB and the background image for the page is 786KB

[http://www.joshmatthews.net/fosdemservo/themes/mozilla/image...](http://www.joshmatthews.net/fosdemservo/themes/mozilla/images/bg- darkgrey-2.png)

[http://www.joshmatthews.net/fosdemservo/themes/mozilla/image...](http://www.joshmatthews.net/fosdemservo/themes/mozilla/images/bg- sandstone-2.png)

Think of the mobile users!</comment>


Slack is the opposite of organizational memory - awinter-py https://abe-winter.github.io/plea%27s/help/2018/02/11/slack.html <comment><USER4> My worry is that if Slack is replacing your documentation, then it may be that your organization did not have good (or any!) documentation that predated its use of Slack. As such, I'm not sure if that's a fair thing to criticize of Slack.

Slack is a tool for productivity. (Go on––I'll give you a minute to laugh.)

Slack does make it easier to talk to people, particularly so in a group setting. Any company can make use of that; if you are a remote company, you need that. JIRA and Trello are also mentioned as "hates", but these are also tools that make it easier to work (notably, to make it easier to organize and catalog work). If you aren't using them, you've probably written a hack that does something like them, only worse.

<comment><USER5> > _if you are a remote company, you need [to make it easier to talk to > people]_

From the article:

> _Remote work culture is a defense mechanism against the distracting open > office, and slack is the end run around that defense mechanism._

Slack kills off any benefit there is of being remote, because it is immediate: you need to be online all the time, and you need to answer / participate / chat instantly.

A good alternative to Slack would be a Reddit-like interface with threads and an asynchronous model. That's also the superiority of email over any chat solution. I don't understand why people and organizations get so excited about real-time conversations.

We always had real time. Cavemen had real time. Writing was invented to free us from real time, to transfer information in non-real time and to future generations.

But now it seems the cavemen are back, with a vengeance.

<comment><USER6> This is an important original post, and I wish the Slack community were having these conversations more often and openly.

The original post nails some important issues: companies really need topic focused discussions, intentional, thoughtful writing, not just chat, more asynch so there is time for deep work and time for more thoughtful discussion and replies, and much better, topic-based search.

I believe in the impact of this problem so deeply that a team of us have been working on an open source solution to it for a couple years now. [https://github.com/open-company](https://github.com/open-company)

What we're trying to build is a place for companies to have focused, asynch discussions about the things that really matter, outside the stream of chat. The UI we've come up with isn't "Reddit-like" really, but it's an attempt to supplement Slack with what's missing, and it will evolve as we learn more.

If anyone is interested in trying it out, you can sign up for early access (we'll get you in very quickly) at: [https://carrot.io/](https://carrot.io/)

<comment><USER7> I don't see how you can ever get something named carrot out of beta (carotene). Your product looks a lot like Yammer (which we have in addition to slack, XMPP and email) in that there are threads. Threads make Yammer better than Slack but there are still two things that I hate (and that Google/Apache Wave got/gets right): 1) Comment threads are hierarchical so side conversations can happen in-line but also be out of the way. 2) Blips that I've read or that I'm not interested in can be collapsed.

The best conversations in Slack should really be a conversation in an issue tracker. Unfortunately, nobody will see those comments when they look at the issue. One issue I see with the carrot UI is that there's not really enough room to have a real conversation in the comments side-panel.

</comment></comment></comment></comment><comment><USER8> I'm very comfortable typing /mute in noisy channels and coming back later. I'm also happy to close slack when I need to be in the zone.

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.

<comment><USER9> > _it 's about discipline_

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

<comment><USER10> \- not having a bag of goddamned Oreos in the house when you're on a diet.

"Aww, all it takes is a little discipline." Yeah or I can set myself up to _succeed_.

<comment><USER11> This seems to me like an incredibly good example, and I've no idea why people would be downvoting it. The GP programming / technical examples are potentially easier for the reader to think "well sometimes I'd want to break that rule because X", whereas this example makes it obvious, and brings up "setting yourself up to succeed".

Good contribution, rdiddly.

<comment><USER10> Thanks, yeah the point is to use discipline further upstream. Use discipline once at the outset to permanently avoid influences that require discipline over and over again.

</comment></comment></comment></comment></comment><comment><USER12> It's an interesting argument. When I hear it, I interpret it as "I'm too busy doing stuff to help anyone else do stuff."

The people who do this, from my experience, are also the people least likely to write tests, documentation, comments, or self-explanatory code. Then, when someone makes a mistake based on misreading this member's code, they are labeled as "incompetent."

I agree that Slack has created an interruptible culture, and I'm not a fan of that, but we have yet to make a tool that transfers knowledge without either human contact or extensive documentation. Structured distraction is the alternative - we call them meetings.

Nobody likes meetings either.

<comment><USER13> I like how you gloss over documentation as if it's not even a viable solution.

Documentation isn't hard to generate. Set up a wiki so you can document things there, move your internal "how do I do X" chatter from Slack to email lists and maybe a StackExchange installation, and you end up with multiple indexable, searchable sources of long-form documentation.

Sometimes, documentation is work. So do the work. People and organizations who avoid that kind of work and say "just use Slack" end up trading 1,000 hours of interruption over 1 hour of work.

<comment><USER14> Everywhere I've ever worked, "set up a wiki" has meant "create something once that nobody ever remembers the existence of"

<comment><USER12> Or, it accumulates so much cruft that it's hard to find the valuable information. I think there's room for documentation librarians, whether by role or job title, but it's hard to justify the expense in smaller organizations.

<comment><USER15> I found that a bit of scripting will make a wiki a bit more maintainable. Replace pages that are out of date with a tag of some sort (e.g. #outdated). Have a script spider the wiki from the home page and send out an email with all the reachable pages with tags. Either fix the page or make sure it's no longer reachable.

<comment><USER16> Pro librarian work right here, Nice work!

</comment></comment></comment></comment></comment></comment><comment><USER17> >Another JIRA flaw: highly formalized process is usually a hindrance, especially considering who in your organization invents, applies and benefits from process. Hint: middle managers.

This just reads as someone who hasn't had to actually think about what is being built, and who is paying for it. Effective teams are more than just "developers write and push code" \- it's about being able to predictably say we are implementing this feature (or fixing this bug), therefore it will be available to customers at X time. As organisations grow, it becomes more and more critical to be able to predictably forecast the work that teams will complete, so that the right work can be planned out and roadmapped.

I had plenty of problems with this article, but this one stood out the most.

<comment><USER18> Your interpretation of the quote is that middle managers don't provide value, but I think that may be too broad. I understood it as "highly formalized process often rewards middle managers", which I do think is true.

The best manager I was lucky enough to report to personalized his approach to his direct reports. He recognized that some people are more creative, others prefer more structure, etc. He still had his responsibilities, e.g. report progress on project X and estimate completion, but this was abstracted away from the team. For all we knew, we each had an area of the system we were responsible for, and we had longer-term collaborative projects that would take on the order of months. I didn't realize how great of a manager he was until I had other managers who firmly believed in the One True Way™ of managing projects, and also pretty much required everyone to be heavily involved in it. (Give estimations for things you haven't worked on, and move tasks as you get to each stage of development.)

Getting back to my original point - highly formalized process often rewards middle managers because it simplifies work for them. Everything is already tracked in the system, it's a matter of moving around and allocating resources. But why does everyone need to be involved in this? Why isn't heavily formalized process compartmentalized to just managers and the people they report to (and maybe their reports that enjoy that process)?

I recognize the value that managers bring - otherwise every individual contributor becomes a mini-PM - but I also believe that the best managers put in the work. They build good personalized relationships with each member of the team, and are able to compile estimates based on their interactions. It's not always a cold science in the vein of "since Alice has 13 points out of a maximum of 18 points per sprint, I should try to allocate 5 more points - <AUTHOR> biggest task that fits into that is 4 points, so let's assign that to her."

<comment><USER17> >Your interpretation of the quote is that middle managers don't provide value, but I think that may be too broad. I understood it as "highly formalized process often rewards middle managers", which I do think is true.

I agree, but I don't think that's a bad thing - I think something that rewards management, rewards the team as a whole. If the PO/PM overcommits, it's the team as a whole who suffers. Likewise, if targets are smashed, the team gets recognition.

As such my interpretation wasn't that middle management is bad, but that formalised development processes are bad, which is what I fundamentally disagree with.

Businesses as they grow end up having abstractions on abstractions. Formalising development processes allows for the business to actually be aware of what it's doing, how effectively it's being done, and where opportunities lay for improvements.

Don't get me wrong - too much management creates warrantless red tape and frustrations, however standardising the development process through things like Jira (which the author was complaining about) doesn't fall into that bucket (in my opinion), especially when the author compares that the same can be done with a blank sheet of paper - if senior management want a rough understanding of the roadmap for the next 12 months, why would you "forecast" with some guessing on paper, over actual proven data of this is roughly how this team performs, this is the rough estimates on these initiatives, ergo, we can commit to these X projects.

</comment></comment></comment><comment><USER19> Thing is, I have always used IM in one form or other for work. Slack is finally one that can handle code snippets well.

It's not worse at interruption than any other IM (and you can tell it to shut up, so), it does not replace documentation, and it does not solve any organisational problems (it's a technical solution, how could it).

What it is, however, is a chat client that can handle code snippets well. So yay for that.

</comment><comment><USER20> If not Slack, then what? Nothing?

I work as part of a fully remote team and I can't really imagine not using Slack.

Generally we discuss in Slack, immortalize in GitHub issues (using ZenHub, thank god), and do ad-hoc video calls for screen sharing and whatnot. Announcements and such usually go out as an email blast.

I'm really curious what life would be like using email/issue comments only. Obviously this must be possible since so many open source projects operate this way, right? But they also have a totally different organizational structure.

Any insights, HN?

<comment><USER21> Remove asynchronous interruptions and go back to old-fashioned synchronous interruptions (scheduled meetings, either in person or calls/video chats) for the stuff that requires high-bandwidth communication and asynchronous non- interrupting queues (emails, or other similarly-shaped things like tickets or wiki page edits / comments) for the stuff that requires low-bandwidth communication and more intensive thought / work.

If you need asynchronous interruptions, pre-Slack and even pre-email culture had ways to do this - phone calls, pages, knocking on people's doors - <USER2> they were viewed as rare and exceptional, and the coworker who would knock on your door all the time to ask if you saw the message they just sent was viewed as rude and distracting.

<comment><USER19> I'ld much rather be IM'ed or emailed than called or paged. If I am called, the phone rings or the pager beeps, and I have little choice but to interrupt my work. My slack client, on the other hand sits in the system tray, silently displaying a little blue or red dot. I can open chat when I feel like it, or ignore it until such a time when I am not concentrating on something else.

Asynchronous communication is empowering: You can choose when you communicate and when you want to concentrate. Synchronous communication does not afford you that luxury.

<comment><USER21> Why is using Slack in this workflow superior to using email? I also know if I have unread emails via the tray icon or mobile app badge, same as with Slack.

Is it just that short frequent messages in email feel weird?

<comment><USER19> That, the superior handling of short-message group conversations and the fact that the number of people who could email me is vastly greater than my team members on slack. As such, I tend to check slack relatively frequently, while I check my emails only twice a day - I do not have push notifications enabled for email. Basically, slack means a usually-within-2-hours response time, while email means same-or-next-workday response time.

</comment></comment></comment></comment></comment><comment><USER22> You should try Twist ([https://twistapp.com/](https://twistapp.com/)). I switched to Twist with my team and haven't looked back at Slack. Twist organizes discussions around tasks. When the task is finished, that conversation is pretty much over.

Read this post by Amir, the founder of TwistApp - Why We're Betting Against Real Time Messaging - [https://blog.doist.com/why-were-betting-against-real- time-te...](https://blog.doist.com/why-were-betting-against-real-time-team- messaging-521804a3da09)

<comment><USER23> I saw the twist video. And it seems just like slack. Slack, but guys please observe discipline. The UI, design, philosophy everything is identical to slack.

You feel forced to respond to slack chats, so just chill and respond only when you want to. This is literally in the video.

The thread loses track of the topic, so we have exactly the same hierarchy and groupings like slack, but guys please just use the thread for the topic only. This is literally in the video.

Chats are annoying and people keep disturbing you in slack. We have "messages", perfect for small groups and individual conversations. Again, exactly like slack, but let's all promise to be not annoying.

The UI and app look great, I can see that folks really worked hard on this thing. But there is zero differentiation from slack. It looks like somebody took slack, re-colored it, and put "calmer and more organized" on the website.

<comment><USER24> > The UI, design, philosophy everything is identical to slack.

This isn't quite right. The way Twist shows threads and information is a lot closer to email, and there's a big difference in how it organizes information: on top of channels, which are based on groups or projects, it has threads as a base organizational unit.

UX does influence behaviour, afaik. The Twist UX facilitates and encourages long-form, on-topic discussion a LOT more than Slack. See also email: have you ever used email like Slack?

imo the main issue is actually that email + some mailing lists still has major advantages over Twist.

</comment></comment></comment><comment><USER25> In my organization, github PR threads and JIRA comment threads tend to be ignored or forgotten after their inception, and chat gets results right now. We also use Trello, Confluence, google docs, and of course email for some things. I think this sort of thing is common.

They all have their strengths and weaknesses, but it strikes me that a bigger barrier to productivity and strong organizational memory than interruptions is the overall dilution of information.

Sometimes I think that the narrowing of the available tools (channels for information), whatever the weaknesses of the chosen tools might be, would be wise.

</comment><comment><USER26> We've found this to be partially true in our very small startup. The unstructured nature of Slack conversation do make it hard to go back and reference something that was said only a few days ago, however we have found that the search tool has been very useful in locating a decision or rule that was made a while back in casual conversation.

By and large, the biggest problem we have, even with a handful of users, is the fact that everyone tends to just use Slack as an ideas repository, and bug tracking/feature request tool, rather than log it in our actual Phabricator development tracking tool.

Also, we have (I believe) gone a little overboard with integrating our other tools into Slack (including Phabricator, AWS, Stripe etc.), so we are almost at a 1:1 ration of bot generated messages to user created messages at the moment - leading to a lot of inadvertent mental filtering of channels, resulting in missed (human) messages.

</comment><comment><USER27> As time has wore on our organization has relied on slack less for team collaboration and more for monitoring.

Admittedly, the slack client is great at cross platform notifications and we leverage those in our monitoring processes, where alerts are sent via zabbix to pagerduty and slack simultaneously via webhooks.

In a real sense the responders have "any activity creates a notification" which enables them to react and others to view a record of what happened. This eliminates the casual "what happened?" conversations.

We've yet to have an oncall event fall through the cracks.

</comment><comment><USER28> Before Slack it seemed like everywhere I worked had chat and IM anyway -- it was just a thinner experience. As a programmer I have mixed feelings about making a point about "distractions". On one hand I'm sympathetic and think people need to be more conscientious... but I also think managing distractions is an important skill as a programmer, and there are a lot of people that seem to relish in acting professionally flustered all the time. At the end of the day sometimes answering questions and coordinating with people is the important work -- even if it might be frustrating.

Also, I mean, you can just turn it off or mute the notifications. I see people do that all the time and nobody cares.

<comment><USER29> Love your last point; I'd respect someone who'd mute notifications and treat it mainly as an asynchronous communications tool.

Combine it with an Urgent channel if need be, where notifications are On, and tell people off for posting crap there..

</comment></comment><comment><USER30> [shameless plug]

This is exactly why we at FastMail made Topicbox! Email is your personal memory, and it made sense to extend that to organizational memory by making mailing lists not suck.

And we switched from IRC to Slack for our internal comms a while back, so we know the pros and cons :) Chat's great for real time, but not for long-term memory.

[https://www.topicbox.com/](https://www.topicbox.com/)

[/shameless plug]

</comment><comment><USER31> As a technical writer I have a big problem with Slack. It seems like a black hole of unfindable knowledge. I stick to Stack Overflow and mailing lists when I interact in my product's communities because they are streamlined repositories of linear knowledge.

A moment of gratitude to Stack Overflow and mailing lists!

</comment><comment><USER32> The problem I have with large group chats like Slack, Riot, IRC is that it's hard to get information from them when you've been "out of the loop" for a while. Much better to read a bunch of forum threads or tickets, then trying to make sense of a long scrollback.

<comment><USER33> You shouldn't be trying to. Slack is a tool used for raid iteration, not an event / decision log. Unless you establish some strict conventions, like having an announce / decision channel with very restricted traffic, you should still record important decisions somewhere else, and give that to people when they need to 'catch up'.

<comment> white-flame That doubles the authoring workload, though.

If you're talking on something like a forum, with individualized contextual threads, then those are already auto-categorized for reference later.

I guess the equivalent would be to start new chat channels per topic, and index them somehow? But realtime chat tends to have more organic topic drift than post-based discussion.

<comment><USER32> > I guess the equivalent would be to start new chat channels per topic, and > index them somehow? But realtime chat tends to have more organic topic drift > than post-based discussion.

Well said. It's a shame IMO how much forum software has deteriorated in innovation post 2010 or so. Discourse is nice, but not my cup of tea when compared to the layout of "classic" forum software, phpBB, SMF, etc.

<comment><USER34> Classic forums software was pretty much a web based NNTP gateway -- some even supported nntp integration directly. Posts were threaded.

Then along came unthreaded forums in late 90s/early 00s. Things like phpBB are not my cup of tea when compared to the layout of usenet or slashcode.

<comment><USER32> > Classic forums software was pretty much a web based NNTP gateway -- some > even supported nntp integration directly. Posts were threaded.

Ah. We have a different view of "classic forum software". NNTP was before my time.

</comment></comment></comment></comment></comment></comment><comment><USER35> There are 3 primary types of documentation that a growing organization needs :

1\. Onboarding 2\. Runbook / Troubleshooting 3\. Notes and ongoing developer wisdom

Slack helps with #3, but is not what #1 and #2 require.

New hires should not be digging through slack to get up to speed, and ops or engs trying to deal with catastrophe in the wee hours should have playbooks, not try to dig up what worked last time in slack.

<comment> awinter-py do you have any recommendations for good runbook tools? I'm on the market for one of these.

<comment><USER36> a wiki?

<comment><USER35> Yeah a wiki should suffice. Having a good runbook is a process that needs to be tended to every time devs and ops deploy, troubleshoot, and configure services. More of a process than a tool, because it should integrate with all the tools already in use for deployment, logging, debugging, etc.

</comment></comment></comment></comment><comment><USER37> I wonder if disabling search and restricting chat rooms to a limited buffer would help encourage people to see Slack as a lossy chat service and not an appropriate data store. You would be forced to decide what's important to keep and keep it somewhere.

I especially don't like when Slack is used as an official record.

<comment><USER33> Why?

It is a great advantage of slack over email / in person that you can later find two people you've never met discussing something similar to your problem, follow their historical discussion, and possibly find a solution.

Or even your own previous conversations for issues deemed too minor to record in a more 'official' record (like a jira ticket, or project documentation).

<comment><USER13> If you have an internal wiki, email list archives, and maybe an internal StackExchange and set up an ElasticSearch cluster over the whole works, you can answer pretty much any question in a one stop shop.

<comment><USER33> None of those do interactive collaboration like debugging very well. You could copy the result of the collaboration into something like that, but actually getting people to do that is not trivial. If the collaboration happens on slack, you get at least some searchability.

</comment></comment></comment></comment><comment><USER38> For large organizations, a forum/ticket model is a much better way to leverage organizational memory and knowledge.

For small teams, and teams within organizations, I actually think the Slack model does fine _if_ people mute it. I'm one of those people that loves to help people with technical challenges and this was a big hurdle for me. Almost all of the problems in the article can be solved by muting and only checking during breaks.

I don't think anyone rational would conflate productivity with availability on slack unless their job is to answer questions on slack. It's also just such an obviously bad idea to forgo documentation in favor of Slack that I'd say no rational developer would do that either. Those aren't problems with Slack, those are problems with lazy people who want to blame Slack for poor software development.

</comment><comment><USER39> For all the hate Slack gets, it works great for me. Yes, you can be interrupted, but you can also ignore it very easily. Without Slack, I'd have people coming up to my desk and asking me questions, which would _really_ be distracting. Maybe I work in a company with a good culture, but the middle managers don't use Slack in the way he describes. Sure, managers can act that way, but they don't have to. And in my experience, they don't.

I don't understand his comparisons to Trello and JIRA. Those are project management tools. Slack is a chat tool. Completely different things. And his complaint that it's a bad tool for documentation also rings hollow. It's a _chat_ app. Is he also going to complain that his hammer it a terrible tool for tightening screws?

<comment><USER40> Yeah, maybe Slack is bad in OP's workplace. But in mine, it's been great for increasing communication in an all-remote developer company. JIRA is used for task management, docs are stored in the same repo as the code, and Slack is used just to talk to people or solicit opinions. No one ever uses @here because none of us want to be bothered either.

I feel like most of the complaints on Slack are either because people use it as something other than logged IRC, or because it's getting misblamed for other company culture problems.

</comment></comment><comment><USER41> I've often thought about using good old NNTP as a replacement for Slack. It does everything I want from Slack in terms of structured conversation and preservation of information. At the same time it doesn't have the same real- timey feeling (that the OP refers to as urgency).

</comment><comment><USER42> There are two types of memory: long term memory and short term memory. Slack is short term memory. Both kinds are important -- short term memory without long term memory is amnesia.

<comment> awinter-py I like this metaphor. Thanks for posting.

</comment></comment><comment><USER43> Ai yai yai. People need to stop adopting tools thinking it'll be the panacea of communication and organization. Insofar as the author says that I agree.

But I think it is equally short sited to blame the tool.

Whatever tool you choose, you have to FULLY adopt. Everyone has to be bought in, learning the features (like do not disturb), setting ground rules which make sense for your company and how people within it like to get things done.

Seriously, I never felt more productive than when I used Trac, I don't think issue tracking has really evolved much more than that save useful social features and code review (essentially what killed Trac because the Git integration was never very good).

When I look back as to why that was, I realize it was because the WHOLE COMPANY was bought in. We all used it, we all used it well and respectfully.

This is the madness of the agile world. Viewing the tool as the solution rather than just that, an implement, a ways to a means that starts before its usage and and ends after its usage.

> Remote work culture is a defense mechanism against the distracting open > office

Disagree as to the reason remote work has become a thing, but I _do_ think it's largely because video conferencing works better every year, tools like Slack exist, and code review tools can be done line-for-line remotely.

But, has anyone seen the Slack diagram for whether or not to send a message? It is extremely well thought out, but settings can't be useful if you don't set them.

> Chat, at least on slack, isn't grouped or threaded.

Yes they are, now.

> ...non-trivial to know what the current topics of conversation are in a > slack channel or to assign one of those topics to any given message.

Then speak up and tell people to stick to the topic, change it, or open a new room.

> ctrl-f, the one constant of web interaction, is broken in channels if you're > searching more than one page up.

Use the Slack client

> Middle managers will make deliverables....

And here is where I stop reading. This is an organizational problem you see manifesting on the tool and you are incorrectly assigning blame to the tool.

\--

You have to be committed to using whatever tool is chosen. Just choose one and actually use it.

These tools are a discipline _not_ a freedom from discipline.

<comment><USER44> >Use the Slack client

I know it's technicalities, but sadly this isn't possible for everyone. Closest thing is using the IRC gateway, but at that point your company might as well be just using IRC...

<comment><USER20> Why is this not possible for everyone?

<comment><USER21> The internet suggests that the official desktop/web client is not particularly usable with a screen reader:

[https://www.marcozehe.de/2016/01/16/status-of-the- accessibil...](https://www.marcozehe.de/2016/01/16/status-of-the- accessibility-of-slack/)

[https://slackhq.com/designing-slack-for- everyone-456002920bf...](https://slackhq.com/designing-slack-for- everyone-456002920bf2) (talks mostly about the mobile clients, which were designed later)

Maybe this has changed recently?

</comment></comment></comment></comment><comment><USER45> Positioned as a tool for collaboration and productivity, how can Slack legitimately be that when it is designed for online, synchronous communication?

Is it really collaboration when members in a channel do not have a chance to prepare or struggle to participate at that pace?

What is productive about Slack? Perhaps you get questions answered through the tool, but you do not produce through Slack. I think of meetings as productive when progress is made on a problem or a decision is arrived at. How does Slack facilitate that better than scheduled meetings?

I have generally stopped using Slack. If a conversation takes longer than three minutes to conduct on Slack, in real/video/phone life please. There is an illusion that work is getting done faster on Slack; the opposite is true, work is slower and of poorer quality.

<comment><USER46> > How does Slack facilitate that better than scheduled meetings?

Slack is not a replacement for scheduled meetings though.

> If a conversation takes longer than three minutes to conduct on Slack, in > real/video/phone life please. There is an illusion that work is getting done > faster on Slack; the opposite is true, work is slower and of poorer quality.

People say meetings are high-bandwidth, but getting a bunch of engineers in a room is very expensive (literally - hundreds of dollars an hour) and you get synchronous, blocking discussion (one person speaks at a time - else, chaos). I am much, much less distracted participating in a "long" slack discussion (which I can check in on every few minutes or so) than I am with all my attention paid to listening to a meeting.

Personally, I find few people on any given team are able to communicate well on the fly in a meeting and I see people (including myself) frequently asking for clarification due to misunderstandings, which contributes to a meeting dragging. Meetings are also _notorious_ for encouraging unfocused and unstructured discussion, unless you have a good moderator or some structured approach to a meeting (like a lean coffee style). A lot of this is improved in a Slack conversation because people are forced to distill their thoughts into text, they are able to reread messages for clarification, and we've had good success using Slack threads for focused discussion of particular topics.

Meetings are also not archived by default, which isolates the people unable to attend the meeting - especially when you have in person meetings that are not remote friendly. Slack discussions are at least discoverable through search. One team I was on started recording meetings and rewatching hour long meeting minutes to get information is actually terrible. Searching through Slack is not perfect, but it's infinitely quicker and I frequently do find what I want.

<comment><USER45> You are right in that meetings are prone to being wasteful and unarchived. A few considerations that I find necessary for meetings: \- Schedule in advance (if possible) \- Set an agenda and provide reading material (if available) such that attendees can prepare \- Be selective in who attends; those with relevant knowledge, interest or stakeholders \- Record meeting notes (key decisions, unsettled conversations, differing opinions) \- Appoint a chair to keep the meeting on track, as per the agenda. They can also help shut people up and give others a chance to speak. \- Share the meeting notes with the team at large

</comment></comment></comment><comment><USER47> The author nails my thoughts on Slack (and its OS clone Mattermost). It is less a communications tool, more of a productivity tracker.

I've worked in places where it was unofficially compulsory to have Slack always open. If you didn't respond to a message is a timely fashion then you'd be asked why. It became the case that Activity on Slack = Productivity.

This wouldn't be so bad if it weren't for the fact that I think Slack is a pretty poor way to do workplace communication. It's the textual equivalent of shouting out a question to the whole office. Everything seems to mush together in to one big conversation about everything that is hard to track and search.

<comment><USER48> My thoughts on your comments are the same as my thoughts on the article. These are cultural problems that Slack is simply exposing. If there was no Slack, something else would fill the need for your middle management to track everyone's 'productivity'.

</comment></comment><comment><USER49> In regards to "organizational memory", has anyone had any luck not allowing for "private messages?" The idea being that the vast majority of conversations between any two people will be about a work item, if it's about work, and therefore all conversations should be organized around work items, rather than people.

Gitlab seems to do this[0] and I'm curious if it's better than ad-hoc conversations. Too bad their UX is too cluttered. I hear Basecamp has similar functionality.

[0] [https://gitlab.com/gitlab-org/gitlab- ce/issues](https://gitlab.com/gitlab-org/gitlab-ce/issues)

<comment><USER28> I can't imagine that being a good idea -- people form friendships in the office, or they just need to have a private conversation -- it seems like it would be weird and draconian to forbid that kind of thing because something important might be in a private chat.

<comment><USER49> Ah, I meant forbidding them in the sense that the culture of the organization would discourage people from talking about work related things in a "work context" via ad-hoc messages, not that people literally or practically wouldn't be allowed to message each other. I agree, that would be draconian.

</comment></comment></comment><comment><USER50> I realize that I am nitpicking the nitpicking here...

> JIRA has a screen real estate problem. Have you seen the articles about SERP > shrinkage, where a G results page in 2004 was mostly results and now it's > mostly ads? JIRA started out this way. 90% of the text on the screen isn't > your project's information, it's JIRA chrome.

Press "z" and "[" in JIRA Cloud to hide the top filter bar and sidebar, respectively, when viewing a project board. These were the first shortcuts I learned after the redesign about a year ago.

</comment><comment><USER51> The "organisational memory" point is one of the driving factors behind the tool / startup I'm building.

[https://getctx.io](https://getctx.io)

tl;dr - It's basically all the good bits of Enterprise Search, but set up to pull in the data from the cloud based SaaS tools we all use in 2018, and designed for digital / product teams.

The rationale is, I think that there is no sensible, central place for a company to store all the types of info they have. Slack doesn't do it all, Confluence, JIRA or Trello aren't enough, Google Drive is good for some things...

In my experience (and from many people I've surveyed and spoken to) most companies end up with loads of these tools, and it's a nightmare to find specific pieces of content when you have 5+ options for where it could be.

The answer isn't one tool to rule 'em all - it has to be an abstraction - <USER3> the data available but store it (master it) in the various locations.

So, my product indexes Trello, Slack, Google Drive, GitHub and email (and, in beta, JIRA). It'd be great to get some HN-style feedback :-)

</comment><comment><USER52> Can anyone please explain why Slack is so popular?

Isn't it just another IM chat? I've tried it a couple of times and found nothing special about it.

Also, in all companies I worked at they either had Lync or Skype (because Enterprise, Windows, Office suite etc.).

Even if company decides to try some fancy IM, isn't it better to switch to Atlassian HipChat as it gives nice integration with JIRA, Confluence, Bamboo, BitBucket (assuming company uses Atlassian toolchain)?

<comment><USER53> It's viral business model, phone/desktop apps, and integrations have made it a leader in workplace messaging. Hooks you with free and hits the sweet spot of UX.

</comment></comment><comment><USER54> In any team development context you need a way of interrupting people when blocked, so regardless of whether it is slack or skype or something else, you will need some chat-like tool, unless everyone sits in the same office every day. That doesn't mean that pointless interruptions should be encouraged or even allowed. I've always made it a policy of telling people in chat to send me an email if their question was not blocking, but that only works if your manager allows it.

Another aspect here is to what degree these tools are introduced for the right reasons. I've seen from the inside (facility services industry) how open plan offices and flex desks are pushed for cost reasons (fewer sq. m. per employee) while being marketed as promoting team interaction (studies show it harms productivity more than helping). Cost is a bad reason, but at least it has an internal logic. But then you get people who see everyone is going to open plan and move to open plan also but with lots of empty space, nullifying the cost advantage and keeping only the downsides. Maybe with slack there's also a degree of cargo culting going on.

</comment><comment> noir-york Mediums create expectations around availability, presence, and response times.

Phone (excluding VOIP): availability is not expected, but once call is picked up, response is immediate.

Email: availability is guaranteed (if you know their email), and a response times range from minutes to next day.

IM / Slack: Availability is known and a response expected in the seconds / minutes range if you are available.

It comes down to using the right tool for the job@ "hej Jeb, you in the office?" \- use IM.

Then go over to Jeb's office to continue the discussion on whether to go with solution A or solution B. Its an indepth discussion that takes over an hour and Jeb closes his door so the two of you can discuss without interruption.

Back in your own office, you email Jeb with a summary of the discussion and the points agreed.

Jeb calls back saying "hey, i'm not sure about para X"... You discuss it over the phone, issue is resolved in a couple of minutes. You post the updated document to the internal wiki and email the team.

Feeling productive, you decide its time for a coffee, you slack the channel asking who would care to join you.

When a company normalises the expectation of getting a response to anything in seconds, interruptions happen all the time and productivity takes a hit.

Also, I hate open offices and thank heavens I only have had to work in one for a few months. The only true progress we ever made was going through the lunch menus of all the nearby restuarants.

On the other hand having say, a handful of people in a room (three or four) is a good balance between the chaos of open office (and real estate cost efficiencies) and giving everyone their own (potentially isolating) office.

</comment><comment><USER55> My approach to Slack is to treat it like email.

It lives in an open browser tab during work hours, tucked away in a corner of the screen where I can't see the "IMPORTANT! EMERGENCY!!! READ ME NOW!!!" warning that is permanently on in the icon. From time to time, when I'm at a natural stopping point, I'll check email then I'll check Slack.

Never allow it to send notifications or make noise. Certainly never install any form of native client. That means it's not on your phone or tablet (since the web version doesn't work on mobile devices anymore). That means it can't seek your attention when you're not in your office.

It'll send little digest mails if you forget about it for a whole day. For me, that's enough to remind me that it exists and that I should open a Slack window as part of my morning email spin.

I've worked with people who have alerts turned on for things, and they can't even hold a conversation for all the bongling going on on their devices. It seems unbearable.

</comment><comment><USER56> From my understanding Slack at large organizations (10+ employees) don't make organizations more productive at all. At the place that I work slack is relatively manageable for the most part. For me to make slack useful I just turned off all of the chatrooms and everything and make it so that I only check if it I get @ notified.

There are weird parts of slack by default that seem to be designed to make you less productive. Why does the #random channel exist at all? Sure it should cordon off off topic conversations and its designed by slack to increase engagement but is that what should be there by default?

For the most part though I see Slack as making me more productive. It is much easier to use than other alternatives. It has a great UI as long as you use the browser version (all of the native apps for linux are largely broken for me). If you are a large organization I think you would want to consider discord (yes I know its targeted for gamers) but it the react community uses it well in this regard.

</comment><comment><USER57> Slack is a tool, and it's all in how you use it. You and your team need to be disciplined and on the same page about how to use it.

As for handling organizational memory, we spin up channels as single discussion forums. It's easy enough to archive them when a conversation ends (usually lasting ~2 weeks from describing problem to everyone involved agreeing it was solved).

</comment><comment><USER58> I get the author's frustration - especially with slack's search features. But I think it's possible to use slack as a tool for transient conversation and notifications. We routinely copy/paste slack chats in other tools (asana, docs, code comments) when we feel it's something worth saving. It does require discipline with tools usage though...

</comment><comment><USER59> Well, this is why i disabled notification for Slack, so i did to everything else. I read emails when I want to read emails and so on. During meetings phones should be put on silent and this must be enforced. I think it is very simple to remain productive in a environment that has so many interruptions. You just need to follow basic principles.

</comment><comment><USER60> This looks like a problem to be solved with something like a google search engine for all internal pages and wiki.

Perhaps we should start machine learning to start auto tagging discussions in Slack with the context they're being done in and then expose a search engine like interface to all of Slack conversations, wikis etc.

</comment><comment><USER61> I think how to divide your rooms is key.

"development" or "engineering" is probably too vague. You may want more specific things: implementation, testing, release management, incidents and make sure people to stay on topic.

Then, have a channel for offtopic, informal things and let people ignore it.

</comment><comment><USER62> IMHO Slack should be used only as informal communication tool. Neither Slack nor Discord or others facilitate the most important part: long-term result from communication.

Why? People are used to WhatsApp, FB Messenger, etc. and chat these days is mostly without consequences. That also translates to Slack and others.

Effective communication producing results IMHO requires investment. Chat is the opposite of that.

Anecdotal part from various companies: Slack is mostly a place for slacking off, doing silly things or send "untraceable" reprimands (since free tier does not archive) long-term.

Organisation has to be company culture before using tools like Slack, or Slack will do you no good.

... feel free to replace Slack with any other messaging app.

</comment><comment><USER63> I miss not having team chat. People figured stuff out and felt it was important enough to document... failing that they got up and walked over. This was 2003ish.

Now I end up either being drained by lack-of-effort questions all day on chat, or being reprinanded for not being available on chat. I never progress in my career, and in my mind there's an obvious correlation. I am talented and have one point of focus, which is a good point of attack for aspiring colleagues (effectively competitors, sadly). I can get better at saying no, but it doesn't fly well as most senior member most of the time because I'm called a "blocker".

</comment><comment><USER64> my slack strategies lately:

* mute everything, except my team's chat;

* turn off the "is typing" feedback;

* use the web version in a standalone browser (eats 200mb ram only instead of 2+gb, in srware iron at least);

* mute colors with custom "theme";

* turn off emoji display (falls back to :foo: :bar:);

* remove the rest of the emojis with greasemonkey extension (and mute more colors);

* collapse documents by default (really helps with big animated gifs).

But I still am trying to cope with some of the problems mentioned in the article and sometimes I have this feeling that I'm part of the problem (expecting fast replies, whining at times, not being constructive enough etc).

</comment><comment><USER65> Never used Slack but I've followed the cycle from little tool that could, to hip tech buzzword, to celebrity startup and now seemingly back down to...do we really need this?

I wonder what will come next.

</comment><comment><USER66> OMG: this guy is 100% right about JIRA.

About SLACK; well, it can be used responsibly, if you set ground rules. Honestly, I've never used it within a team, but across teams. So I never had the problems he's describing. I can see how it would be abused that way. But you have the senior leaders set ground rules on usage. (doesn't solve the search problems).

Chat is a tool. It can be used responsibly to be helpful, or it can be misused to fuck shit up. Just like any tool.

</comment><comment><USER67> This assumes everybody's in the same office. Slack has tremendously improved my team's communication as we're spread across many university buildings.

</comment><comment><USER68> Wow, this is the most dystopian take possible regarding Slack. Half the time I can't tell if they're arguing against real-time chat or for IRC.

In any case I think that you could easily argue that most of these things depend on your organization and what use cases you have for Slack. But wow, I'm having a hard time visualizing how it could be this bad.

Before Slack, my org had no centralized communication. That sucked way worse than having Slack.

</comment><comment><USER69> Reading through this thread, it seems like Slack is really missing more fine- grained control over channel permissions.

There are largely four types of communication and they need four different permission designs:

* Important and immediate - stuff like production monitoring and incident resolution. These channels should typically be quiet but they should have the power to notify and interrupt people doing normal work when activity happens. If you have support channels, they should be staffed by dedicated support people whose primary job is to be interrupted by support requests, and not engineers trying to buckle down on their work.

* Important but not immediate - ordinary corporate alignment discussions. These channels should be globally administratively enforced as read-only except for predefined, enforced "meeting hours" which are blocked out organization-wide on everybody's calendar, which is when discussion on issues actually happens. If people have an issue they need to bring up on a particular topic, it can wait until tomorrow, and not interrupt engineers trying to get their work done. People no longer mute these channels because they're not interrupting them during get-work-done hours. If it's too difficult to follow the "meeting" in a dozen different channels then it's probably a sign that your organization has you in charge of too many responsibilities and you should stop looking at the tool as a means of fixing your organizational problems.

* Not important (and either immediate or not immediately): there's a time and place for watercooler channels, and it's not interrupting you in your cubicle. Notifications should be globally administratively disabled entirely for these channels, for everyone, including the people who care about following along in those channels, because nobody should be standing around the watercooler all day long.

Slack's product teams should be looking at mute as a sign of failure that says "either this tool or this tool's configuration is preventing me from doing my job" and the product team should respond accordingly (remember: tool misconfigurations are an admin UX failure that harms your product by damaging its reputation, and you should fix the UX failure that lead to the misconfiguration so as to protect your product's reputation). The only mute button in Slack should be a Slack-wide mute button for vacation etc.

</comment><comment><USER70> I think something useful could be implemented using a distributed model. No server, no company, just a network of nodes communicating together using the Internet as it was originally intended to be used. No one makes money on email and no one should make money on chat.

The underlying implementation could use Git, which would preserve history and give everyone a complete copy of the repository.

</comment><comment><USER71> Slack, like all tools with built-in notifications, works out much better for me when I disable the notifications.

I alt+tab to the window now and then to see if anyone's trying to get my attention and it tells me who, and how many unreads I have.

The key is to not have the notification sound/popup and I can just bury Slack under my editor, browser etc until I decide I'm available.

</comment><comment><USER53> Easy to say Slack, JIRA, Trello suck, but what are the alternatives? I used IRC at two 1000 person companies. It was useful, but didn't replace email like slack does now. Likely due to lack of persistence, absence on phones and hard to setup integrations.

Echoing a lot of the comments, you can blame tools for altering the culture. Phones disrupted memos, email ended vacuum tube delivery, computers killed the file cabinet. Slack is a reflection of our short attention spans. No one wants to read long emails. People need an easy way to message and get notified on all screens. People pass screen shots across their devices. It solves problems. I've seen people who abuse @mentions and @here, but ultimately you develop filters and need to take responsibility for one's own workflow.

I do hear how Slack isn't good at making organizational events searchable and good at archiving in corporate memory. Problem space is: need to search, recall, store and archive better. Maybe tools to record this into some record or doc, (i.e. readthedocs). You can argue Facebook/Yammer style status posts is a better way to broadcast and save announcements. Slack can innovate on UX, but they seeme focused on growth and quality of service. They're not looking to solve small issues at this time.

<comment><USER72> This isn't really about Slack, it's about the whole paradigm. Maybe it's even OPs fault that he phrases it this way, but anyhow, if it really would be about Slack it would imply that something like Facebook Workplace is any better, but in reality it's infinitely worse on about every possible aspect and beyond. Even by OPs own metrics.

So it's more about how "emails would be better", and surely not about "how to replace them". Not sure if I agree or disagree though.

<comment><USER29> Had Workplace in my last job, just started a new one which uses Slack.

I do _not_ in any shape or form miss Workplace. It was sucking my attention dry, blocking meant I'd lose out on things that actually matter.

With Slack it's super easy to set notifications to null except for eg mentions or important groups - and can even have different defaults for mobile vs desktop.

<comment><USER72> Yes, it's horrible. I actually _do_ set all notifications off, which is borderline rude and arrogant of me, but otherwise my "working hours" would be pretty much pointless.

For me, actually, the worst part is the shittiest chat app I've ever seen bar none, especially on desktop. There's no decent app for Linux, browser app is slow, buggy and constantly leaks memory, the most basic features that, I'd think are mandatory for any modern chat-app are missing, UI just totally sucks. It's hard to imagine someone could make an IM-app so bad by chance.

</comment></comment></comment></comment><comment><USER73> There is communication bottleneck in any large team. The goal should be to maximize information sharing and minimize communication.

Communication is scare resource and the use should have budget to create incentives to save it. Maybe someone can use blockchain hype to create that monetizes messaging inside companies.

</comment><comment><USER74> Like anything, this is a people problem. I have no issue with Slack because I have no issue with it personally, because there is no fanatic focus on this thing in my company.

If it is a problem, it's probably easy to start solving it: don't use it.

</comment><comment><USER75> What about the argument that since email is built atop an open standard, you can (theoretically) migrate to different email servers and clients, but with Slack, your "organizational memory" is owned by Slack?

</comment><comment><USER76> The "ADD" that Slack creates might be the killer feature. I suspect that many middle managers may not know how to organize work, and this lets them get away from that.

The name Slack becomes even more ironic in this context.

</comment><comment><USER77> Is anytime using Zulip and would care to comment about your experience?

<comment><USER78> We are at my org, but my only exposure is cross-team / cross-division chatter. I collaborate with my team across offices through an old Jabber client. This isn't ideal, but pulling it away from a browser window allows you to disconnect, set DND status, that sort of thing.

Zulip's focus on streams & discussion topics (over people-groups) is terrifically handy for tuning into large-scale group chatter, looking at things that are interesting to you and sharing conversations with others. Project/task management via Slack or any similar tools just seems bonkers to me.

</comment></comment><comment><USER79> I one time kept saying that one shouldn't have a General forum - but no one understood.

The only way to have the desired archive structures is to _not_ have a dumping ground. Non of any kind.

</comment><comment><USER80> Yes— and that's ok. Slack is more like organizational RAM.

</comment><comment><USER81> "it's like having an old man pee on your face one trickle at a time. I'd rather have it over with quickly and go wash up."

I think we've all been there.

</comment><comment><USER82> Slack is a tool, just like kitchen knife is. Used correctly, it is valuable. Otherwise, I agree with all you said.

</comment><comment><USER83> Great post. Hits exactly the sore point of working in today's environment.

</comment><comment><USER84> Slack should be used as a CLI for your business. It not _only_ a chat room.

If you want documentation, then add a command for `/doc "title"` and start a collaborative document.

If you want to add a task, `/task add "title"`

etc.

Its a shared command line, not only chat.

</comment><comment><USER85> /giphy amen

</comment><comment><USER86> Relay is a Slack alternative: [https://www.relay-chat.com](https://www.relay- chat.com)

So far, a Relay organization is a hosted Mattermost instance. Slack isn't exactly revolutionary software and it seems silly that persistent IRC (that's all Slack is) should cost so much money or run on a proprietary, users-as- inventory, data-gobbling platform.

1\. Why does Relay exist?

We built Relay for precisely this reason. Mattermost is pretty cool but we (nilenso.com) are not a military contractor or a bank. We didn't need Mattermost hidden deep in our datacenter; we just wanted hosted Mattermost so we could stop handing over every byte of our internal data to Slack, Inc.

If Relay existed a year ago, we would have paid for it. So we built it (for) ourselves.

2\. What's the plan, Stan?

As long as we can, we want to stay in sync with the Mattermost mainline. All our code is open source ([https://gitlab.com/nilenso/relay- backend](https://gitlab.com/nilenso/relay-backend) and [https://gitlab.com/nilenso/relay-ops](https://gitlab.com/nilenso/relay-ops) so far) but we'd like it if our users could move to their own self-hosted Mattermost instance as easily as a self-hosted Relay instance.

We have some pretty specific near-term plans: First, Integrations are a pain with Mattermost and we'll be releasing a server to make that a one-click operation (like it is on Slack) soon. Second, a fully-automated (one-click) Matterbridge server so you can migrate from Slack slowly or keep or IRC users happy.

But beyond that? We're not sure. There are some UI/UX bugs that annoy us (especially on the Mattermost/Relay mobile clients). Some of the issues Abe mentions are low-hanging usability fruit, but from a lot of the replies on this thread, it sounds like not everyone feels the pain. It's not immediately obvious to use what we should prioritize; we don't have an issue people at nilenso sending us photos of their cats, for example. We're probably far from the norm, though.

If you want to shout at us about how we can fix Relay (née Slack) and, as a consequence, Mattermost, usability we'd really like to hear it. This is our 9-to-5.

Shout on Twitter: [https://twitter.com/relay_chat/status/962936101919838208](https://twitter.com/relay_chat/status/962936101919838208)

Shout on Open Relay [1]: [https://open.relay- chat.com/signup_email](https://open.relay-chat.com/signup_email)

Or shout on this thread, obviously.

Thanks HN.

-steven

[1] This is our open Relay server. Create channels, teams, whatever. Think Freenode or any other community IRC network. No 10k message limits or any of that garbage (it seems insane to me that language communities like Elixir and Clojure moved chat to Slack, given this restriction).

</comment><comment><USER87> I think people forget what it was like before Slack. Sitting down to 30+ emails by 9:00AM and over 200 in a single day. It was death by email threads and following them was a horrible time suck. Worse off, email was treated like a real time conversation so you were expected to tracking it all the time through the day.

Slack solves a lot of this. The channels are opt in. If you don't want to follow something, just leave. Email is now just for async messages and is less of a distraction during core hours.

If your team or Co uses one channel for all your discussions, then I suggest that you find a way to split out the primary topics in a way that lets everyone filter the wheat from the chaff.

Like others are saying, don't blame the tools for being misused. Ultimately you have to learn how to efficiently communicate with your team and be disciplined enough to know what tool to use for each type of task.

<comment><USER88> Agree 100% on the last para.

</comment></comment><comment><USER89> My issue with Slack in our organisation (a University), is that people spawn off new teams for everything, and nobody has a paid group, because it's too expensive with our budgets, so you lose the conversations by age at 20000 messages.

This has led to the situation where I'm in (a) My research group's group (b) One for people who program within the University (c) One for a side project I'm involved in (d) Slack channels for some software I use as dependency in my own project (e) One for a language specific group (f) One which is a group we share with collaborators at other Universities (g) About 5 more that have now been abandoned.

And because of that, I end up just turning off Slack all day and checking it in the evening, because I don't find it conducive to research work where I mostly work independently anyway.</comment>


Coding Anywhere with Cloud IDE - <AUTHOR> http://fixate.io/tech/cloud-ide/

<comment><USER2> Do you have a working URL?</comment>


The Rise, Fall, and Rise of the Home Office - <AUTHOR> https://www.citylab.com/design/2020/06/home-office-setup-design-history-remote-work-furniture/612889/ <comment><USER2> I'd never given a lot of thought to it but even the fairly large house I grew up in during the 60s/70s didn't have a dedicated office although there were large bedrooms with desks. I was fortunate enough to have a nice dedicated office before the current situation hit.

One does see a huge contrast on video calls between people in seemingly offices (or, if bedrooms/living rooms, sufficiently stage managed and lit to appear as such) and those obviously balancing laptops in a bedroom or kitchen table.

<comment><USER3> What makes something a dedicated office though? The only two things I can think of would be a phone line (not so much these days) and maybe being somewhat separated/distanced from the rest of the bedrooms and maybe near the front door. That's how I deduced I was an aberration to the family planning from my "bedroom" anyway.

<comment><USER4> What makes it an office? A separate room (or at least separated area, dedicated desk and chair, necessary peripherals and paraphernalia, sufficient electrical outlets and opportunity to not be interrupted.

</comment></comment></comment><comment><USER5> Interesting article. I'm personanly struggling to find a home office chair, without being able to try them in store. unfortunately, all the reccomendations are in the 500$+ range that I simply cannot afford.

<comment><AUTHOR> I got an old solid wood chair from the 20s or 30s that was US Airforce surplus for free (I got lucky and had connections, but they can also be picked up dirt cheap at surplus places, don't look at antique shops, they'll overcharge you) and it's nicer to sit in than any fancy expensive $1000 chair I've had at fancy office buildings before. My lower back starts killing me in most chairs, but something about these old chairs really helps it despite having none of the fancy features of modern chairs. It looks awesome too, although it weighs about a ton.

<comment><USER6> Can you post a photo?

I despise all the fancy aeron chairs (they appear to be classic cargo cult science) and favor a couple of old Eames and Corbusier chairs. Just curious what works for others in the "chair that grandparents would recognize as chair" category.

<comment><AUTHOR> It's this one: [https://imgur.com/poAth33](https://imgur.com/poAth33)

I think it's actually later than I was saying, I looked at a USAF one from the 30s but I can't remember if I picked it or not. I'll have to see when I get back to my desk, it had the Airforce logo on the bottom if it was that one. If it was the other one, can't remember when it was from.

<comment><AUTHOR> Looked it up; this is not the USAF one I was looking at, it's by Milwaukee Chair Co. and was manufactured in 1924 according to the stamp under the seat

</comment></comment></comment></comment></comment><comment><USER7> I have a very well planned home office. I've gone through countless chairs over the year trying to fix back issues. I introduced more weight lifting into my exercise (deadlift in particular) and I haven't had back issues in a couple years. I sit on my couch or bed for work most of the time -- which I've been told is supposed to be the worst for you.

<comment><USER8> Pull-ups are better than deadlifts. Deadlifts actually have a really bad risk- reward ratio

<comment><USER9> They have little to do with each other. The lats are the primary movers in pull-ups, while they are only a supporting muscle in deadlifts.

Also if you are having general back troubles due to sitting, deadlifts are more likely to fix them.

<comment><USER8> Risk to Reward ratio. And no, deadlifts wont help with your sitting problems. Your lats are the ones that need stretching n that case.</comment></comment></comment></comment>


Ford disguised a man as a car seat to research self-driving - <AUTHOR> https://techcrunch.com/2017/09/13/ford-disguised-a-man-as-a-car-seat-to-research-autonomous-driving/ <comment><USER2> It sounds goofy, but this strikes me as really clever. Compared to almost anything else with self driving cars adding a few indicators to outwardly show what it's going to do next (for pedestrians and other drivers) is a huge win.

There is a fair amount of waving for someone else to go first at a turn, seeing if a driver is distracted (on their phone) at a stop, making eye contact while using a cross walk etc that gets lost with SDVs.

Also, I really feel like they stole this idea from Raid 2 [https://youtu.be/ErrRhXItBWc?t=118](https://youtu.be/ErrRhXItBWc?t=118)

<comment><USER3> __* SPOILER __*

That's how they made Knight Rider "driverless" scenes ([http://www.knightriderarchives.com/knight_rider/season_one/g...](http://www.knightriderarchives.com/knight_rider/season_one/give_me_liberty_or_give_me_death/nitpicks/images/04238.jpg) <= can't find a clear shot, but if you find episodes online, it's pretty easy to see the double depth seat and raised up armrests)

<comment><USER4> How did I go through life without knowing that?

<comment><USER5> You are not alone & I am with you

</comment></comment></comment></comment><comment><USER6> People in the comments are making references to prank videos and film techniques, but this type of research study has also been conducted multiples times in the last few years by institutions such as Stanford [1], UC San Diego [2], Virginia Tech [3], and more.

[1] [http://wendyju.com/publications/RO- MAN2016-Rothenbucher.pdf](http://wendyju.com/publications/RO- MAN2016-Rothenbucher.pdf)

[2] [http://www.sandiegouniontribune.com/news/science/sd-me- ghost...](http://www.sandiegouniontribune.com/news/science/sd-me-ghostdriver- ucsd-20170403-story.html)

[3] [https://www.citylab.com/transportation/2017/08/heres-the- rea...](https://www.citylab.com/transportation/2017/08/heres-the-real-science- behind-that-fake-driverless-car/536268/)

<comment><USER7> I think the article is referring to the VirginiaTech study itself too

<comment><USER6> Curses! Shame on me for commenting before thoroughly reading the article.

</comment></comment></comment><comment><USER8> A reporter apparently tried to talk to one of the drivers and they refused to acknowledge his presence: [https://twitter.com/AdamTuss/status/894627339891609602](https://twitter.com/AdamTuss/status/894627339891609602)

<comment> unkown-unknowns What an annoying reporter

<comment><USER9> He's actually a pretty decent reporter in the Washington DC area. He covers transportation, including all the failures of WMATA (DC metro).

</comment></comment></comment><comment><USER10> "they just needed people to believe wholeheartedly they were using one."

Don't they mean "seeing one" instead of "using one"? Or am I missing something?

"fill in gaps where we currently communicate via subtle gestures, eye contact and other less obvious mechanisms."

This also struck me as odd - do pedestrians and other drivers really make "eye contact" with drivers to gauge their intention? I guess it's possible, but in many cases you can't see the driver's head, let alone eyes.

<comment><USER11> > do pedestrians [...] really make "eye contact" with drivers to gauge their > intention?

Yes. Consciously, at every vehicle at an intersection, to make sure they aren't going to run me over. Same on a bike.

Other drivers? IDK, its harder through 2 windshields.

<comment><USER12> I do it all the time whether I'm walking, in a car, or on my motorcycle. If I look at them and see them looking at me it raises my confidence that they see me.

<comment><USER13> I've been given a ride in the passenger seat of a RHD car in a RHT country, ie the steering wheel is on the "wrong" side.

It's actually quite stressful before the driver (hopefully) stops at a zebra crossing after you accidentally caught eye contact with a waiting pedestrian staring at you.

The best strategy is to just look down, but that feels a bit stupid too when the pedestrians are clearly looking at you.

</comment></comment></comment></comment><comment><USER14> It's interesting, everybody is thinking about how this was used for pranks and films, but I immediately thought of the much more sinister attempts to flee east Germany. I was unable to find a photo, but I remember seeing a car that was modified so a person could be sewn into the seat in a Berlin Museum.

<comment><USER15> Yes - it happened, also on the Mexico/US border, this has a guy as a car seat but leads with woman in a dashboard: [http://www.snopes.com/photos/automobiles/dashboard.asp](http://www.snopes.com/photos/automobiles/dashboard.asp)

<comment><USER16> I wonder how is it possible to find someone hidden in a dashboard? Were it dogs that found her?

<comment><USER17> I'm paraphrasing the news report because it's been a few years, but:

The border patrol agent became suspicious when the driver opened the glove box to retrieve his registration and a hand reached out from within the box to give it to him.

<comment><USER18> Sometimes, one can be _too_ helpful.

</comment></comment></comment></comment></comment><comment><USER19> This is really quite common. I read an article about a car in Pittsburgh where a driver was similarly disguised in order to research specifically other peoples reactions to driverless vehicles on the road. In the article I read, I believe it occurred in Pittsburgh, PA and the researcher was affiliated with a university (maybe Carnegie Melon?). The reporter was able to speak with the costumed researcher just briefly, but got a more substantive statement from the org doing the research.

<comment><USER20> That's literally the same project this article is about

</comment></comment><comment><USER21> Seems like they need to turn the cameras inward too (or has this been done already?); they can start observing "good" drivers providing signs to other drivers to then learn how to communicate a driving decision better.

<comment><USER21> It's kind of funny imagining a robot / self-driving car program going through driver's ed and taking the driver's license test with a human scoring it. Will car models and algorithms be evaluated like this too? :)

</comment></comment><comment><USER22> Just as in Knight Rider! [https://knightriderhistorians.blogspot.com/2013/12/the- fate-...](https://knightriderhistorians.blogspot.com/2013/12/the-fate-of- original-hero-car-revealed.html)

</comment><comment><USER23> Really interesting study, would have liked to see some preliminary or even anecdotal findings discussed in the article.

I've seen some Youtubers pranking drive-through windows in the same way and they're pretty funny at the very least.

</comment><comment><USER24> The setup reminds me of a pretty weird story called "The Human Chair": [https://en.wikipedia.org/wiki/The_Human_Chair](https://en.wikipedia.org/wiki/The_Human_Chair)

</comment><comment><USER25> I have been in a situation when I was mid-crosswalk when an idiot came screaming round a long shallow corner too fast (fast enough to have the white- line between his wheels).

I had a 50/50 choice. Keep going or run back. In the 3 or so seconds I had we made eye contact and I saw him return his eyes to my front (i.e. he was trying to get back on to his side of the road) so I moved backwards.

Not sure what I would have done if it were a self-driving car and unable to do the visual communication (Although the entire point might be moot since a self-driver wouldn't be in that situation)

</comment><comment><USER26> This is what it looked like on the news: [http://www.nbcwashington.com/news/local/Why-a-Half-Car- Seat-...](http://www.nbcwashington.com/news/local/Why-a-Half-Car-Seat-Half- Man-Was-on-the-Road_Washington-DC-439081263.html)

</comment><comment><USER27> So what were the results? Are pedestrians jerks? Do other cars cut them off?

</comment><comment><USER28> New Turing test:

Is the driver in the car in front of you a human driver or a computer.

</comment><comment><USER29> Looks like they put a cylon indicator on it? Not terrifying at all...

As for devising new signals which other drivers are supposed to watch to understand what the car plans to do, I'd say we need a lot more research to understand if this actually helps or just distracts.

</comment><comment><USER5> Only successful if they can cross the Mexico border. :D

</comment><comment><USER30> Prediction: this is the sell out costume for Halloween.

</comment><comment><USER31> This article confused me a lot more before I realized Ford meant the company, not the individual.

<comment><USER32> Interestingly, it was the same for me. I was really confused for a few seconds until "self-driving" sank in and it became clear that Henry Fore could not have been alive for that.

<comment><USER33> In Henry's time, "self-driving" would probably be more likely used to describe a brick on the accelerator.

</comment></comment></comment><comment><USER34> MVP

</comment><comment><USER35> So they re-did a prank from 2013 but for science [1]

[1] [https://www.youtube.com/watch?v=xVrJ8DxECbg](https://www.youtube.com/watch?v=xVrJ8DxECbg)

<comment><USER36> The ol' car-seat-suit trick! That's how KITT from Knight Rider did it in 1982 as well! [https://www.moviemistakes.com/entry91522](https://www.moviemistakes.com/entry91522)

<comment><USER37> Disguising yourself as a car seat also features in this episode of 'Sherlock', [https://en.wikipedia.org/wiki/The_Six_Thatchers](https://en.wikipedia.org/wiki/The_Six_Thatchers)

</comment></comment></comment><comment><USER38> a programmer disguised as HM Aeron chair ... probably makes for more serene looking open floor office, and also minimizes the chances of the others bugging you with various stuff.

</comment><comment><USER39> In London, with their right positioned drivers, more than once I got a scare of the phantom drivers. :-)

</comment><comment><USER40> Not quite the promotion to deputy chair that he had expected.

</comment><comment><USER41> Reminds me of the magician who goes through drive throughs in that costume.

I like the idea of an indicator showing what the car is 'doing'.

</comment><comment><USER17> I can't wait until somebody patents "signaling pedestrians" and we all have to deal with brand-specific signaling mechanisms.

Thank Zod QWERTY was invented so long ago.

/cynicism

</comment><comment><USER42> Off topic, but man do I hate looping gifs in my articles. It's so incredibly distracting.

Sure, play it once, maybe even twice. But an endless loop? That's just unnecessary.

<comment><USER43> It's not even very good communication. As there often is no clear start and end, when I scroll to the gif I have to watch it at least 2 or 3 times until I really know what is going on, where the loop starts and where it ends. Simple video would be so much better.

</comment></comment><comment><USER44> Leslie Nielsen did this forever ago: [https://www.youtube.com/watch?v=xqJ3lx43lMg](https://www.youtube.com/watch?v=xqJ3lx43lMg)

</comment><comment><USER45> The conspiracy theorist in me figures this kind of research will be used by companies that are falling behind in the self driving car race (no pun intended) to get governments to regulate against self driving cars.

</comment><comment><USER46> Going off on a tangent here but is the HDR filter really necessary for those images? What is gained by using it? /rant

</comment><comment><USER47> This isn't even the most elaborate market-research stunt I've seen.

Some of you older folk may remember an 80s sitcom called Small Wonder, which was a typical American suburbia family sitcom, except the youngest daughter, Vicki, was a robot. What I found unusual about the show was its copyright message: "©1987 The Small Wonder Joint Venture". In later years I found out that the show was produced in part for market research purposes, to solicit feedback about how Americans might feel about robots in the home -- especially robots that look and behave like humans. It was the 80s and we all thought that was coming Real Soon Now.

<comment><USER48> The unusual name ("The Small Wonder Joint Venture") is because the television show was the first product of a "joint venture" between 5 television stations [1], not because it was made by some secret home robotics manufacturer or marketing firm.

[1] [https://en.wikipedia.org/wiki/New_Program_Group](https://en.wikipedia.org/wiki/New_Program_Group)

<comment><USER49> Also, Booger produced 'wonder joints' to liven things up during the party scene in 1984's 'Revenge Of The Nerds'

[https://youtu.be/WEp0fte3B8o](https://youtu.be/WEp0fte3B8o)</comment></comment></comment>


The BEAM Book – A Description of the Erlang RTS and the Virtual Machine BEAM - <AUTHOR> https://github.com/happi/theBeamBook <comment><USER2> There is even a separately implemented BEAM VM for running directly on Xen hypervisor:

[https://github.com/cloudozer/ling](https://github.com/cloudozer/ling)

An impressively done book on BEAM instruction sets:

[https://github.com/cloudozer/ling/tree/master/doc](https://github.com/cloudozer/ling/tree/master/doc)

There is even a handy dandy online instruction set completion search:

[http://erlangonxen.org/more/beam](http://erlangonxen.org/more/beam)

</comment><comment><USER3> To anyone who wants to learn about the BEAM would highly recommend Hitchhiker's Tour of the BEAM by Robert Virding [https://www.youtube.com/watch?v=_Pwlvy3zz9M](https://www.youtube.com/watch?v=_Pwlvy3zz9M)

</comment><comment><USER4> There's a bit of back-story here, the gist of which is: the book initially was supposed to come out from O'Reilly and Associates, but periodically the release date would get pushed back by 3 months or so.

Then they cancelled it.

It was then picked up by Pragmatic Programmers, but they wound up cancelling it too.

In any case, Erik told me a couple of weeks ago at Erlang & Elixir Factory that he'd be looking to get it out himself online by -- or around, I forget -- summertime, so it's nice to see he did this now, even if it means I lose the betting pool (I kid).

<comment><USER5> I am curious if you or anyone else knows why this book might have been cancelled by both Oreilly and Prgagmatic, given they have other Erlang/OTP titles. It seems odd.

At any rate I'm glad to see it's going to have a life independently. This looks great.

</comment></comment><comment><USER6> This is incredibly cool. BEAM is one of the most fascinating bits of tech to me, particularly its garbage collector.

You've given me a bit of reading material for my train-ride for the next few days, so thank you!

<comment><USER2> Agreed! Just like people admire at a beautifully engineered ship, plane or nice building, I think BEAM VM is marvel of software engineering.

It got so many things right, it was ahead of its time. Is already stable and is serving critical pieces of infrastructure around the world for many years.

It is also worth pointing out that the BEAM was designed with one purpose and that is to run Erlang. Other languages can be implemented on it, but they sort of have to adapt to the Erlang way. The downside there is that the BEAM official specification is its ... implementation. And reasons for implementation were written down. You can catch Joe Armstrong or Robert Virding at one of the events like Erlang Factory and they'll happily tell you why things works the way they do.

Things I like about this VM:

* Process isolation : sounds like magic but it's true you can have millions of processes _and_ all having isolated heaps.

* Dynamic tracing : connect to a node and start tracing any function

* Hot code loading : don't feel like stopping a critical production server to add an extra log statement or upgrade it, don't have to. Can just load the code.

* Like you mentioned, GC. It will never "stop the world". When process ran and exited, the whole block can be reclaimed quickly and efficiently.

Anyway using BEAM with Erlang, Elixir, LFE or other languages, feels a bit like using a secret weapon that very few know about.

<comment><USER2> EDIT: too late to edit but it should have been "... reasons for implementation were NOT written down...". So yes do track Robert and Joe down and ask them why

<comment><USER7> And write the answer down. Somewhere, even if it's just your blog with about three readers.

</comment></comment></comment></comment><comment><USER8> FWIW, there's a description of most of Erlang internal data structures here: [https://edfine.io/blog/2016/06/28/erlang-data- representation...](https://edfine.io/blog/2016/06/28/erlang-data- representation/)

</comment><comment><USER9> This is amazing. I've started to learn Elixir recently, and as a result my interest in Erlang and BEAM has been piqued. I'm sure a lot of this will be over my head for now, but looking forward to digging in.

</comment><comment><USER10> This is awesome. Unlike the JVM, its really hard to find anything describing how the Erlang VM works in detail. I tried reading through the source a while back but it was still hard to get a gist of what was going on because of the shear size of the project.

This will be a very valuable resource. Thanks so much to Erik!

</comment><comment><USER11> Thank you! Did you think about using gitbook service?

</comment><comment><USER12> Not to be confused with Apache Beam which is looking to become a survivor in the big data space with it's abstractions over whatever is the hottest new streaming or batch processing technology.</comment>


Reasoning under uncertainty: philosopher or scientist? - <AUTHOR> http://www.brbr5.co/blog/2013/04/11/reasoning-under-uncertainty-philosopher-or-scientist/

<comment><USER2> Interesting that you linked to pg's essay, as pg himself has both a humanities and technical background.

Overall I think you're boxing people into categories that need not exist. Plenty of engineers/scientists enjoy studying the "huge ideas" in human history, and plenty such people have also become strategic visionaries.

Your argument may apply to a subset of engineers/scientists who box themselves into their own field, but in my experience that's a pretty small minority (of the best ones at least).

Ultimately ..

 _don't let schooling get in the way of your education_. \- Twain</comment>


Researchers develop tattoo ink capable of monitoring health by changing color - <AUTHOR> https://news.harvard.edu/gazette/story/2017/09/harvard-researchers-help-develop-smart-tattoos/ <comment><USER2> This isn't new. There was an article six years ago about a bioactive tattoo ink that could measure blood glucose levels non-invasively (after the tattoo was applied, of course). The measurement required a sensor attached to an I-Phone and the sensor was estimated to cost several hundred dollars, but it would allow for frequent glucose measurements without finger sticks. Not continuous like CGM devices, but less painful and significantly less expensive.

So far as I know it still hasn't been approved by the FDA, and I don't know whether the developers are even still trying to get it approved.

Google also developed a sensor incorporated into a contact lens that provided non-invasive, continuous glucose monitoring at about the same time. Same result; not approved (that I know of) and no indication that it ever will be.

<comment><USER3> Unfortunately these companies/institutions have no experience with, and no concept of the challenges involved in approving a totally novel medical device in the US.

<comment><USER4> And double unfortunately, approving a medical technology is vastly more expensive and slower than it needs to or should be. Existing medical approval policies are strongly motivated by political concerns (we're still reeling from thalidomide) rather than any rational social optimization policy. It's very easy to scare people into excessive conservatism (in the literal sense). [http://www.fdareview.org/05_harm.php](http://www.fdareview.org/05_harm.php)

<comment><USER5> > we're still reeling from thalidomide

Wasn't that one of the FDA's big victories? Perhaps you mean the FDA is far to powerful because of that win.

I can see some argument for abandoning the efficacy requirement, and only going with "safe" but so few drugs actually do anything - isn't it something like a 95% attrition rate? only 1 in 50 actually have a measurable effect?

Maybe the bar is too high. Seems like the bigger challenge, and far far greater win is just making testing cheaper.

<comment><USER6> >Wasn't that one of the FDA's big victories? Perhaps you mean the FDA is far to powerful because of that win.

depends who you ask.

Milton Friedman used the thalidomide reaction as a case-book example of government meddling in the private sector where it needn't be, causing vast delay in possible new therapeutics, which basically created an unquantifiable loss of value due to us being unaware of "what could have been without bureaucratic delay".

Friedman believed that if a company does sufficient harm to a population that the negative market signal will eventually destroy the 'bad-actor' company, without the need for anything like the FDA and the delays it imposes[0]

I don't know whether or not he's right.

[0]: [https://www.youtube.com/watch?v=KUDV0YII6lk](https://www.youtube.com/watch?v=KUDV0YII6lk)

</comment></comment></comment></comment></comment><comment><USER7> See also "mediatronic tattoo" in The Diamond Age, Neal Stephenson

</comment><comment><USER8> I think John Rogers' group already made quite some progress in this field. Maybe he is not in MIT or Harvard so not often seen here.

</comment><comment><USER9> This should help keep health insurance premiums down as all those Millennials start aging!

(I kid, I kid...)

</comment><comment><USER10> If I had diabetes I would really want this kind of capability for monitoring my glucose levels

<comment><USER11> My wife has T1D and uses a continuous glucose monitor from Dexcom to keep track of her levels.

The current state of the technology is probably best described as "finicky": the sensor skin patch needs to be replaced every week or two, at which point it's much less accurate for a couple days. It also needs calibration inputs from a finger prick at least every 12 hours. In general if the sensor is reporting a high or low condition her first action is to double-check with a finger prick. More often than not the sensor is simply wrong.

With all that said, it's better to have the sensor than not. She is able to use an app [0] to track her glucose levels over both the short term and long term trends. She's been able to use that data to make dietary decisions which allow her to keep her glucose within range and she had very good A1c levels (5.4, vs a goal of "under 7" for many diabetics) at her last checkup.

I think the long term data collection ability means that a more connected sensor (as opposed to the linked tattoo) will continue to be beneficial for diabetics. The next steps in the useful technological development will be to integrate with insulin pumps (this technology is already in trials) and to integrate with diet tracking data e.g. from MyFitnessPal to assist with meal decisions.

0: [https://github.com/StephenBlackWasAlreadyTaken/xDrip](https://github.com/StephenBlackWasAlreadyTaken/xDrip)

<comment><USER10> Recently my cousin, and my friend's child were diagnosed with type 1. Following their Facebook posts I was surprised how limited and frustrating current monitors/pumps are.

Thanks for the input from your wife's experience

</comment></comment></comment><comment><USER12> I wonder how this would fare with kids.

</comment><comment><USER13> As a type 1 diabetic, I will gladly sign up for this. As soon as this is viable and available, I will be getting my first tattoo. Now for the design, maybe the insulin molecule?

<comment><USER14> I'd imagine endurance athletes would also love an easy to read blood glucose monitor on their forearm. Would probably be great for runners or bikers.

</comment></comment><comment><USER15> Next our corporate overlords will make drug reactant tattoos.</comment>


Firefox: Flash will be loaded only from HTTP(S) sites - <AUTHOR> https://bugzilla.mozilla.org/show_bug.cgi?id=1335475 <comment><USER2> That makes a lot of sense. I believe JavaScript already has the same limitation.</comment>


Why Hiring Rockstars Is Harmful to Your Organization - <AUTHOR> https://techvibes.com/2017/10/03/why-hiring-rockstars-is-harmful-to-your-organization <comment><USER2> The ultimate conclusion of the article is that, if you hire someone who does not work well with others and doesn't allow other to critique their code, it is going to be harmful to your organisation. Doesn't seem terribly interesting. Although the authors definition of a "rock star" coder is someone who doesn't work well with others, I think that the assumption that everyone shares that same definition is mistaken.

</comment><comment><USER3> > and even if you do succeed, and have now hired a bunch of "rock stars," you > don't have a team. You have a bunch of "rock stars." In reality, rock stars > typically don't play well with others (consider these examples), and each > member is typically just in it for themselves.

So by generalizing a definition of a rockstar as someone who sucks at teamwork, you too can write an article with a clickbait headline using 2014 slang and no real science.

<comment><USER4> Yup. If I define rockstar as someone who loves teaching, has a thirst for new knowledge, and has a passion for quality, I can write a counter-article no problem.

</comment></comment><comment><USER4> You want roadies, not rockstars.

If you ever meet someone who has a passion for enabling everyone else on the team to excel at their roles, you've found a roadie. They're your force multipliers.

<comment><USER5> it's the rock stars who attract the roadies

<comment><USER6> Wait, where do the groupies fit in?</comment></comment></comment>


YEurope introduces its team, one day before their submission deadline - <AUTHOR> http://beta.yeurope.net/team/ <comment><USER3> List is unimpressive. Where are the real entrepreneurs? All I see is a bunch of lawyers (and they make the worst entrepreneurs).

<comment><USER4> It certainly isn't PG and company, but at least they're trying is all I can say. Europe really is 'that bad' for startups in some ways:-/

<comment><USER4> I thought about it a little bit more:

\- They aren't all lawyers - they've got some marketing/economics guys too.

\- In Europe, there are a lot less PG type of people in any case - <USER2> techies that have turned to funding in some way, so "business guys" is probably as good as you'll get for the time being. At least they're trying.

</comment></comment></comment><comment><USER5> I don't want to sound negative, but first impression is pathetic. A bunch of suits with no apparent startup experience , plus a techie that gave up after trying once, blatantly parasitizing on the YCombinator brand. And what with this Stephan Zeinler's Bono picture? Screams phony.

Don't judge a book by its cover and all that, but still.

[Edit: To be fair, I hadn't read the disclaimer: "This site is inspired by, but not affiliated with YCombinator." I still think they could use some personality.]

</comment><comment><AUTHOR> They're really running on a tight schedule...

On the other hand, my understanding is that they've been hard at work since their original announcement, figuring out how their program is going to work legally and organizationally. Being willing to set themselves a tight schedule when necessary and being able to meet it might not be such a bad thing for a startup investor. :-)

</comment><comment><USER4> Seeing as how I'm in Austria (albeit on the other side of the country), I went ahead and applied, just for the heck of it. Maybe I'll meet some interesting people even if they don't invest in me.</comment>


Antibiotics could cure 40% of chronic back pain patients  - <AUTHOR> http://www.businessinsider.com/back-pain-breakthrough-could-eliminate-need-for-nearly-half-of-spinal-surgeries-2013-5?IR=T

<comment><USER2> Already posted: <https://news.ycombinator.com/item?id=5667122></comment>