Offered with minimal comment:

• A Unified Theory of Superman’s Powers
  
  The most important scientific paper of our time.

• Managing Oneself.
  
  A short, but very clear and concise guide to managing your own career, by the father of management science.

• Stories of Your Life and Others

• Carter Beats the Devil
  Fun and thought-provoking fiction.

One of the more interesting errors in planning I’ve run across is called “fighting the last war”. This means believing in and using a strategy that has been successful in the past but is no longer a relevant tactic in the present. A famous historical example of “Fighting the Last War” is when France’s military leadership built the Maginot Line.

France built a series of concrete fortifications along their border with Germany: the Maginot Line. They didn’t fortify Belgium. This was the winning move for WWI - where armies moved slowly and concrete fortifications slowed those armies down. But, it didn’t help in WWII, when Germany flanked the Maginot line and invaded from the North, from Belgium.

I’ve made this error a bunch of times in my career as a developer and entrepreneur. I used successful tactics from previous successes when they no longer applied (or the converse, over-corrected...

Offered with minimal comment:

• The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
  
  Much like The Goal, this book is about constraint theory. Unlike The Goal (which is about factory operations), this is about IT.

• Selecting the Right Chart for Your Data and The Data Visualisation Catalogue
  
  Both are excellent resources to help you understand how to best visualize data.

• Civic Hacking
  A great resource for using open data for the greater good.

tldr: Simplicity and utility trump large corporate backing.

In the middle of 2000, SOAP - an XML-based messaging protocol - started to rise in popularity as a communication protocol for distributed computing. By 2004, there were dozens of SOAP implementations in as many languages, including all of the most popular ones, such as Java, C/C++, .NET, Perl, and PHP. The term Web service became popular, describing a new model of interaction: APIs over the Web.

I was on the team that shipped various SOAP and Web services products at Microsoft. This included various product management tasks, designing features, working across companies on interoperability testing, chairing the first WS-I committee, etc. I helped build and popularize SOAP. And I watched as it lost.

Ten years later SOAP is gone. Very few, if any, developers, are creating new SOAP-based Web services. But Web services, APIs over...

Offered with minimal comment:

• Notes on Distributed Systems for Young Bloods
  
  A review of important points in building non-trivial systems. Read it. Build something. Read it again.

• How to Become a Good Theoretical Physicist.
  
  “The costs of becoming a theoretical physicist should not exceed much the price of a computer with internet connection, a printer, and lots of paper and pen.”

• Are We There Yet?
  Hickey at his finest.

It was my great luck to work with two amazing engineers at Microsoft: Erik Christensen and Hervey Wilson. One of the most important lessons I learned from them was how to estimate. I’ve modified their methods to suit my needs, so don’t blame them if this doesn’t work for you.

Step 1: Write a small feature design document

This can be one page in google docs. Or a slide deck. Or even an interactive prototype. The key is that you can document the features you will be working on in a short and succinct amount of time.

Step 2: Make a spreadsheet of the tasks

I usually have the following columns: Area, Name, Priority, Hours, and Notes. I spend a lot of time here, re-working the areas and specific tasks. In general, I am done when the following is true:

• No task is more than four hours
• I have no more notes saying things like: “No idea how to do this.”
• There are less than 80 hours in the...

It’s a popular pattern today to build a set of APIs (usually with JSON and HTTP) to expose functionality to various applications (mobile and single-page applications.) These services are often the heart of a start-up. Ensuring they are secure is difficult, but required.

Keep in mind, if you write a service that isn’t useful or reliable, it doesn’t matter how secure it is, because no one will use it. Before you launch, though, you will need to be secure. But don’t think of it that way: security isn’t a spice that you season on your service. It’s a fundamental component of any distributed system.

I remember when an early employer of mine started taking security seriously. We stopped development on many projects, took classes, and made security a top-level component, like performance or reliability. Before then, we hadn’t taken shipping secure software seriously enough. But those tools...