Small set of guidelines for using Slack

I have been using Slack for a long time. Here are a few guidelines based on that experience:

• Slack is part of your communications toolkit. It has limits. When you feel that you are typing too much or getting frustrated by misunderstandings then switch to a call. A consequence of this is that you should be prepared to make or accept a call — earbuds at the ready.

• Slack is great for singular topic discussions. The channel clearly displays the discussion’s history. Even if the discussion spans many days the context is always available for a quick catch up.

• Slack is terrible for overlapping topic discussions. The channel quickly becomes a hodgepodge of utterances and fragments that have little reference to the topical context. Overlapping topic channels are needed, however. For example, in one small company I worked at the #operations channel is primarily used to give notice of infrastructure changes. When using such a channel you need to remember that others will not have the same topical context as you. Where possible, include some reference to the topic — "Re X, we did Y." For example, "Re loud bang, we have flogged the responsible employee." Here "loud bang" is the strong reminder of the previous topical messages. See Threads. See Links Use pinned messages to define the purpose of the channel along with links to supporting materials. Messages are editable and so do improve and update the pinned message. Pinned messages can be quickly accessed via the "push pin" icon in the channel header.

• Slack has discussion threads. Any message can be the start of a thread. Threads provide a natural grouping of related messages. The problem with them is that it is hard to have everyone on the channel use them consistently. For example, Jane started a thread to continue the discussion, but Jack, in haste, posted a message instead. Now we have 3 messages connected by two different mechanisms. Don’t use threads unless you can get everyone on the channel to use them consistently. (Actually, just don't use threads.)

• When you want to clearly reference a previous message use a Slack link. It is long and ugly, but it is by far the most reliable reference.

• We reuse text from many different applications and written languages everyday. It is common to copy from one place and paste it into Slack, and vise versa. When you do this you bring along a lot of unseen cruft. Cruft like formatting, odd visible characters, odd invisible characters, etc. And Slack does not help, in that it wants to pretty up the text for you; emoji interpretation being the most blatant example. When pasting into Slack always use Paste without formatting or Paste and Match style. And if you are pasting something technical like an email address, an access token, my salary, etc then use Slack's inline code formatting, eg "The email is `me@there.com`" becomes

• Use the sidebar as a presence indicator. Making sure your immediate team members are favorited.

Remote teams and hiring

While I was driving to work this morning I was thinking about an earlier conversation that touched on an earlier blog posting about the difficulty of having too large a skills gap in your team or in your development organization. We agree about the skills gap. Then he said something that gave me pause to totally reconsider my stance on remote development organizations. My stance had been that they don't work as too often during a project you need the high bandwidth available in face to face collaboration. But this stance comes from assuming there is a large gap between staff. What if the gap was small? What if gap was of zero width?

It has been my experience that you can successfully communicate and work remotely together when the gap is small. The eureka moment came when I reconsidered the reputed benefit of remote work that allows you to hire the best from anywhere in the world. It is not a benefit, but a rule. It is not that you can, but that you must hire the best.

Update, 2018-10: Remote Only, https://www.remoteonly.org/, has good information and references for both remote employees and employers.

Update, 2018-11: The 25+ Best Sites For Finding Remote Work, https://skillcrush.com/2014/10/10/sites-finding-remote-work/, has more information on remote-only job posting sites.

Slack for One

I have a deep background thread running in my head that started when I read in The Year Without Pants: WordPress.com and the Future of Work about how Automattic, Inc. created a new Wordpress site for every bug. I tend to think of blogs as having weight. They are heavy. However, this is psychological response to how blogs have been used. Technically, they are not much more than a column value in a database table. One of the lightest datum there is. Slack is no different in this regard than is Wordpress; Slack's Workspace is no more than a column value in a table.

Recently, I had the idea that you could use a private Slack site for personal projects and journals. Each channel is a new project or a journal. Slack's chronologically organized messages allow for text, images, (simple) formatting, and the inline inclusion of external content such as from Google Apps. There are many bots for managing each project's actions and reminders, for example. And if you do need to share the project you can. As I thought about this more there seemed no end to how to use Slack as purely a personal information tool rather than a group communications tool. I wonder if anyone has actually used Slack this way?

Problems of a modern, digital, open office

Never liked open plan offices. Lots of studies going back to the 1960s on their problems. This new, small study shows the problems of a modern, digital, open office. Summary at Open Offices Make You Less Open.

4 skills you need to be successful in software development

Comment on Why I Was Wrong About Liberal-Arts Majors

The article is a half truth. There are 4 skills you need to be successful in software development. Two of these skills are needed to be successful anywhere and they are (1) coherent written & oral communications and (2) working well with others. Any university degree will develop these skills. The other two necessary skills are (3) having broad software development experience (both re/ tasks and teams) and (4) actually knowing the foundations of computer science. A useful programmer can get by for a long time having only skills 1, 2, and 3 but a successful programmer has skill 4. Critical thinking skills alone do not design a successful system nor do they diagnose the root cause of a problem.

I have been developing software programs and software systems for 37 years. I have met lots of very useful software developers in that time. I have met only a handful of successful software developers.

I would never build a team of only useful programmers.

Grumble about messaging conversation indistinguishability

Why, why! oh mighty God, do Slack, Skype, Messenger, iMessage, and every other messaging application not make any visual distinction between two or more conversations? Squint at the screen and you will see that every conversation looks identical -- even across messaging applications! How many times have you and I and, most likely, the developers of these applications sent a message to the wrong conversation? Lots. Please, oh pretty please, allow me to at least change the background color of conversations.

Guidelines for presenting a document for discussion

The following guidelines are for presenting a document for discussion. They seem obvious, but it seems they are not in common practice in public policy fields, esp. the South Kingstown School District.

Revision number

What revision number is the document? The number should be (mostly) consecutive -- 1, 2, 3, etc -- but, when not, at least increasing. If an established document is being changed then consider using the software version system. Revision number must be in the footer of every page.

Revision date

When was the revision finalized? Use YYYY-MM-DD date format so as to avoid international date ambiguity. (Is "10/2/12" Oct 2, 2012 or Feb 10, 2012, or Feb 12, 2010.) Revision date must be in the footer of every page.

Revision history

Summarize how the document changed with each revision. The revision history is usually located in the front matter and presented as a table of revision number, revision date, revision authors, and revision summary columns.

Page numbers

What page am I looking at and how many pages are there in total? Page number and page count must be in the footer of every page.

Line numbers

Use line numbers to give the discussants a means to directly reference a portion of the sentence or the paragraph for discussion. Line numbers appear in the left margin of every page. Line numbers are consecutive across the whole document (and not just per page). It is common to only show every 5th or 10th line number. ¶ With online documents there are no fixed lines so use numbered paragraphs.

Changebars

When content is changed change bars allow the reviewer to focus only on the changed content. With a long document, or one that has had intense discussion, not having to reread the whole document aids in moving along the document to completion. Change bars are usually placed in the left margin, but either is fine.

Table of contents

For a long document a table of contents, especially an annotated table of contents, is a guide to quickly understanding the overall structure of the document's content. A good table of contents can substitute for an executive summary.

Also of interest:

• The International harmonized stage codes is a rather sophistated encoding of ISO's document development process. I just use WORKING (not yet draft), DRAFT (not yet final), FINAL.

Which answer goes with which question?

Gripe. In real-time group discussions -- Skype, Slack, HipChat, etc -- the interleaving of messages from the multiple participants will cause confusion when many questions are open and answers are given without context. Which answer goes with which question? So, when the question is "do we need to do X with Y" then answer "Re X with Y, yes" and not "yes". It takes so little extra time and, really, if you are that short on time then find another job where clear communication is not important.

Atlassian has forgotten that Jira is a communication tool

Atlassian has forgotten that Jira is a communication tool. Comments need numbers so the team can communicate with specificity everywhere. See Skype and development teams as it applies to Jira also.

Jeff Bigler's tact filter theory

An oldie, but a goodie. Jeff Bigler's tact filter theory

W.A.I.T

When wanting to talk WAIT: That is, ask the question "Why am I talking?"

Gobby and reviewing some source code

Evans Lin and I used Gobby <http://gobby.0x539.de/trac/> last night to review a sub-system that he is implementing. It worked but was less useful than anticipated.

1. Gobby is a peer-to-peer networked application and so your application is both a server and a client. This kind of networking does not play well between corporate and ISP firewalls. The only way we were able to communicate was to have three instances of Gobby running: One for me, One for Evans, and one running on my home Linux box acting as a server. And even then, Evans needed to ssh tunnel to the Linux box. To effectively use Gobby in a WAN much consideration needs to be given to network connectivity.

2. As anticipated, Gobby's document management is very weak. The documents are listed alphabetically with no meta-data about ownership, modification time, directory path, revision number, etc. I also found the floating document list to get in the way more time than not.
3. When Evans and I were discussing our first document Evans asked if I was seeing his highlighting. I was not. We both assumed that not only would you see other's changes but you would also see other's highlighting. This is a good example of not knowing what you want until to actually trial your tools.

4. Gobby knows almost nothing about the documents it is presenting and editing. It does highlight the syntax of the document based to the document's file name extension. However, our experience with IDEs is that we want really good navigation between source code elements. For example, with Java source code we want, at a minimum, 1) class name to definition source file, 2) method name use to definition location in source file, and 3) method name definition to locations of use.

5. Gooby has a instant-messaging feature but we used Skype's voice chat. Gobby as an extension to Skype would be more useful.

Overall, Gobby has too many network connectivity issues and not enough document navigation features. If Gobby were to be implemented today then it should be a web application built using the Etherpad <http://etherpad.com/> and Bespin <https://bespin.mozillalabs.com/> toolkits with a little of the Nautilus file manager <http://live.gnome.org/Nautilus>.

A tool for informal review of a tree of documents is needed. (As opposed to a set of patches for which there are great tools. For example, Rietveld <http://codereview.appspot.com/>.) So, I will keep looking. Tell me if you find something good.

Advocates need to simplify their awareness emails

I get too many emails from advocacy organizations attempting to keep me aware of them and their work. They need to find a way to to do this without sending me pretty but functionally unhelpful email or expecting me to watch a video to get more detail. Repower America is especially bad. An itemized list of short statements of accomplishments and/or actions with links is all I need.

Read Better Scientific and Technical Writing by Morris Bolsky for some sound advice.