- real time
- phone calls, voip
- near real time
- instant messaging & irc
- fast asynchronous
- twitter, facebook (in-your-face asynchronous)
- slow asynchronous
- email, usenet. rss, mailing lists, online forums
persistent vs transient
- static content publication
- bittorent, ftp DHT/Swarm
- connection between identities
- voip, rtc Raw P2P Connection
- transient datagrams
- email, twitter, IM, irc
routing privacy is important
vulnerable to end-point analysis
- wholly directed
- im, email
- partially directed
- mailing list, usenet
- filterable global
- twitter, registries, content-search
Yeah, my feeling is that the modern workplace is structured completely wrong. It’s really optimized for interruptions. And interruptions are the enemy of work. They are the enemy of productivity, they are the enemy of creativity, they are the enemy of everything. But that’s what the modern workplace is all about, it’s interruptions. Everyone’s calling meetings all the time, everyone’s screaming people’s names across the thing, there’s phones ringing all the time. People are walking around. It’s all about interruptions. And people go to work today, and then they end up doing most of their real work after work, or on the weekends. So, people are working longer hours, people are tired – I’m working 50-60 hours this week. It’s not that there’s 50 or 60 hours worth of work to do, it’s because you don’t work at work anymore. You go to work to get interrupted.
– Jason Fried | Why You Can’t Work at Work
Interruptions can really fuck up your workflow – takes 5-45 min to get back into the groove… so showing respect for others is very important.
- Programmer Interrupted
- Why You Can’t Work at Work | Big Think (includes transcript)
always use plain text – if you must send formated messages, use multipart mime (plain text and html)
Devices and the limitations that they impose on what they can be used to read and respond to communications belong to different shearing layers – don’t try to use the wrong device/interface to work in the wrong shearing layer.
Don’t use a device to communicate that isn’t appropriate to the type of communication.
mobile –> short form desktop/laptop –> long form
Commonly held hacker beliefs and personality traits:
Before communications between computers and computer users were as networked as they are now, there were multiple independent and parallel hacker subcultures, often unaware or only partially aware of each other’s existence. All of these had certain important traits in common:
- Creating software and sharing it with each other
- Placing a high value on freedom of inquiry
- Hostility to secrecy
- Information-sharing as both an ideal and a practical strategy
- Upholding the right to fork
- Emphasis on rationality
- Distaste for authority
- Playful cleverness, taking the serious humorously and humor seriously
– Hacker culture | Wikipedia
- Laziness
- Sharing
- Openness
- Decentralization
- Free access to computers
- World Improvement
- Access to computers-and anything that might teach you something about the way the world works-should be unlimited and total.
- All information should be free.
- Hackers should be judged by their hacking, not bogus criteria such as degrees, age, race, or position.
- You can create art and beauty on a computer.
- Computers can change your life for the better.
I believe that most of these traits and beliefs overlap with other fields as well, especially in the sciences – if you combine the above with the scientific method, we have something that can bridge between development, research, philosophy and art.
Go one step further and mix in the best of the Stoics, Epicurians and Process Philosophers and you have a very powerful personal philosophy which I will call Scopism or Scopic Philosophy & Ethics.
The Git Lab manual is very proscriptive – as it should be, but process and behavior are not always the same thing.
Back in the day, in the 80’s when I first started learning Unix, hacker culture and ethics in mailing lists, Usenet and email, I was taught that:
- always exhaust every eay you can think of trying to solve a problem on your own before asking for help.
- if you ask a question, you are obliged to answer three questions from other people. In the 90’s in a Will Smith movie this became known as paying it forward.
Claiming something “does not work” isn’t what one programmer says to another programmer. The phrase “does not work” should be reserved for when you’re taking your car to the mechanic and you don’t have a clue what’s wrong with it. If you’re telling a programmer that a particular piece of source code simply “does not work”, then you should no longer consider yourself a programmer.
– Nick Griffith | Does Not Work
- How To Ask Questions The Smart Way Eric Raymond
There are a lot of different ways in which a piece of code could “not work”. And as a programmer, even if the solution is beyond your capabilities, the exact nature of the problem certainly shouldn’t be. If you know enough to know that the code isn’t working, you should be able to at least explain to someone else what makes you draw that conclusion.
This code does not work because…
- it does not compile.
- it encounters a run-time exception.
- it does not produce the correct results.
- it launches missiles.
– Nick Griffith | Does Not Work
people who ask “can I ask you a question?” - this doesn’t have the same positive benefit as “hey, how’s it going? how was your wknd?”, it doesn’t seem to serve any purpose. I typically ask people, nicely, to just ask the question directly next time and I’ll answer when I’m able, if can’t right away. Especially in a chat-type environment in a geographically/timezone-diverse team.
– mastre_ | Does Not Work | Comments on Hacker News
- when reporting an issue, always state:
- a description of the problem (including code and or screenshots if needed)
- a description of the software and operating system the issue occured on, and what other combinations of hardware and software you have been able to duplicate the issue.
- the output of error messages, log files and debugging tools.
- an explanation of what you have tired to resolve the issue.
- an explanation of where you have searched for the solution.
More specifically, it would be great if issues pointed to a specific instance of a container and that the issue is written as literate devop document in orgmode. This would make it trivial for anyone to spin up the container and run the code from the org document and play with it and hopefully contribute a solution.
- always use english in communications – even if it is one-to-one, because it might be quoted…
- always define acronyms and abbreviations (LOL, ROFL,
IANAL, NSFW, TL;DR) the first time you use them, with
the exception of those listed in the team glossary –
don’t include anything in the team glossary, and it’s
still a good idea to link to the glossary definition.
Perhaps we can use a convention, like, any term that is
in the glossary should be marked as a orgmode
verbatimmarkup and we can programically generate links, or a search of the glossary for the term. This sounds like a waste of time, but is important to help avoid semantic rot over long periods of time and is very helpful when sending quotes to non-technical people or people who are outside the culture. - use the past-tense when describing things, which makes it easier to quote and integrate into other communications and documents.
- emoticons – always use text, not graphic or unicode, and let’s keep the number of
We’re open, and distributed, so the vast majority of what we do is in the open, so secrecy is not really an burning issue. However, because we are open, transparency is important and by extension, accountability.
- keep different roles separate
NOTE: look up etherium whisper video
AKA: Rich Text, Fancy Mail, HTML Email
- Improve Your Spam Score With Multi-Part Emails
- RFC 2045 - Multipurpose Internet Mail Extensions (MIME) | Part One
- https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
- Why HTML in E-Mail is a Bad Idea | (1998) author said he has since changed his mind.
I really can’t believe that this has to be spelled out for people, but I have seen so much abuse of email in the last few years that I guess it’s a lesson that has to be revisited periodically and learned anew by each new generation.
Email is a communications tool designed to send plain text messages. This is not a bug it’s a feature.
The long and short of it.
- Send plain text email.
- Do not use for regular communication between people
- NEVER use for mailing lists.
- Do not use for newsletters (if it’s formated, then attatch it or provide as a link).
- Do not use for marketing.
- NEVER use for security alerts.
- If you must, then ensure that there is a plain text
and html version as well using RFC2045. There are a
few situations when you might have to use:
- some bonehead demands/requests it, because plain text doesn’t reformat in some webmail apps on mobile devices. Best just to give them what they ask for, they’ll never understand.
- it is required to be used in reply to a html email (not sure if I’ve ever seen one, but hey…).
- When sending multipart mime messages, please use clean standard HTML. NEVER NEVER set a background color.
Reasons not to use:
- proportional fonts look like crap in plain text email clients that render basic html. Plain text is rendered using monospace which looks great in a text editor.
- not everyone uses web mail for everything! This may come as a surprise to some people but Gmail, Apple Mail, Hotmail and Yahoo Mail are not the only way you can get and use email.
Why Is Fancy Email So Bad?
- It’s even in the name. The word fancy is seldom used to mean anything positive.
- Is group chat making you sweat? | Signal v. Noise
- Communications: Team Handbook | GitLab