Information Diet Planning - Part 1

{

Goal Setting

I’ve let it slip that one personal goal for 2011 is a more regimented information diet. I’m becoming increasingly convinced that the concepts we apply to diets on the body can be applied with some parallel applications in the world of information.

Calorie Counting

The first thing that applies to physical diets is the concept of tracking intake. Our bodies can utilize up to a certain amount of food after which, no matter how good it is, the food is going to be stored up as fat. Is tracking intake something that can be applied to information? The number of sites visited in a day, the number of browser tabs open, the amount of time getting pumped with information via some form of media: podcast, radio, screencast, television or otherwise? Is there a point where that additional reading does no good and takes away from what might have been retained?

Exercise

The second basic thing in the world of physical diets is some concomitant form of exercise. Some of this might be for burning away calories (cardio) but sometimes it’s about gaining mass or turning “fat” into “muscle.” I wonder what exercise looks like in the world of information. Steve Yegge had an old article about practice for programmers and I suspect that exercise involves designating time specifically for the mental effort related to processing information efficiently.

“The great engineers I know are as good as they are because they practice all the time. People in great physical shape only get that way by working out regularly, and they need to keep it up, or they get out of shape. The same goes for programming and engineering.”

Media and Delivery

There are different “food groups” associated with a healthy diet. Some types of food, like “fatty carbs” are very difficult to incorporate into any meaningful diet but others, like fruit, are a staple of most sensible dieting efforts drawn up for a healthier lifestyle. I wrote down my main sources of intake and looking at the list I would consider some blog entries analogous to fatty carbs or sugar whereas other forms of intake such as technical books to be a more substantive form of media for input and processing.

Confession: I’m an architecture geek¹. It started in earnest when I moved to South Dakota – it was the first time I’d lived in a rural area. I missed the built environment I was used to in cities. Along the way I’ve managed to have 14 different architecture blogs in my RSS Reader. Especially since I’m not an architect, this is excessive. I usually enjoy a story here and there but I leave a lot unread. This is a case where it’s not my curiosity that needs to go away, it’s the delivery format. I’d be better served rereading Steen Eiler Rasmussen’s Experiencing Architecture or Bjarke Ingalls’s Yes Is More than getting distracted by blog entries from the web.

Processing

I’m not sure there is any equivalent in the world of dieting but the last thing I’ve been thinking about related to my information diet is designating time for processing. Earlier this year I finally made some headway in understanding Getting Things Done and though I can’t say I’ve implemented everything David Allen recommends two things have stuck: his recommendation of using a calendar and the idea that you process information rather than letting it idle in an indeterminate state.

It’s occurred to me that in recent years information access for personal and professional development is trivial. Wikipedia is a great resource for documenting general knowledge. For professional work there are websites, link aggregators, and vendors eagerly providing a glut of information to learn from.

In this environment, what does it mean to “process” an information resource? For example, at work this week we watched Bart De Smet give a talk on a language feature of C# called LINQ. I’ve used LINQ quite a bit but his talk covered some direction in the technology that is new (Rx). In a more general sense, he referenced the Wikipedia entry on Monads – another resource which I would like to process.

I’m not sure what processing should look like but it seems like what it means to process an information resource is less of an issue than the discipline it takes to designate time for it. Perhaps that ties this notion back to exercise.

Conclusion

I’ll be using the next couple of weeks to think more about what an Information Diet should look like and a practical structure to use. I’m posting in part because I would love any input on tactics and also because committing this to the permanence of my blog means the commitment is formalized. Four areas of focus will be:

• Calorie Counting – tracking input
• Exercise – deliberate practice
• Media and Delivery – determining which formats and timing work best for information
• Processing – what steps are involved in making meaning out of information

}

¹A running joke with my wife is that I will quit my job, enroll in an architecture program just so I can be a critic. She takes great joy in laughing about this.

Language, Programming, Quirks, Conviction; Derek Sivers at RailsConf

{

“

Imagine that you are standing on a street, and you are in America, and a Japanese guy comes up to you and says “Excuse me… what is the name of this block?”

And you say “well, I don’t understand… there’s Oak street and there’s Elm street, this is 27^th street and that’s 26^th…”

And he says: “Yes but what is the name of this block?”

You say: “I don’t understand what you mean; blocks don’t have names, streets have names. Blocks are just the unnamed spaces in between the streets.”

He looks a little disappointed and leaves.

…

So now imagine that you are standing in Tokyo one day and you’re a little lost and you turn to somebody next to you and you say “Excuse me, what is the name of this street?”

And they say, “That is block 17 and that is block 16.”

And you say “Yeah, but what is the name of this street?”

And they say, “Streets don’t have names; that’s just the space between blocks 16 and 17.”

”

A great talk from Derek Sivers given at RailsConf earlier this year available on IT Conversations.

}

The Future Is Balkanized

{

“I like HTML5, but I think you're duct taping a horn on a horse and hoping it will become a unicorn.”

Shawn Wildermuth hit the nail on the head with a recent analysis entitled “The Next Application Platform? All of them... ” It would be interesting to see how many more hits the article would have gotten with a title like “XYZ is dead” or “The Death of XYZ,” perhaps something along the lines of “The Death of the One Stop platform.”

A basic summary is that he points to a future in which developers tangle themselves with the following development targets:

• An HTML5 solution for the web
• Plugins to extend HTML5 as necessary
• Desktop/Browser apps for in house/well known customers
• Apps for mobile/tablets in Objective-C, Java, and Silverlight

The sentiments are corroborated by my own experience, most recently even with a potential customer who wanted to have an iPad friendly application (native) but also wanted to support web based users who had no such device. If I could translate the request, it could simply be that they want things in the best possible experience for each of the disparate platforms for which they had users. Of course the smart phone was no exception.

In a world like this, what could the future portend but that we will have multiple platforms, no singular delivery, and a constantly increasing need to build things quickly, portably?

I’ve cited the article quite a bit but over the years I’ve always gone back to Jonathan Edwards article on Beautiful Code:

“I wish someone had instead warned me that programming is a desperate losing battle against the unconquerable complexity of code, and the treachery of requirements.”

Although Edwards was talking more specifically about code, all of my experience points towards this truth in the realms of the disparate platforms, specifically that getting something to work in a “real world” where people use different operating systems, browsers, displays, and connectivity paradigms. Over the years there have been different tactics in trying to solve the problem: web standards, ActiveX controls, Java, plugins, and of course the latest new craze, HTML5. It’s not that these tactics (and the technologies related to them) are bad: I still advocate web standards to a point, I still have my day job programming Silverlight. It’s just that the pragmatist in me thinks this is the Arab-Israeli conflict in software: no perfect solution no matter how badly its desired by those in each of the platform camps.

The big insight for me as a developer is this line:

“This means as a developer you'll need to expand what you know and learn more platforms. Is that bad or good?  Both. It means more work for all of us, but it does mean you'll need to less focus on silo's of platforms and use your knowledge across these platforms.”

}

Advent Calendars for Developers

{

Since my days trying to hack up some Perl¹ I was charmed by the idea of a developer’s advent calendar: a day by day lead up to Christmas with articles pertaining to a specific topic. I’m otherwise a scrooge during the holiday time; not given to commercialism, Christmas music, and other seasonal rituals.

But I am up for the both the Perl Advent Calendar and the RJBS (Perl) Advent Calendar. On a similar vein, Sys Advent, a sys admin advent calendar should be interesting tracking too.

Others have riffed on the idea, most notably web developers. 24ways is a seasonal advent project that I’ve tuned into each year – I usually have at least one or two of the posts stick.

Finally, there is an entrepreneurial advent calendar, 24waystostart. A lot of good things in there, I feel the onset of holiday good cheer.

I’m disappointed not to find a .NET Advent calendar (or even a Python one!). If you know of a good advent calendar, developer or otherwise, feel free to share. A few good articles can make the season pleasurable, even for a grinch like me.

}

¹Could it have been that long ago? Funny to see those old posts, but that's part of why I blog

Serialization’s “Pit of Success” with C# and JSON

{

Although it’s been mentioned before here, it bears repeating that before you find yourself making a reference to the DataContractJsonSerializer, you ought to consider and indeed are more likely better off with the NewtonSoft library Json.NET. Whereas the DataContractJsonSerializer relies on giving you the flexibility of creating types and using the DataContract and DataMember attributes on them for a lot of granular control, this is burdensome with types that should naturally find themselves serializable and JSON friendly. For example, let’s say I have a Dictionary<int, string>; the intent of the user shouldn’t be too complicated in the serialization process. Or, if I have a class Foo with a couple of properties, and I want to serialize an IEnumerable of said class, again, the intent doesn’t require the extra use of attributes and a complexity overhead.

This is not to say that the DataContractJsonSerializer does not have its place; if you are leveraging WCF and choosing JSON as your serialization format, it is probably the best route to go. That said, however, I have fallen more than once into a “pit of success” with Json.NET after getting burdened with trying to use the DataContractJsonSerializer.

Json.NET is still quite active, the last release during the latter half of this year. Check it out.

}