Unfortunately, I have not been reading as much as I would love to lately. In the past year I have only read two books, one of which was a technical manual. Don’t get me wrong, I still had a lot of personal and professional growth going on: reading blogs, articles, guides, watching keynote talks… But I did miss the feeling of holding a good book in my hands, turning the pages with the tips of my fingers, seeing the texture of the paper under the print. A few weeks ago I went ahead and ordered one of the books on my reading list: “The Design of Everyday Things” by Donald A. Norman. I just finished reading it a few hours ago and am eager to share my impressions of the book.

The Design of Everyday Things” turned out to be one of the most eye-opening books about design I have ever read (alright, alright, I haven’t read any design books before). It’s mind blowing to think that I have never considered the points brought up by the authors. Hell, (and I will probably have rotten tomatoes thrown at me for this statement) but I didn’t even think design was a “real” job. Oh dear, how wrong I was.

Norman’s masterpiece talks about the psychology of everyday things (which was actually the initial title of the book, but was changed to “Design” after the first release). The author explains how users make decisions, use objects, make errors - and so many other factors which should go into the design process. Norman explains fundamental basics of the psychology of human-object interaction, something most people never think about. How hard could it be to design a door? Turns out the answer is - very hard. And every time you see someone pulling the door instead of pushing and vice versa - it’s a result of a poor design. So many everyday frustrations could have been avoided if designers would have put more thought into usability of their product.

I build software for living, and I was skeptical if I even needed to know anything about good design. I mean, how hard could it be to put together a few pages and forms? “I tackle complex software problems, I don’t need any of this liberal arts bullshit!” - I thought that way, and I know many people who still do. Well, Norman’s book is a great starter for people like me: he does a great job explaining why the design process so important. By the time I finished reading it, I had a pretty solid set of ideas why there are so many things wrong with our industry, and how good, thoughtful design is a way out. The funniest part is - the book itself is published in the year 1988, over twenty-five years ago. It doesn’t talk much about computers, concentrating on objects more common at the time: cars, telephone systems, even stoves and dish washing machines. And here I am, reading this book in the year 2014 - and the situation did not change at all. Expensive laundry machines are as hard to operate, computer programs are as clunky.

The Design of Everyday Things” compels the reader to become a part of the solution to this enormous and bulky design problem the world is stuck with. In the everyday world, for every good case of design out there, you will face a hundred faulty, frustrating, and downright insulting design attempts.

The book is very easy and pleasant to read, and I went through it in under a week. Most of it is a set of rants about poor design decisions, with suggested improvements and solutions. Throughout the reading process, I had to revisit the systems I built at work and rearrange the components, add more feedback to user’s actions, and do many other little and big improvements in order to make make the system image much more transparent to the user. Norman taught me the most obvious truth: a designer is not your typical user of the system. This changes so many things, makes you doubt and rethink a number of design decisions you made along the way - all in order to build a product that is easy and pleasant to use.

I now consider myself to be blessed with an understanding of the importance of good design, and admitting there is a problem is the first step to fixing it. And believe me, there is a problem. I will now continue learning about the best practices in building systems that are easy to understand and pleasant to operate for the user. My next stop is “Don’t Make Me Think, Revisited: A Common Sense Approach to Web Usability” by Steve Krug. I’ve heard a lot about this book, and I will be sure to share my impressions here.

I enjoy organizing things. I am accustomed to keeping neat “To Do” lists, written notes, and just about anything that will let me arrange my tasks instead of actually accomplishing them. I recently stopped writing things down, and the results were pleasantly surprising…

I was keeping a list of things I would need to complete. I organized it by priorities, and at some point I even used Gina’s fancy “Todo.txt” wrapper for managing it.

What I realized after using such a scheme, is that my list was growing longer and longer with every week. After a while, the number of tasks became hard to manage, and the number of tasks became permanent residents on my task list. Why did this happen? Well for one, I turned my list into a “check box machine”. Complete a task, check off a check box. There was no mindfulness about it: I was just completing task after task. “All right, this one is done, let’s move to a next one.” - this is what was constantly running through my head. Secondly, by writing down a task on my list in the first place, my brain would register it as being completed, and then I’d go on with my day. Needless to say, certain tasks would sit on my list for an indefinite amount of time.

After a while, I deleted my “To Do” list. Instead, every day I ask myself a simple question: “What should I do today to succeed at what I am trying to accomplish?”. This way, work becomes achievement driven. I started choosing tasks which provide the biggest impact, dedicating some days just to minor “clean up” tasks which I didn’t deem important enough for productive days.

I threw away my “To Do” list, and I am glad I did it. I love being mindful about my day, I know exactly what I need to accomplish in order to succeed. It’s easy to get caught up in a daily route, and forget that your life isn’t just a list of things to do, but a number of goals you want to reach. By not relying on a written manifesto cluttered with tasks, I am forced to concentrate on the bigger picture, where what I set out to accomplish has the highest possible impact on my life and career.

I prefer to create and edit my posts in plain text. It’s a timeless format, and I find it nice to have an archive of posts lying around in plain text.

I wrote a little Python script which I used to extract an archive of my posts and pages into a bunch of files on my computer. In order to use it, you need to use “WordPress Importer” plugin. Export your posts and pages into a WXR format, and feed the file to the script.

Source code of the script is below (link for downloading the script is at the bottom of this post):

#!/usr/bin/env python

"""This script converts WXR file to a number of plain text files.

WXR stands for "WordPress eXtended RSS", which basically is just a
regular XML file. This script extracts entries from the WXR file into
plain text files. Output format: article name prefixed by date for
posts, article name for pages.

Usage: wxr2txt.py filename [-o output_dir]
"""

import os
import re
import sys
from xml.etree import ElementTree

NAMESPACES = {
        'content': 'http://purl.org/rss/1.0/modules/content/',
        'wp': 'http://wordpress.org/export/1.2/',
}
USAGE_STRING = "Usage: wxr2txt.py filename [-o output_dir]"

def main(argv):
    filename, output_dir = _parse_and_validate_output(argv)
    try:
        data = ElementTree.parse(filename).getroot()
    except ElementTree.ParseError:
        _error("Invalid input file format. Can not parse the input.")
    page_counter, post_counter = 0, 0
    for post in data.find('channel').findall('item'):
        post_type = post.find('wp:post_type', namespaces=NAMESPACES).text
        if post_type not in ('post', 'page'):
            continue
        content = post.find('content:encoded', namespaces=NAMESPACES).text
        date = post.find('wp:post_date', namespaces=NAMESPACES).text
        title = post.find('title').text
        date = date.split(' ')[0].replace('-', '')
        title = re.sub(r'[_]+', '_', re.sub(r'[^a-z0-9+]', '_', title.lower()))
        if post_type == 'post':
            post_filename = date + '_' + title + '.txt'
            post_counter += 1
        else:
            post_filename = title + '.txt'
            page_counter += 1
        with open(os.path.join(output_dir, post_filename), 'w') as post_file:
            post_file.write(content.encode('utf8'))
        post_counter += 1
    print "Saved {} posts and {} pages in directory '{}'.".format(
            post_counter, page_counter, output_dir)

def _parse_and_validate_output(argv):
    if len(argv) not in (2, 4):
        _error("Wrong number of arguments.")
    filename = argv[1]
    if not os.path.isfile(filename):
        _error("Input file does not exist (or not enough permissions).")
    output_dir = argv[3] if len(argv) == 4 and argv[2] == '-o' else os.getcwd()
    if not os.path.isdir(output_dir):
        _error("Output directory does not exist (or not enough permissions).")
    return filename, output_dir

def _error(text):
    print text
    print USAGE_STRING
    sys.exit(1)

if __name__ == "__main__":
    main(sys.argv)

You can download the script from here: wxr2txt.py.

I have a confession to make. Up until recently I did not know how to touch type. I would do what most people around me did: push the keys however which way I felt; make a typo; look down at the keyboard to find the letter I mistyped; repeat the whole process. I would put out up to 50 words per minute with this method, with an embarrassing error rate (which usually went up if I was showing something to someone). I am now terrified to think about those times.

It wasn’t until I stumbled upon Steve Yegge’s article “Programming’s Dirtiest Little Secret”, that I fully understood the implications of not developing proper typing technique.

Picture the following: programmer Clara is working in a small software company. Clara doesn’t use any fancy IDEs nor extendible editors like emacs or vim. Clara uses Windows’ default “Notepad” program to write and edit her source code. She is defending herself by saying that she doesn’t need any advanced features, and that she knows every keyword she needs to use by heart. She spends hours tediously searching for the files on her computer, opening them in Notepad, holding down arrow keys to get to whichever chunk of code she needs to edit (or even worse - lifts her hands off a keyboard and uses a mouse to navigate the file). Her editor only goes back one step with the “undo” operation… But Clara has good memory and she can re-type the code she erased.

What do you think of Clara? You might say that she is wasting her time and she should learn herself a robust editor. And of course, you will be right.

One day, Clara’s company hired a new tech lead - Jane. Jane noticed that Clara is very slow at accomplishing tasks assigned to her. So Jane showed Clara how to save a lot of time by using an advanced editor she uses. Suddenly Clara discovered a whole new world in front of her: it became much easier to read the code with parts of it highlighted, and the new text editor showed her when she would make a typo or a big error - even before Clara compiled the code. And Clara didn’t even have to re-invent the code she deleted, she could just travel down the undo tree back to the time when she erased the code: all of a sudden it felt like she had access to a time machine! Jane even told her that there are plugins which can write some code for Clara! How amazing is that? It took a while for Clara to learn how to use the new editor, but after a few months, Clara became almost as fast at doing her job as Jane. Maybe Clara even received a promotion from doing so many things in a short period of time.

If you don’t know how to touch type - you are Clara. You are wasting your time. You look ridiculous to your colleagues when you stare down at your keyboard while typing. Interviewers secretly laugh at you when you make five errors in a four-letter word. You are frustrated by even the remote possibility of having to write more than you absolutely have to.

Writing is a big part of the job as a software engineer. You write code, documentation, ask questions. Most importantly, you have to communicate with your colleagues and users. Most of this interaction is written: it’s a great form of communication for the job - written notes can be saved and searched through later. As a software engineer, you bring value to your company and its users. And due to the arcane nature of the craft, communication becomes crucial. You can be the smartest programmer in the world and you can write the best piece of software out there, but no one will know about it unless you communicate why is it so great, what it does, and how to use it.

By learning how to type properly, you turn a keyboard into an extension of your hand. All you have to do in order to type - is just think of words and sentences. Your muscle memory does the rest.

I now type somewhere between 60 and 80 words per minute with what I find to be a low error rate - and I have been touch typing now for little over a month. If you care for your craft, you have no excuse for not mastering a proper typing technique.

This is my first article out of what I hope will be many. I started this blog in 2012 and I’ve never written a single biased entry: just dry technical manuals, tutorials, and guides. This has lead to a number of page views from programmers in distress, but getting a certain amount of views was never the goal of this blog. To be honest, I am not even sure if I had a goal in mind. Everyone had a blog, and I thought so should I. I was hoping it will assist me in getting a job I will enjoy by increasing my online presence (and it may have). Maybe I was out for some online reputation and (knowing myself) fame. Of course, none of this happened.

What did happen, is that I created a collection of technical notes which no one cares about until they have a problem with something they are working on. And after the issue is resolved they close the page and never open it again, as one would do with a countless number of other programming blogs and tutorial collections.

Where am I leading with this?

Lately I have been (multiple times) hit with realization that software engineering is less about writing perfect (or any, for that matter) code, and is more about management and people skills. The very people skills most software engineers lack due to choice of profession (or maybe the other way). I spent some years reading books and articles on how to optimize, refactor, and design code for which any programmer would be praised and renowned for. I have even made some progress in reaching this “magic goal”.

Don’t get me wrong, writing readable and reusable programs is an essential part of the job, but it is only one scale on which a professional programmer’s performance is measured. And it’s a relatively small scale, in comparison to others.

As a professional, you have your skill of assessing priorities, productivity, time management, patience, an active learning process, and of course, the above mentioned communication skills. This post is about just that: transmitting ideas and concepts to readers.

I am not very good at human interaction. I am an introvert. Even worse, and as many of my colleagues do, I mumble something or smile awkwardly when passing someone in a hallway. What is the social protocol for such an event anyway? Whatever it is, I don’t think I am doing it right.

It’s hard to evaluate my verbal communication skills. Maybe people have hard time understanding the points I am trying to bring across in conversation. Being a foreigner, some people probably find it challenging to understand every word I say. In addition, with my tendency to slur words when I am tired or excited - it’s probably annoying to talk to me sometimes.

I can say with confidence that my writing skills suck. I spend by far more time than I should composing emails. I write a paragraph and then I delete it. Writing is a big challenge for me. I am quite sure this article is very hard to read. And I have a very strong feeling no one will read this article. Except for maybe, my wife - who is a fantastic writer and will point out every mistake I’ve made. This text will have to be revised many times before it becomes even slightly readable.

I started looking around for ways to improve the way I communicate my thoughts. I found a large number of articles, rules, and techniques which supposedly should instantly make you a better writer. This of course might be true if you are a professional writer or a student majoring in literature. I am neither. I stumbled upon a great article by Jeff Atwood: “How to write without writing”. Reading it gave me the push I needed to get over the embarrassment of the inevitable failure from writing poorly. And I know I am writing poorly, I’ve read the stuff I wrote.

You don’t expect yourself to wake up one day and write awesome code, do you? No, you wake up, go to work, fail, and maybe after months and years of practice you become better at putting together pieces of code. The same rule applies to writing. Write a lot and often, and read what smart people write. Try to be even better than them. Fail. Repeat.

This is why I am starting to write less technical entries. Abstract topics will let me hone my writing skills. All I have to do is just stick to some sort of a writing schedule. I’ll come up with things to write about, I am a pretty loud person.

P.S: My recently acquired touch typing skills have come in handy in composing this. I would have previously never had the patience to finish the wall of text I am looking at right now. Go learn to type faster.