Flowdock Blog

I like to ask people what they've tried so far so I can understand their thought process - but also to give them a hint that I expect them to use brain a little bit.

With every client I've ever worked with I always have a wiki page with common Q&A, some "required reading" and links to other wikis / docs.

If people do the incredibly annoying thing of starting conversations with "Hi" or "Hey Sam, how's it going?" Or even worse "Hey, can I ask a quick question?" I politely share this site https://nohello.net if I feel it likely won't be taken with (much) offence.

If they always send you a DM/PM rather than asking in a shared room I ask them to please start a thread in the room so that others can learn and the help can be load balanced, I often link people to this article: http://blog.flowdock.com/2014/04/30/beware-of-private-conversations/

If none of this helps and they really are just being lazy - I all have a direct conversation with them and be pretty frank that the value people add to a team / company is the effort and how they go about problem solving - if they're just acting as a middle-person passing questions and answers around it becomes and highly inefficient system.

Not thinking before asking someone else for the answer is a learned behaviour. It can be learned from being out of your depth, low confidence often combined with a lack of context, laziness or general incompetence. Most people aren't generally incompetent but have become comfortable with their…

It definitely let me know that the market for Ruby on Windows isn't anywhere near what I thought it was.

It's a story that goes back a long way too. Some people care about Ruby on Windows a lot but in the main, nah, Ruby and Windows don't gel and there isn't the mass interest. As true now as when I wrote about this problem back in 2008: http://www.rubyinside.com/is-windows-a-first-class-platform-for-ruby-823.html

Back at Euruko 2008 I chaired a panel on the topic of Ruby + Windows after a few Windows advocates asked me to get a feel for the what the community though. You could have seen a tumbleweed go across the room of 300 developers! And Matz's opinion was pretty clear: http://blog.flowdock.com/2008/05/29/ruby-release-compatibility/

And before HipChat there was (and still is) Flowdock [0]. I think they have the best threading model I've still seen on chat apps, so it was very weird seeing Slack get threading so wrong when there were much better examples to copy from.

I suppose Slack won that popularity race as they had a free tier; AFAIK Flowdock was always only available for a paid subscription. Slack definitely was for a long time the worse product. Though at some point much later Slack's larger dev budget finally tipped the scales in their favor I think.

[0] http://blog.flowdock.com/2009/07/05/announcing-flowdock-real-time-collaboration-for-teams/

The ideal thread implementation is in Flowdock (which not many people have heard of or use), but it's really the best of both worlds. Everything is a single stream of messages, and you can optionally group things as threads. There is a really nice blending of the two. Here's their implementation and you can see how well this works in practice. http://blog.flowdock.com/2017/08/31/the-1-customer-request-has-arrived-re-threading/

Far far better than other abominations like slack - which hides streams of conversation behind a wall, making the UX terrible.

I constantly wonder if all of this UI is better expressed as a slack chat room (instead of a whole new UI)

Flowdock thought of this long time back - http://blog.flowdock.com/2014/11/11/chatops-devops-with-hubot/

Github Hubot is of course a modern interpretation of it..but I wonder why chatops doesnt have the mindshare that gitops has.

Slack's deployment is human driven. It's a natural fit for a chatops style model.