Become the Inflection Point

December 14, 2012

An engineer from a famously successful internet company once told me something that has stuck with me for a couple of years now. He said, they measure and graph everything, and that whatever they’re working on isn’t done until they’ve measured and seen the change. As he told me they put it, they “become the inflection point”.

comments

Review: The Unwritten Laws of Engineering

December 08, 2012

I just finished reading Unwritten Laws of Engineering and thought I’d write a quick review.

The book is short with only three chapters, of which the first lives up to the title and I’d recommend to any current or aspiring engineer looking for ways to be more successful. The style of the book is very simple and easy to follow, and the advice, at least from my experience, is pretty solid. The ideas in this book should be obvious, but unfortunately just aren’t, so I think it’s great someone took the time to jot them down and share.

The second two chapters are focused on managers, which I found much less applicable to me and, probably as a result, a bit drier. If you’re a manager, or looking to become one, you’ll probably see things a bit differently - I know I would.

The book also contains the Codes of Ethics from three professional engineering organizations; probably not the worse thing to have around.

All and all, a pretty decent book.

comments

Balance

November 30, 2012

You drink too much, you put too much on your liver, you’re going to kill it. You smoke too much, you put too much on your lungs, you’re going to kill them. You drink a little bit, you smoke a little bit, you’ll be alright.

What I’m saying is, maybe the more vices you have, the better off you’ll be.

Balance.

comments

Together

November 21, 2012

Certain things go together. This is expected and unavoidable. At a certain level, we choose; but things still want to go together. Letting things flow together is easy. Changing the course of things is not.

comments

Prettyprint JSON in Terminal

June 14, 2012

When working with JSON APIs, the output from cURL can be fustrating.

Example:

$ curl -sL https://raw.github.com/gist/88b61ee74378d8bcb42b/example.json
{"first_name": "Blake","last_name":"Taylor","likes": ["git","ruby",
"octocat"], "dislikes":["adjectives","windows"], "pets": {"dog":
null,"cat":null}}%

This isn’t something to look at all day. However, it’s actually simple to add formatting.

We’ll use the Python json.tool. Pipe output through it to add validation and prettyprinting.

$ curl -sL http://bit.ly/KDCgZt | python -mjson.tool
{
    "dislikes": [
        "adjectives",
        "windows"
    ],
    "first_name": "Blake",
    "last_name": "Taylor",
    "likes": [
        "git",
        "ruby",
        "octocat"
    ],
    "pets": {
        "cat": null,
        "dog": null
    }
}

Then add syntax highlighting with pygmatize.

$ curl -sL http://bit.ly/KDCgZt | python -mjson.tool | pygmentize -f terminal256 -l javascript -O style=native

Make an alias for easy access.

$ alias json='python -mjson.tool | pygmentize -f terminal256 -l javascript -O style=native'

And with that, it becomes simple to get decent output from a JSON API.

$ curl -sL http://bit.ly/KDCgZt | json

comments

Gmail Compose is a Fat Ass

June 02, 2012

Perhaps you’ve noticed that the Gmail compose view is dependant upon the width of your browser window. This means, if you’re on a 27″ monitor, you’ll likely have a much wider compose view than someone on a smaller monitor or device.

This variable width presents a problem as the available horizontal space seems to have a significant impact on the perceived length of an email, and as a result whether or not it will be read, and the communication a success.

Just imagine how bad it could be for an email on your iPhone from a person who drafted it fullscreen on their super-sized monitor. One line for them could fill up your entire view. There’s a mismatch of perception here and it leads to trouble. Even on my modest 13″ screen, emails that look short can appear too long when read on someone’s phone, and this is a real concern as they often will be.

Fixing the Problem

So, what’s the solution? At the very least, the compose view should have a max width. However, it would be a shame to impose this constraint on the user. Instead it should simply be available as a default. I envision some some sort of drag handle and perhaps a couple buttons to allow toggling between the manufacturer default, user preference and full width (Similar to how the + button on an OS X window works.).

So in conclusion, it’s always been important to stay direct and to the point, or in other words, short, but perhaps that’s even more the case now. People read email on small screens. We should keep this in mind, no matter the size of the screen or window we’re composing in, and Gmail should make this easier to do by allowing us to control the width of the compose box.

comments

Clean Code

April 08, 2012

I’m often conflicted on the level of effort I should take to clean up the code I work with.

Certainly, taking no effort, and even using the presence of bad code as an excuse to write more of it leads to problems. On the other hand, making every possible refactor to leave the code in an idol condition is likely misguided if your job is to produce results.

The Boy Scout Rule

According to this this Amazon customer review, Clean Code, by Robert C. Martin, introduces The Boy Scout Rule. This rule states that like a Boy Scout should always leave a campsite in better condition than found, so should we do the same with our code.

I love this! It wonderfully addresses my concerns above. I’ll be sure to call upon it often in the future.

comments