I just finished reading “The Pragmatic Programmer” by Andrew Hunt and David Thomas - two consultants behind Pragmatic Programmers, LLC. This book might as well be a fantastic marketing trick for their consulting agency, but the value it brings to the reader is hard to underestimate.

Hunt and Thomas cover a wide variety of topics, briefly glancing over every major aspect of developing software: be it the choice of a text editor, calculating time complexity, or working effectively on a team.

If you read thematic books and actively follow programming blogs and podcasts - you may find yourself cheerfully nodding while reading sections of this book. You may have read about some of the tips online, heard from colleagues, or simply discovered them yourself. You will finish this book with a wide smile of approval, and a sense of validation in regards to your daily work flow or actions.

If you are less lucky (say, you don’t read as much), you will find 70 tips you can utilize right away, right now, at your workplace. This is what “The Pragmatic Programmer” essentially is: a collection of practical things regarding getting things done.

It’s an essential read, and I’ve seen this book in every single recommended reading list out there. And for a solid reason. This is the kind of book you want to re-read every couple of years to absorb every piece of knowledge presented within it. The latest edition of the book even contains a printout with all the tips listed in the book.

You should read it after being in the field for a few years. After making mistakes, and figuring some things out on your own. Beginners might not understand some pieces, but will still be able to comprehend a major portion of knowledge contained within this book.

I enthusiastically recommend this book to every software engineer I get to work with. It’s easy to read (as opposed to monstrosities like “Code Complete” or “Art of Computer Programming”) and it teaches you how to get things done, the pragmatic way.

I recently found an interesting way to organize random bits of information: a personal Wiki. It’s a great idea to have data repository shared between your machines: important notes about people, conversations, events, tasks you’ve accomplished, thoughts, and a hundred of little pieces of knowledge which don’t belong anywhere else. There is plenty of software out there which lets you set up a personal Wiki, and some of it is very lightweight and well polished. However, I prefer to do most of my editing and writing in Vim. As tip #22 from “The Pragmatic Programmer” states:

Use a single editor well

We think it is better to know one editor very well, and use it for all editing tasks: code, documentation, memos, system administration, and so on. Without a single editor, you face a potential modern day Babel of confusion.

I fully agree with the above statement and I try to use one editor for the majority of tasks which require typing, without having to remember which editor contains certain features, and which doesn’t. That’s one of the main reasons I went with vimwiki - a lightweight and clean personal Wiki with it’s own Wiki-style markdown. Oh, vimwiki also subscribes to another tip from “The Pragmatic Programmer”:

Keep knowledge in plain text

The vimwiki plugin has a number of interesting and useful features:

• Memorable mappings for moving in and out of Wikis. Hit <leader>ww and you are on the home page of your Wiki. The <leader>wt will open the Wiki in a new tab: the rest of the mappings are as intuitive.
• Multiple Wikis support: really handy if you have a number of separate projects for which you want to keep separate entries.
• Diary-like quick notes. You can create an instant page for today by hitting <leader>w<leader>w. Combination <leader>wi brings you to a diary home page, and <leader>w<leader>i re-indexes the diary entries.
• Easy link creation: hit enter on a word and it will turn into a link to another page. Hitting enter on a link will transport you to the destination page. Simply surrounding text with double square brackets ([[]]) works as well.
• Navigation: enter to follow a link, backspace to go back.
• You can convert all your records into html by executing :VimwikiAll2HTML.
• Extensive and well written help file. Just run :help vimwiki and start reading.

The list can go on forever, but these are the features I found to be the most useful.

In order to enjoy synchronization between all my machines, I hosted my Wiki in a Dropbox folder - vimwiki lets you specify locations from each one of your Wikis.

let g:vimwiki_list = [{'path': '$HOME/Dropbox/wiki'}]

Download it from the GitHub: https://github.com/vimwiki/vimwiki.

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.