Notes on “Effective Programming: More Than Writing Code” (#kindle edition)


I have finished reading Effective Programming: More Than Writing Code on my Kindle and Kindle for PC. This post is a collection of my highlights and notes I made while reading the book.

There are two (2) important points:

  1. Some code samples were not reproduced at all in the Kindle edition. I have reported this to the Kindle Support team.
  2. Colour is not useful in a black and white device, such as the Kindle, but the Kindle for PC reproduces it okay.

The book is quite easy and interesting to read.

Some brief comments on the highlights I made in the e-book:

The difference between a tolerable programmer and a great programmer is not how many programming languages they know, and it’s not whether they prefer Python or Java. It’s whether they can communicate their ideas. By persuading other people, they get leverage. By writing clear comments and technical specs, they let other programmers understand their code, which means other programmers can use and work with their code instead of rewriting it. Absent this, their code is worthless.

Atwood, Jeff (2012-07-04). Effective Programming: More Than Writing Code (Kindle Locations 223-226). Hyperink – Guide to Effective Programming. Kindle Edition.

This also applies equally well to System Administrators, such as DBAs. We need to explain to developers and managers why the SQL is not performing as expected. It is no good just to point to a chart, such as an Oracle Enterprise Manager Performance, and say, “There is the problem! Now, go and fix it.” We need to tell a story why there is a problem and help them reach a reasonable decision.

Execution isn’t merely a multiplier. It’s far more powerful. How your team executes has the power to transform your idea from gold into lead, or from lead into gold.

Atwood, Jeff (2012-07-04). Effective Programming: More Than Writing Code (Kindle Locations 758-759). Hyperink – Guide to Effective Programming. Kindle Edition.

This equally applies to System Administrators as well. But execution has to match the capabilities of the team. If the team is biased towards engineering work, such as builds, then the operational capability is low.

One practice that I’ve found effective in getting teams to think about a product vision is the Design-the-Box exercise. This exercise is great to open up a session to initiate a project. The team makes the assumption that the product will be sold in a shrink-wrapped box, and their task is to design the product box front and back. This involves coming up with a product name, a graphic, three to four key bullet points on the front to “sell” the product, a detailed feature description on the back, and operating requirements.

Atwood, Jeff (2012-07-04). Effective Programming: More Than Writing Code (Kindle Locations 802-805). Hyperink – Guide to Effective Programming. Kindle Edition.

This is also important for operational teams to know when we have to evaluate operational scenarios, such as outages and performance degradation. We need to know what is important in order to make trade-offs.

Without a coherent vision statement, it’s appalling how many teams can’t pass the elevator test — they can’t explain what it is they’re working on, or why it matters.

Atwood, Jeff (2012-07-04). Effective Programming: More Than Writing Code (Kindle Locations 823-824). Hyperink – Guide to Effective Programming. Kindle Edition.

Again, this vision applies to operational teams. We have to deliver this vision every day.

Cajoling and berating your coworkers into compliance isn’t an effective motivational technique for software developers, at least not in my experience. If you want to pull your team up to a higher level of engineering, you need a leader, not an enforcer. The goal isn’t to brainwash everyone you work with, but to negotiate commonly acceptable standards with your peers.

Atwood, Jeff (2012-07-04). Effective Programming: More Than Writing Code (Kindle Locations 1319-1321). Hyperink – Guide to Effective Programming. Kindle Edition.

“Technical problems are easy; political problems are hard.”

What I like about Dennis’ advice is that it focuses squarely on action and results. It correlates very highly with what I’ve personally observed to work: the most effective kind of technical leadership is leading by example. All too often there are no development leads with the time and authority to enforce, even if they wanted to, so actions become the only currency.

Atwood, Jeff (2012-07-04). Effective Programming: More Than Writing Code (Kindle Locations 1358-1361). Hyperink – Guide to Effective Programming. Kindle Edition.

As a team leader, what I do is important. If I focus on database performance, the team will come around to focus on database performance as well.

Let me be quite clear on this point: if your team leader or manager isn’t dealing with the bad apples on your project, he isn’t doing her job.

Atwood, Jeff (2012-07-04). Effective Programming: More Than Writing Code (Kindle Locations 1563-1564). Hyperink – Guide to Effective Programming. Kindle Edition.

This has always been difficult for me. When do you give up on somebody?

What they found, in short, is that the worst team member is the best predictor of how any team performs. It doesn’t seem to matter how great the best member is, or what the average member of the group is like. It all comes down to what your worst team member is like. The teams with the worst person performed the poorest.

Atwood, Jeff (2012-07-04). Effective Programming: More Than Writing Code (Kindle Locations 1588-1590). Hyperink – Guide to Effective Programming. Kindle Edition.

So, you should focus on trying to improve the worst performing member of the team. Either they improve, or they leave.

While it’s depressing to learn that a group can be so powerfully affected by the worst tendencies of a single member, it’s heartening to know that a skilled leader, if you’re lucky enough to have one, can intervene and potentially control the situation. Still, the obvious solution is to address the problem at its source: get rid of the bad apple. Even if it’s you.

Atwood, Jeff (2012-07-04). Effective Programming: More Than Writing Code (Kindle Locations 1608-1611). Hyperink – Guide to Effective Programming. Kindle Edition.

It is better to improve than remove.

This is all your app is: a collection of tiny details. This is still one of my favorite quotes about software. It’s something we internalized heavily when building Stack Overflow. Getting the details right is the difference between something that delights, and something customers tolerate.

Atwood, Jeff (2012-07-04). Effective Programming: More Than Writing Code (Kindle Locations 2081-2083). Hyperink – Guide to Effective Programming. Kindle Edition.

The same for operations. All of those little glitches need to be explained somehow. The narrative about what is happening behind the scenes needs to be refined against experience. This is so we can explain why failure is occurring. The normal behaviour is so-and-so. The difference has to be this, not that.

Dogfooding can be difficult. But manning the support desk, if only for a short while, isn’t. Software developers should share the customer’s pain. I know it’s not glamorous. But until you’ve demonstrated a willingness to help the customers using the software you’ve built — and more importantly, learn why they need help — you haven’t truly finished building that software.

Atwood, Jeff (2012-07-04). Effective Programming: More Than Writing Code (Kindle Locations 2807-2810). Hyperink – Guide to Effective Programming. Kindle Edition.

At one site, I was fortunate enough to be in the same room as the Support Desk. It is amazing how much you can learn just by overhearing the support people go through problem solving.

When you work with the Chaos Monkey, you quickly learn that everything happens for a reason. Except for those things which happen completely randomly. And that’s why, even though it sounds crazy, the best way to avoid failure is to fail constantly.

Atwood, Jeff (2012-07-04). Effective Programming: More Than Writing Code (Kindle Locations 2852-2853). Hyperink – Guide to Effective Programming. Kindle Edition.

So, a site that has continual failures is a good one as long as the failures do not affect the customers.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s