Month: September 2012

The 8th Characteristic

Biologists will tell you that life has 7 characteristics: organization, metabolism, irritability, reproduction, homeostasis, adaptation, and growth.

I think this list is missing something. It’s foundational, indisputable, and familiar even to kindergartners. But perhaps only kindergartners would call it out; several generations of biologists seem not to notice it enough to add it to their short list. Pick up a biology textbook, and you are unlikely to find a single chapter devoted to it.

Are you ready?

The 8th characteristic of life: mortality.

All living things die.

We see without seeing… Photo credit: John O’Neil (Wikimedia Commons)

Think about the consequences for a few moments. Would any of the ecosystems that you see on nature documentaries be possible without death? Would human civilization, as we know it? Read Orson Scott Card’s short story, “Mortal Gods,” and ponder.

Community blindness

Why am I writing about this as a software guy?

Continue reading →

How to turn coding standards into epic fails — or not

Yes, a restaurant really displayed this sign. I doubt it influenced anybody’s behavior…

Some attempts to influence the behavior of other people succeed; others are doomed from the get-go.

Coding standards are usually written because we want to influence the structure or style of code produced by engineering teams. Sometimes they’re helpful; more often they’re ignored and forgotten; occasionally they provoke fireworks or bitter resentment.

I’m not sure there’s a guaranteed formula for success, but there’s a guaranteed formula for failure; let’s cover that first, and then see what helpful suggestions we can derive.

How to turn coding standards into epic fails

1. Micromanage.

Leave no room for personal style and creativity. Make no attempt to distinguish between meaty issues and utter trivialities. State all rules in absolutes; allow no exceptions. Announce enforcement in code reviews. Bonus points if you actually follow through on the threat, and double bonus points if you display some other developer’s code in front of the team as an example of egregious violations.

“Always put a space between an identifier and a curly brace, except in nested struct initializers where the first member is a string literal (other than NULL) or a #define’ed constant.”

“Begin every function with a comment that specifies the name of the coder, the date the function was last modified, the purpose of the function, an annotated history of how the function has evolved over time, a list of functions called by your function, your zodiac sign, and the names of all parameters. Make sure that parameters are listed alphabetically (case-insensitive), with a blank line between each, and the explanatory text after the param name indented 8 – (len(param name) mod 4) spaces.”

Continue reading →

Six Learning Tips For Tech Folks

In Seven Habits of Highly Effective People, Stephen Covey reminds readers to periodically suspend their lumberjacking long enough to sharpen the metaphorical saw. In other words — take time to renew, to learn, to get better, to work smarter.

Sharpen the saw. Photo credit: ATsawyer (Wikimedia Commons).

Chances are, you’re nodding your head. We all recognize the truth of the principle, but we struggle to put it into practice. My friend who’s a voracious learner is an example we all need to emulate better.

Here are a few tried-and-true habits that help me.

1. Look it up.

If you’re like me, you constantly encounter new acronyms, technoslang, APIs, languages, buzz words… Years ago, the effort to track down the meaning of such items was substantial–a trip to the library, maybe. Now you can usually define a term with 10 seconds of googletime, and you can get the skinny on fatter topics with a 30-second scan of a wikipedia topic. We spend so much of our time in front of screens; resolve now to make a habit out of looking up what you don’t know. It will cost your schedule nothing, and keep you learning.

2. Read.

I’m not suggesting that you should spend hours every day devouring deep content. I subscribe to a number of blogs, newsletters, and industry publications, and I usually rip through all of them in just a few minutes each day. For subscriptions that arrive in my email, I often read subject lines or headlines only, then press Delete. This keeps me aware, and I can always dive in if something truly interesting comes up. I also use StumbleUpon, which has led me to delightful discoveries a few times.

Besides the digital equivalent of sound bites, it’s important to expose yourself to richer content. Ask people you respect for book recommendations. Set a goal to read an in-depth magazine article once a month…

3. Follow thought leaders.

All voices in the blogosphere are not created equal. Twenty or thirty years ago, the only way to get inside the mind of luminaries was to hear them present at conferences, and to buy their books. Now, barriers to silent up-close study (or even one-on-one dialog) are much lower. People like Linus Torvalds, Scott Meyers, Bjarne Stroustrup, Guido van Rossum, Yukihiro Matsumoto, Martin Fowler, RMS, Kent Beck, Don Box, Erich Gamma, and Grady Booch have web sites, podcasts, twitter accounts, google profiles, and the like. Connect and learn.

4. Keep track of questions.

I have a google doc where I record topics on my to-study list, things I want to memorize, experiments I want to try. I also take plain old pen and paper to meetings, and take notes not so much about content but about loose ends or questions that arise in my mind.

Of course, you need to revisit your questions and answer them now and then. Maybe while a build is running and you’re eating a sandwich…

5. Teach others.

The conventional wisdom that the teacher learns more than the students is not just trite sentimentality. Put yourself on the hook to teach something that you’ve learned. If you’re comfortable presenting, volunteer to train team members. If that makes you nervous, write up something you learned in a blog. Or write an email to someone at work, sharing a cool blog post that made you think. Or just capture your learning in insightful comments in your code. But get the ideas out to others, which will deepen and enrich their potency in your own mind.

6. Find a foil.

In literature, a foil is a character that, when placed beside the protagonist, provides significant contrast in personality, style, or motivation. Foils challenge tidy assumptions and deepen the character that the reader cares about the most.

We all need to be challenged. We need to learn about other viewpoints–not at some surface level, so we’ll have talking points to contradict, but in depth, so we appreciate the contributions that other human beings can offer. Nothing is more certain than that the aggregate wisdom of others will always exceed our private insight.

Chances are, you’ll regularly encounter viewpoints different from your own, with no particular effort. So set yourself the task of thoroughly understanding and articulating such a viewpoint now and then, to the point where its proponent would nod with satisfaction and agree that you’ve nailed their thinking. Good things will happen.

Action Item

Pick an item or two from the suggestions above–or find some ideas of your own, that work for you–and start today to turn them into habits. Slow and steady is better than inconsistent bursts…

Extra credit: Tell others about the goals you set. This commits you, and might stimulate some worthwhile conversations. Or add a comment here, sharing other ideas you have. (Remember the value of teaching… :-)

Julie Jones: Learn voraciously.

(A post in my “Role Models” series…)

When you’re a twenty-something computer geek, the pace of the software industry doesn’t worry you much. You’re full of energy and enthusiasm for your chosen career, and you’re confident you’ll quickly absorb whatever wasn’t covered during college.

Add a decade or so, and you may see the world a bit differently.

Expertise and Moving Targets

Is mastery possible when your instrument keeps changing? Photo credit: Wikimedia Commons

The rate at which new technologies burst on the scene, acquire mindshare, and demand the attention of engineers can be overwhelming. A journeyman’s knowledge on a given subject may be obsolete long before it matures into mastery. Gartner’s hype cycle can make your head hurt.

If you aspire to excellence, the dawning realization that you will never learn it all (you can’t be perfect on breadth), and that even in a narrower problem domain where you might specialize, flux will erode your skills (you can’t be perfect on depth) might cause some angst.

Maybe you’ve read Malcom Gladwell’s Outliers. Yo Yo Ma put in 10,000 hours to become great at the cello; what are you supposed to do if your instrument changes every year or two?

My friend Julie has an answer.

Learning to Learn

I first met Julie Jones when I was in my early 30’s. We worked together on the “new engine” initiative at PowerQuest (a pivotal experience I’ve blogged about before). Julie had much more experience than I did; she taught me abstract factories and dependency injection, loose coupling, declarative programming, streams, unit testing, XP, and many other key concepts.

At first I thought Julie just plucked these ideas out of an impressive mental archive. She had rich and varied experience, and she seemed to know so much.

As I came to know her better, however, I realized that knowledge was not her great talent. Sure, she knows a lot–but more importantly, she learns a lot. The XP she taught me–that came from a book by Kent Beck that she’d just finished. The loose coupling? Scott Meyers, Effective C++. Again, recent reading. Fancy template techniques? Alexandrescu, Modern C++ Design, just barely published.

Julie was constantly, steadily learning. She subscribed to the C++ User’s Journal. She played around with new boost libraries. When she got an assignment to improve the build system, she tinkered with Perl, then decided she wanted to learn Python and threw herself into the effort with gusto. One weekend, she wrote a Python module to manage advancement in her foosball tournament; within a month or two, she was teaching the rest of us. She was always adding new books to her bookshelf. She went to conferences. When we had to have support for LDM and dynamic disks in our disk management layer, Julie volunteered, studied the relevant specs, and quickly rolled out library extensions.

What I learned from Julie’s example is that a superb software engineer isn’t so much an expert on a technology; a superb software engineer is an expert student of technology.

Learn to learn. In the long run, the engineer who’s mastered that skill will deliver far more business value than a narrow subject matter expert. And she or he will have a lot more fun surfing the turbulence of the tech industry.

Thanks for the lesson, Julie.

Action Item

Identify a few habits you could form to help you learn more, more often, and more easily. (Check out this post for some ideas.) Start working on them.

Code Isn’t Art

Programmers, tell your inner artist to shut up.

One of the defining aspects of the Ruby programming language is that it is very flexible. It takes a very UNIX-like approach of having a few simple and well-defined functions that allow you to build rather complex systems. Unfortunately, it also ends up encouraging programmers to start thinking of their code as art, and then they start writing “clever” code. There’s nothing necessarily wrong with finding an unconventional solution to a coding problem, but that often falls apart when you have to involve another human in reading your “art”.

Let’s use an example from SQL of a “clever” solution. Take a look at the following query:

SELECT cl.Language, c.Name AS “Country Name” FROM CountryLanguage AS cl INNER JOIN Country AS c ON cl.CountryCode=c.Code SORT BY c.Code

How long did it take you to read that query? Probably a good minute or two because you had to expand out all of the aliases to figure out what it’s doing. Compare that to the unaliased version below:

SELECT CountryLanguage.Language, Country.Name AS “Country Name” FROM Country Language INNER JOIN Country on CountryLanguage.CountryCode=Country.Code SORT BY Country.Code

As you can see, it isn’t a “clever” query, but it sure is a lot more readable to a third party.

A lot of programmers will probably come back with “so what? I can read my own code and it gives me the result I want.” The fatal flaw here is that code is written not for machines, but for people. (Odds are good you’re also not going to be the only person that sees that code.) If we were writing for machines, you’d be using pure binary. All programming languages are made to give humans a way to express this in terms that are much more easily understood. Heck, SQL had an explicit design goal to be easily understood by accountants that needed to work with a database. The human element is crucial.

This is especially frustrating for those of us in support roles. I have a long history with SQL, some PHP experience, and I’ve done some dabbling with Ruby on Rails, but that’s atypical. Most support people don’t have any programming experience. What if they’re in a situation where they need to decipher the scripts that support a product or, heaven forbid, peruse the source code to try and find the cause of a particular error? They can probably figure out verbose code from having dealt with pseudo-code examples but will run straight into a brick wall if a programmer decided to be “clever”. Now the engineering team has to be drawn into something that could have potentially been resolved by support.

The question you have to ask yourself is if the ego boost from “clever” code is worth the increased work created when others don’t understand your “art”. I’m going to bet that your team members, members of supporting teams, and any management you report to won’t look favorably upon it.

Jesse Harris has been a geek since cutting his teeth on the Commodore 64 in pre-school. He currently works in support at RSA, the security division of EMC, and has been doing support, systems administration, and web development for 13 years.