Could it be the CEO/the bizguy who wants you to leave? Could he brought up the idea? I can hardly imagine that a hired CTO dares to say something like you wrote without backing.
Great proposal. I just upvoted it. Don't know if the typical freelancer dev will jump on it and has enough will power but I totally agree on premise 1,2 and 3, so true. Great post!
Replacing email isn't fixing email, it's replacing email. When I discovered I couldn't practice running a mile in my house, I went to the local track. I didn't fix my house, I replaced it for this particular task with something else. Isn't this the same?
I think PG is in the minority when he considers a conversation over email a "degenerate case" of a TODO list item. A public-writeable personal todo list application is separate from my email client, whether it uses the email protocol to send todo items, or a new protocol to send todo items, or http to put todo items on a centralized database, etc.
Good point, it reveals a lack of organizational and leadership skills. If one is so wanted that his inbox is quickly full either he has to reduce workload or hire staff and delegate.
Great post and we found the hidden agenda of this "email is broken" propaganda. It's sad that the VC/startup business heavily relies on hype to drive interest and valuation.
Nethertheless, I welcome that seemingly a lot do not blindly follow this BS.
The common problem you describe is still not about email.
The real cause lies in people with deficits in time management, organisational skills and leadership.
If you have too many projects/threads going on with too many people time to change: do fewer projects, focus, delegate, give people goals rather than nitty-gritty todos, basically stop micro-managing, find talented peers and trust them.
There are mechanisms through which some limitations of email can be worked around, but there are still problems with email.
Technologies lend themselves to particular use and misuse, and when we see a repeating patterns of abuse, it's reasonable to focus on the technology and talk about what we can do differently.
The original post is talking about email as a series of protocols and ignoring the culture of email as we use it in day-to-day use. It's a nerdy rant that dismisses a problem space by forcing a new definition on the language, rather than addressing the problems that people suffer. The chap I relied to continues the tone by insulting people who are dealing with the queue.
Email is the monitoring messages that clog up my inbox. It's the reasonable expectation of response that happens when somebody sends me an email, unlike with my phone where I leave voicemail turned off or a colleague can take a call and I can know that ownership has shifted. Email is the ease with which a difficult-to-understand message is sent and the exhaustion created by comprehending it. It's the poor integration with task management. It's the awkwardness around tracking ownership of an issue that's sent to a group list. It's spam. It's the compromises you make to avoid spam. It's how awkward it is to implement IMAP, and the multiple eccentricities of different IMAP servers, and how woeful POP is. It's Lotus Notes and Exchange, and being forced to use them.
I think people are looking at it the wrong way, it's not problems with email it's the fact that email is flexible, decentralized, reliable that makes it possible to use it for any of these tasks.
The asynchronous messaging that email provides is it's killer feature that would need to exist for any of the features (todo,task management,calendering...) that you mention would need to work well. But the underlying mechanism of email is still working fine and I don't think that should change.
I agree with the article, the client is where this should go with maybe some thing similar to the W3C and Browser vendors (This isn't perfect but it works) agreeing to protocols.
I an a Rails dev and want to try something new for web development. Tempted to try Node/express or Go with one of the given frameworks. How do they compare?
Honestly by far the biggest difference between the two is the difference in underlying language. Assuming you already know JavaScript the big question you should be asking yourself (depending slightly on what other languages you already know) is, "do I want to learn a completely new language, with a rather different way of doing things". The answer to this question is far more relevant than any differences or similarities in frameworks.
Could it be the CEO/the bizguy who wants you to leave? Could he brought up the idea? I can hardly imagine that a hired CTO dares to say something like you wrote without backing.