Article: What Is Code?

Amazing book-length feature by Paul Ford in the latest issue of Bloomberg Businessweek:

We are here because the editor of this magazine asked me, “Can you tell me what code is?”

“No,” I said. “First of all, I’m not good at the math. I’m a programmer, yes, but I’m an East Coast programmer, not one of these serious platform people from the Bay Area.”

I began to program nearly 20 years ago, learning via oraperl, a special version of the Perl language modified to work with the Oracle database. A month into the work, I damaged the accounts of 30,000 fantasy basketball players. They sent some angry e-mails. After that, I decided to get better. [...]

What I’m saying is, I’m one of 18 million. So that’s what I’m writing: my view of software development, as an individual among millions. Code has been my life, and it has been your life, too. It is time to understand how it all works.

Every month it becomes easier to ​do things that have never been done before, to create new kinds of chaos and find new kinds of order. Even though my math skills will never catch up, I love the work. Every month, code changes the world in some interesting, wonderful or disturbing way.

The web-based version is great, though I went ahead and bought myself the print edition:

Well worth a read if you want to understand how every aspect of your life is or will be impacted by software!

Article: A Product Person’s Perspective on Enterprise Selling

Interesting article from Steven Sinofsky:

Most technology leaders are consistently amazed at the depth and sophistication in enterprise selling. Since most engineers or technologists have little experience big-ticket selling, other than perhaps buying a car, this isn’t a surprise. While you might not be a designer or engineer, as a product person you have an empathy or sense of the skills, roles, and processes used. The same usually can’t be said for sales and selling.

There’s really only one key factor that distinguishes enterprise selling from everything a product person knows, and that is enterprise selling ends with the product and starts with the enterprise. Of course that is the complete opposite of what one might normallythink where everything starts with a product. Even with the most amazing and inventive product ever conceived, selling at the enterprise level and enterprise scale requires inverting your perspective.

Go read the full article!

Articles: Wait But Why on Artificial Intelligence

Tim Urban at Wait But Why (highly recommended blog) recently published a 2-parts article series on Artificial Intelligence and its possible consequences for humankind:

The AI Revolution: The Road to Superintelligence

This pattern—human progress moving quicker and quicker as time goes on—is what futurist Ray Kurzweil calls human history’s Law of Accelerating Returns. This happens because more advanced societies have the ability to progress at a faster rate than less advanced societies—because they’re more advanced. [...] So—advances are getting bigger and bigger and happening more and more quickly. This suggests some pretty intense things about our future, right?

The second article takes things further still:

The AI Revolution: Our Immortality or Extinction

To absorb how big a deal a superintelligent machine would be, imagine one on the dark green step two steps above humans on that staircase. This machine would be only slightly superintelligent, but its increased cognitive ability over us would be as vast as the chimp-human gap we just described. And like the chimp’s incapacity to ever absorb that skyscrapers can be built, we will never be able to even comprehend the things a machine on the dark green step can do, even if the machine tried to explain it to us—let alone do it ourselves. [...] But the kind of superintelligence we’re talking about today is something far beyond anything on this staircase. In an intelligence explosion—where the smarter a machine gets, the quicker it’s able to increase its own intelligence, until it begins to soar upwards.

If you don't trust my advice, maybe you'll trust Elon Musk's?

Article: Lessons from the World's Most Tech-Savvy Government

Estonia does have a lot of things to teach us:

Estonia may not show up on Americans’ radar too often. It is a tiny country in northeastern Europe, just next to Finland. It has the territory of the Netherlands, but 13 times less people — its 1.3 million inhabitants is comparable to Hawaii’s population. As a friend from India recently quipped, “What is there to govern?”

What makes this tiny country interesting in terms of governance is not just that the people can elect their parliament online or get tax overpayments back within two days of filing their returns. It is also that this level of service for citizens is not the result of the government building a few websites. Instead, Estonians started by redesigning their entire information infrastructure from the ground up with openness, privacy, security, and ‘future-proofing’ in mind.

Article: Reengineering Work: Don’t Automate, Obliterate

From a 1990 HBR article:

At the heart of reengineering is the notion of discontinuous thinking—of recognizing and breaking away from the outdated rules and fundamental assumptions that underlie operations. Unless we change these rules, we are merely rearranging the deck chairs on the Titanic. We cannot achieve breakthroughs in performance by cutting fat or automating existing processes. Rather, we must challenge old assumptions and shed the old rules that made the business underperform in the first place.

Every business is replete with implicit rules left over from earlier decades. “Customers don’t repair their own equipment.” “Local warehouses are necessary for good service.” “Merchandising decisions are made at headquarters.” These rules of work design are based on assumptions about technology, people, and organizational goals that no longer hold.

25 years old, still insightful today.

h/t to Fred Wilson for the article.

Article: Seven Plus or Minus Three

Great article by @rands:

It is this hurry-based reactive mindset that might give you the illusion that random shit time is more important than 1:1 time, but I would argue that properly and consistently deployed 1:1 time eliminates future random shit time. Because you met three weeks ago and discussed what appeared to be a listless Frank, you moved him to a new team and he didn’t quit.

Those teams are not fighting because you met with each of their leads last month and made sure each team felt heard. The proactive minutes you spend each week with your team might not contain as much energy, but they are far healthier minutes than unexpected, unhealthy, and avoidable high fructose random shit minutes.

Go read it!

Article: Estimation Games

My colleague Corina sent me a great article last week about the games that are played during the process of estimating IT project workload:

The apparent inability of IT people to accurately estimate the effort, time and cost of IT projects has remained an insolvable problem. In interview after interview with business people, our group has found that poor estimation is one of the major factors in the breakdown of relationships between IT people and their clients.

The article reminded me of the famous Programmer Time Translation Table. What's interesting is that the article focuses on the interpersonal aspect of the estimation process:

Almost all research into improving software estimation miss a vital point: it is people who estimate, not machines.
This simple point underpins the real problem in estimation. In fact, our research has shown that within certain conditions, IT people are pretty good at estimating. Further, our research has shown that the major precondition for improving estimation accuracy is the existence of an estimation environment free of inter-personal politics and political games.

Their take is similar to Daniel Kahneman's Thinking, Fast and Slow recommendation that the first thing to do if we are to fight our cognitive biases is to learn to recognize them. In other words, if you can't identify it, you can't fight it.

The article goes on to describe several of the games that are played as part of the estimation process:

It is our belief that over the 30 plus years of commercial computing has developed a series of sophisticated political games that have become a replacement for estimation as a formal process. More importantly, like all good games they are passed on from generation to generation by "children" IT people learning from "adult" managers who of course learnt the games from their adults when they were children and so on.

If you have ever been impacted by this problem (and if you work in IT, you have!), read on!

A few thought on sales from David Cummings

We had a new sales intern starting about 10 days ago. This was the occasion to dive into some relevant advice from David Cummings I read a while back.

The first 30 days for a new sales rep is all about shadowing existing team members as well as training with the sales manager. Then, by the end of the month, it’s time for live calling and prospecting. Training is a critical part of the sales rep on-boarding process.

The sales team should be working towards a reproducible, and profitable, sales process. As part of that iteration, a sales playbook should be at the top of the sales manager or entrepreneurs list of items. A sales playbook is the how-to manual for a sales rep.

Last but not least, interesting advice about connecting the Product to the Wallet:
Last week I was talking with an entrepreneur about their new product focus. After digging in, he volunteered something that really stuck with me: their new direction connects the product with the wallet in a way it never was before. Similar to the idea of candy, pain-killers, or vitamins, products that can clearly demonstrate an increase in revenue for the customer are more desirable.
With a good ROI demonstrator, pretty much every product should be able to do this. It is one of the keys of a successful sales process.