This plugin has been in my .vim directory for a few years, and I sometimes forget that it’s not a built-in Vim feature.

Link to a GitHub repository: https://github.com/tomtom/tcomment_vim.

I use email a lot. Maybe not as much as some, but I receive and send a fair share of mail each day. You might find it odd, but I love using email. It’s a pleasant and calm experience, and sorting through a pile of messages every morning rewards me with a sense of achievement. There are, however, few tricks I have up my sleeve, and I would like to share them today. These tips will not necessarily make you more productive, but they will provide you a with a more pleasant and peaceful experience of managing your inbox.

But first, I would like to set the scene…

The wonderful Mailbox app

I started using iOS email client called Mailbox a little over a year ago, shortly after a release. Back then, before it was acquired by Dropbox, you had to wait in order for the company to grow their servers. I patiently waited “in line” for almost a month and I finally was able to transfer all my accounts to this wonderful mail client.

It was worth waiting for. Right after starting, Mailbox archived all the conversations in my inbox, and presented me with a list of unread emails which looked an awful lot like a To-Do list. You can read and reply, archive the important letters, delete junk, or resend a conversation to yourself after a certain time span as a reminder. This is an extremely simple idea, but it is essentially what anyone’s inbox is: a list of things which need to be done. Some emails have to be replied to, some have to be acted upon in some other way. The ones that don’t get archived are deleted right away.

Mailbox turned my trash-filled inbox into a clean list of items I need to do. Since then, there never was an email I forgot to reply to, nor an important thing I forgot to do. Inbox can be referred to as “To Do”, and an archive as “Done”. This scheme makes it nearly impossible to miss anything of importance.

Unfortunately, Mailbox is an iOS-only application, and I started noticing the shortcomings of the desktop experience. And I do use desktop mail far more often than mobile. I decided to have a set of rules for managing my inbox; and this is the workflow I have been successfully using for over a year.

Workflow outside of the Mailbox app

I only use Gmail, and there probably are ways to have the same experience on other platforms. However, the Mailbox app works only with Gmail.

The first thing which needs to be done in order to start using the zero mail inbox workflow - is to empty it from all the read mail. Thankfully, the Mailbox app archives all your previous conversations the moment you install it.

Next, there has to be a way to implement a “snooze” button. There are always times when you can’t reply to an email, but don’t exactly want to keep it in your inbox (what an eyesore). Gmail does not provide a native way to resend your emails at later times, but I found a Chrome extension called “Snooze Your Email for Gmail”, which adds a simple “Snooze” button to the Gmail UI.

Now that these two things are taken care of, there is a simple set of rules to be used when a new email comes in:

• Delete. Is it a notification? Does it require saving for future reference? A lot of things should be deleted. Bills, notifications, messages from robots: these don’t have to be saved. Items in Gmail trash live for 30 days, which is enough time to find something in case of an emergency. In addition, most of this information is available from some another source anyway.
• Snooze. Do you have time right now to read/reply/act upon this email? Remind yourself about it in a few hours or days instead.
• Archive. Conversation with a real person you might want to reference to later? I save all the email chains from humans, just in case I have to search through them at a later date.
• Reply and archive. Self-explanatory. Act upon and save for future reference.
• Let it be. This is an eyesore version of using the “Snooze” button. You usually want to do this only if there are more important emails to read and act upon before getting to this one.

Ideally, when you keep items in your inbox - this means they have to be acted upon in some way. There is no reason not to archive or delete conversations which don’t require actions.

Bonus point: labels

This is a recent addition to my repertoire. I found myself often searching through certain sets of email, and hence Gmail does not support regular expressions it’s quite a big pain in the neck for me when I can’t remember certain details. I created a set of thematic labels, which group emails by projects, products, and teams. And I started religiously assigning them to all the emails I archive. First it takes a bit of work, but after a while it becomes easy to identify a pattern and create filters to assist yourself with categorization.

As a result, I can narrow down a search to a thematic subset of emails, saving myself a lot of time and frustration.

It upsets me greatly, since there is no immediate or obvious solution to an interviewing scheme which will fit every company. Some companies seem to find processes which work for their size and culture, while others struggle to do so. Human resources management is a complex subject, and it’s hard to get right.

I have experience with only a small subset of interviewing techniques, but none of the following interview components I employ seem satisfactory.

Screening

Screenings are usually done by recruiters, employees whose skills are in seeking and evaluating prospective assets to the company. The first problem here is that recruiters are not team members. Recruiters might do a really good job at, say, finding good recruiters - since this is their domain, and something they are inherently good at. But they don’t develop software. Recruiters don’t work with tech leads and team members, they don’t have the slightest real life idea what managers and leaders want from the potential hire. Hell, the problem is - most team leads don’t even know what kind of person they need. And if they do, they don’t have a slightest idea on how to communicate this properly to the recruiters.

In an ideal world, software engineers and team leads would do recruiting themselves. But this way they would not have time to do their own job, and would thus become recruiters. Boom, the company lost a good software engineer. So you end up hiring recruiters, who have not the slightest idea what a team needs (“person has to be proficient in Blah-blah-blah” is like saying that a writer has to be an expert at writing about red cubes).

Is there a solution? Probably, maybe, I don’t know. Maybe recruiters and software engineers have to communicate more. Set up meetings to discuss team needs, go through training in regards to identifying key traits in prospective engineers. Teams of engineers have to communicate their preferences better. Engineers are hired to fit the culture, not to be a “rock star”. Geniuses don’t go through the HR process, future team members do.

Interview with another engineer

This, even though it has a good intent, is a big whopping failure. What this originally is meant to do - is have a potential colleague evaluate the candidate. Sounds like a fantastic idea in theory, and sometimes it even works the way it is intended to.

Most of the time, however, you end up with a competition-driven technological fanatic bombarding an interviewee with smart-ass obscure trick questions they discovered that one time browsing their favorite language’s mailing lists from the year 1990. In the worst-case scenario, the candidate is not able to answer any of those terrible questions, satisfying the interviewer’s ego while she cranks out a negative report to a recruiter.

In a slightly better version, an engineer will give a candidate a set of hands-on tasks which rarely have anything to do with the real job responsibilities. One version of this: pair programming segment, on the engineer’s machine, under stress and with shaking hands. Are we hiring contestants for a hackathon?

When it comes to software engineering, everyone suddenly forgets that writing code is the smallest portion of the day. This might not be the case for junior programmers, but they are not the ones companies are wasting their hiring resources on. It’s the mid-level and senior workers who weren’t even evaluated on half of their job responsibilities. How are their human interaction skills? Are they pleasant to work with? Will they have issues with company policies? Will they fit? These questions are as important as one’s ability to put together a few lines of code.

Maybe interviewers have to spend less time checking how well candidates write code under pressure, and more time evaluating if they will be a good match for the company’s culture. How do they react when you point out their mistake? Can they communicate concepts clearly? Are they good at marketing themselves? You hire people, not code generating machines. Unless that’s what you need, of course.

Home assignments

Home assignments are something I personally like and despise and the same time. And I find it sad that there are a number of big fat minuses with this approach. First, one might find it insulting. “What, I have to write code for you in my own time? Couldn’t you evaluate me on an interview or something?” This method can turn a lot of people off, and unfortunately the ones that stay are not typically the best quality.

As my co-worker wisely pointed out, if you have a choice between two overall equal companies and one requires you to do more work before being considered - you will naturally pick one that accepts you easier. Any job seeker would feel more appreciated and trusted taking that route.

The honesty factor doesn’t play much role here, since you usually can tell if the person did not write everything herself during the one-on-one followup. But the cost does play a role. The interviewer has to come up with a relatively unique assignment, spend time reading and evaluating the written program, give feedback on a follow-up interview. This adds up if you have many candidates.

This technique does make sense when the list of candidates needs to be narrowed down, or when you’re at the top of your domain. Who wouldn’t complete a day-long homework for Google? Many people will happily spend a sleepless night for an employment opportunity. Even more wouldn’t, especially if someone has a number of options lined up in front of them.

What about other methods?

There is a large number of various interviewing techniques out there. Some companies combine the above specified methods to have a bare-bone hiring template. Some make candidates do paid work for a few weeks before being accepted as a new hire. Some don’t bother and just decide to wing it.

This is still a developing area; I am afraid the solution has to be obtained through the method of trial and error. There seems to be no success recipe which works for everyone. There are, however, a number of alternative solutions. I don’t think most companies put enough resources in finding a successful technique, instead opting for whatever method is in season at the moment.

You might wonder what an English language style guide from 1918 is doing in a software engineering blog. You might even get angry at me for pointing this book in your face. But I have a strong affection towards this guide; I believe everyone who has to write more than a sentence in English should read it. I like to emphasize the communication aspects of a software engineering career as much as coding or management skills.

English is not my native language, and I often struggle with the writing style. I found a number of style tips online and in the books I read, but lately I noticed a pattern: most of those tips referenced “The Elements Of Style”. The book is available online free of charge (copyright has expired; it is now in public domain) and takes only an evening to read.

What the book gives you is invaluable writing advice. The author provides concrete style rules targeted at increasing the appeal and comprehension rates of your text. Here’s my favorite piece of advice:

13. Omit needless words.

Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that he make every word tell.

“The Elements Of Style” is a timeless classic; it should be mandatory reading for every speaker or learner of English out there. I immediately applied the rules to technical documentation, email communication, and even this very blog entry. I will probably have to read through the guide multiple times over the course of the following months in order to ensure maximum retention. If you care about being understood by another human being, you should read it too.

Recently, I’ve been trying to read at least one book every week, and this week’s pick was “Expert Python Programming” by Tarek Ziade. Besides its few shortcomings, I found it to be useful - Python is a language of choice for me, and I found some valuable tips I could add to my arsenal.

The best thing about this book is that it covers a very wide range of topics: syntax recommendations and code profiling, testing practices and project management, technical writing and design patterns, package distribution and version control… My favorite chapter covered writing technical documentation: I am very interested in writing in general, and the tips Ziade provided turned out to be very useful for documenting code, writing design documents, and even posting to this blog. Not much else caught my eye, but I had a number of “Aha!” moments such as, “Oh, I never used that!” and “That’s an interesting topic to look into!” scattered throughout the book. This book is very useful for filling in little gaps in knowledge which programmers can have: the author covers an extremely wide variety of Python development aspects.

Unfortunately, I found the book to be poorly written. Weak writing style, typos in the text and code examples - it looked like the book was put together sloppily, in haste. Reviewers did not do a very good job evaluating this book. “Expert Python Programming” gives you the feeling that the author tried to fit in as much content (and code) as possible in his book, with no consistent style. Many chapters go into unnecessary details, and the author has tendency to paste completely useless chunks of code, such as a page-long output of an installer. As I have mentioned, the book hops from one topic to another, and covers a wide variety of subjects: this is both a key strength and the biggest weakness of the book. There is just “too much stuff” and it’s too scattered across the topics.

“Expert Python Programming” will be of best use to, you guessed it, an expert. I found it best to scan through the content and seek out interesting bits of information. Beginners, however, might be completely overwhelmed. While advanced and intermediate Pythonistas will get the most out of this book, it will probably be too hard (and painful) to read to be of real value.