Email is my prefered method of communication (besides in person). At the same time, I get a lot of it, so making it better via tooling is very important to me. A large proportion of the emails I (and many other people, I’m sure – especially those in the tech world) receive are generated automatically, from LinkedIn notifications to Jira updates to monitoring alerts.

Email is good at receiving information, but then acting on the information is encumbered by the need to link out to a browser. In fact, the whole process is ungainly: receive email -> link out to browser for a single action -> return to inbox to delete message and move on, often to the next message generated by the same web app. Fixing this is just a matter of allowing mail clients a means of handling actions without linking out. They already format HTML and CSS, it’s time to add javascript as well. Let me give you a couple of examples.

Problem: I’m at a playground in central park and I need to print something at home. I have a new printer that is online, but hasn’t been setup with Google Cloud Print yet.

Solution:

1. Set up an SSH tunnel from my phone, through my desktop to the printer (using iSSH on iPhone).
2. Configure google cloud print from the browser on my phone.
3. Print from chrome.

p.s. I was at a playground with my kids, not just to print something.

Update: I’ve written a much more in-depth article on this topic that was published in Dr. Dobb’s Journal on 1/7/2014.

The typical expected path of an engineer goes something like this:

• Individual Coder
• Project Lead
• Team Lead
• Manager
• Director

At each step, their expected coding time looks something like

• 90% (Individual Coder)
• 80% (Project Lead)
• 50% (Team Lead)
• 1% (Manager)
• 0% (Director)

This seems wrong. It is not shocking that engineering management is often found to be out of touch with the tech when they aren’t working on it themselves.

I get a lot of email. I used to think I got a lot of email, but that was before 10gen. Maybe one day I’ll remember writing this and laugh because comparatively today’s load is light. I hope not, because that thought is frankly scary.

There are a number of programs I’ve written to help me deal with email. One of them is less about helping me, and more about letting the people around me know that I don’t have a special desire to ignore them.

Doing a technical phone screen has always been a challenge for me. My preferred in person technical interview, especially for more junior engineers, is to take a relatively simple programming task, and dive deeply into it. The code will be simple enough to commit completely to a whiteboard, or a piece of paper, but I’ll lead the conversation to edge cases, performance, and how to test that code, for example. The coding task is really just the framework within which the interview happens.

MongoNYC 2013 is on Friday, 6/21, and I’m really looking forward to it. This is our 4th conference in New York City, and we’re expecting over a thousand attendees.

I’m delivering two talks one on Data Safety, and another on Full Text Search, which we added in 2.4. I’ll also be presenting the MongoDB Roadmap at the end of the day, during which I’ll both preview the short-term aims of the upcoming 2.6 release, and discuss how we think about the roadmap for the next few years.

I’m trying a relatively new thing these days: working through huge lists of open MongoDB JIRA tickets using a pencil and a big printout. This turns out to be a better way for me to handle this workload than sitting at a browser and doing it interactively. To explain this, I suppose I have to explain why I’m reading all these JIRA tickets.

I’m reading all these JIRA tickets because I don’t want to lose touch with the needs of MongoDB users, in spite of the ever increasing volume of related articles, blog posts, and yes, JIRA tickets. By reading all of these things, I am trying to keep an “on the ground” sense of use cases, issues, complaints, needs, and desires, which is invaluable in decision making. Knowing that this gestalt sense is honed and working well is crucial to my peace of mind. However, this sense is dampened and feels unfocused when the information comes through layers of delegation and summarizing.

Emacs is the only editor I can use effectively at this point. It doesn’t matter if there are better choices (there aren’t ;-), it’s the one I’ve invested all of my muscle memory into. When working on files locally, I use normal emacs, and things are grand. Life, however, dictates that a great deal of my coding is done on remote machines. I had tried a variety of solutions to edit remote files (emacs in a shell, emacs of x, samba, nfs, etc…), none working terribly well for me.

MongoDB 2.5.0 (an unstable dev build) has a new implementation of the “Matcher”. The old Matcher is the bit of code in Mongo that takes a query and decides if a document matches a query expression. It also has to understand indexes so that it can do things like create a subsets of queries suitable for index covering. However, the structure of the Matcher code hasn’t changed significantly in more than four years and until this release, it lacked the ability to be easily extended. It was also structured in such a way that its knowledge could not be reused for query optimization. It was clearly ready for a rewrite.

I visited London a few weeks ago to attend and speak at MongoDB London. The event was very successful, and I enjoyed many conversations with attendees and staff during the event. But having the opportunity to spend time with our 10gen London team makes the value of the trips far exceed my contribution to the conference.

Although my time with the team was relatively short since my entire trip to the UK lasted only two days, it provided yet another example of “no substitute for in-person collaboration”.