Skip to content

Great writers read…a lot

Dear Reader,

Have you ever watched one of those movies where  a software developer (usually called a hacker) is sitting in front of 2 screens and on both of them code is scrolling by at a fast pace while the hacker nods knowingly like they are reading and understanding what they are seeing?

Yeah, that doesn’t happen.

A more common scenario is that a software developer will fork a repo, clone it locally, open their editor of choice and start reading through the code. Scrolling through it slowly. opening another edito for the same code and scrolling back up to a previous section and comparing the two. This goes on for a long time.

Reading other people’s code is probably the best way to learn how to program. If you know what the code does then reading the code shows you how someone else solved the problem.

Just like a great writer reads more than they write, a great software developer will read code, theirs and other peoples, more than they will write code. As a junior developer this goes double for you. Since you do not have a body of work to copy and paste from, you need to see how other people solved common problems so you can understand how to solve them yourself.

Until next time,
I <3 |<

Practice the best

Dear Reader,

The tenants of software development put forth in Fred Brook’s seminal work “Mythical Man Month” are considered by most professional software developers to be “Best Practices”. They are not considered to be best practices because someone smart wrote them down; they are given this title because for the past fifty years smart people have reaffirmed that they are the best practices when developing computer software. Brooks talks about everything from how to estimate the time it will take, to how to structure your development teams. In fourteen chapters Brooks lays out the way to handle things.

Yes, there were software development books written before “Mythical Man Month” and yes there have been some great ones written after it. Many of they lay out current implementation practices for the era and were groundbreaking when written.

Don’t confuse current implementation practices, with best practices.

Until Next Time,
I <3 |<
=C=

How to solve the problem of crappy software.

Dear Reader,

A lot of the software we uses these days is crappy. Poorly built, insecure, crap. How do we solve this problem?

We solve it by treating software development with the respect that we treat other professions that can hurt people or destroy things.

Too many people see Software Development as a get rich quick scheme. It is perceived as ‘so easy anyone can do it’ and thus we are encouraging everyone to learn to code.

We don’t encourage everyone to become carpenters; take a 12-week course and go out and start building houses. But that is exactly what we allow in software development.

Software runs the world. We need to be at least as careful in who we let develop software as we are in who can build houses.

If you want to solve the problem of crappy software, you have got to start by getting rid of untrained an inexperienced software developers that call themselves professionals.

Until next time,
I <3 |<
=C=

 

Think like a house painter, not an artist

Dear Reader,

The lifecycle of a software project:

  • Simple and easy to use
  • Useful
  • Complex to understand but still useful
  • Unusable because of it’s complexity
  • Refactor to make it simple

Developers love complexity. However, most of the time, complexity is the enemy.

Artists love complexity. Many artists create beautifully detailed landscape scenes that you can stare at for hours and still not see it all.

House painters however create beauty with simplicity. They give special attention to a few details, like the edges, but for the most part, their goal is to create a surface that is clean and un-marred. Simple.

Yes, sometimes software needs to be complex. As developers though, we need to adopt the mindset of the house-painter, not the artist.

Create clean, not complex.

Until next time,
I <3 |<
=C=

 

p.s. Props to Brandon Savage for the idea.

“Delivery Initiated” A word on having empathy for the users of your software

Dear Reader,

Lost Luggage 1 by Aaron Tyo-DickersonLast week I was in Amsterdam for DrupalCon Amsterdam, 2014. I traveled to Amsterdam from Sofia, Bulgaria where I was attending WordCamp Europe.

The Setup: I lost my luggage

I traveled from Sofia to Amsterdam by way of Frankfurt, Germany. I was traveling via Lufthansa, a great airline if you’ve not yet had the pleasure. As I had lost my travel talisman, I fully expected something to happen along the way and I was not disappointed.

My flight arrived late into Frankfurt and I had to sprint across the Frankfurt airport to get to my flight to Amsterdam. I made it with scarce minutes to spare; my luggage however, was not so lucky. My luggage got an unexpected holiday in Frankfurt for a couple of days. This post is not about my travels or the Eli Travel Curse, I just needed to set things up. I learned something very important in all of this, I learned that we as software developers and designers need to have a great deal of empathy for the people using what we build.

It is not enough to put yourself in your user’s shoes, you have to put yourself in their mindset. You have to design every user interaction with an understanding of not only who is using your software, but why they are using it.

Once I knew my luggage did not make it, I contacted Lufthansa, they handed me off to the company that handles lost bags. I filled out the forms, they gave me a packet with a fresh T-Shirt and a bad razor, give me a copy of the report that included a URL I can visit to check the status, and sent me on my way. It is this URL that is the focus of this post.

The Problem: Developers don’t use their own software

The next day I had not heard from Lufthansa so I decided to check the status on-line. I was greeted with a form from 2004 that asked me for the basic information about my incident and the showed me a status page. That page is the heart of this post. (I wish I had had the presence of mind to take a screenshot)

The form told me that the status was “Delivery Initiated”, that is all, “Delivery Initiated”.

Now as a developer, I respect the brevity of the message. However, as a traveler in a strange land, wearing the same pair of boxers for the second day in a row, I did not appreciate it at all. The message itself was absolutely unhelpful and did nothing to ease my mind – or discomfort.

  • Did this mean they located the suitcase in Frankfurt and it was being delivered to Schiphol?
  • Did this mean that it was in Amsterdam and was being delivered to the hotel?
  • What time did the status change to this?
  • When could I expect to be reunited with my suitcase?

Nope, all I got was “Delivery Initiated”. See, Lufthansa – and the developers of their lost luggage system forgot that nobody uses their system for grins and giggles. There is no option to track someone’s random lost luggage for fun. If you are using this system, you are most likely a little stressed and probably angry at the company. They did not have any empathy for me as the user. If they had they would have given me more information. At the very least, a key off to the side that let me know what “Delivery Initiated” means would have been helpful.

 

The Solution: Have empathy for your users

A more empathetic system would have given additional statuses.

  • We found your luggage in XXX
  • Your luggage has arrived here in XXX
  • We’ve dispatched a courier with your luggage to your hotel/home
  • Your luggage has been delivered safely, we are sorry for the inconvenience

All of these would have been great statuses to let me know what was going on. Adding a timestamp would have been even better.

It is not enough to put yourself in your user’s shoes, you have to put yourself in their mindset. You have to design every user interaction with an understanding of not only who is using your software, but why they are using it.

  • If you are designing a game, the interactions will be fun, entertaining. Your users are usually in a good mood or looking to kill some time.
  • If you are designing an airline check-in system, your interactions will be streamlined and matter-of-fact. Your users want to get it done and get on with their travels.
  • If you are designing a shopping system, your interactions will help users make a buying decision.

It is not enough to create personas and figure out who is using your software. You need to understand why they are using it, and what their mindset will be when they are using it. You need to have empathy for your users.

Epilogue

It turns out that by the time I checked the online status, my luggage was actually at the hotel. The hotel however had misplaced it. :) Eli, I really need you to give me another bottle of Pyrat Rum. I need a new talisman.

Until next time,
I <3 |<
=C=

Photo Credit: Lost Luggage 1 by Aaron Tyo-Dickerson
Used under Creative Commons license