New Digs

I've been planning to move back to the wordpress platform. Now is the time to say goodbye to turbulentdensity.com. Visit my new (working on the improved part) blog http://precisematters.com

Should Everybody Learn C?

Joel Spolsky says everyone should learn C. He even gives some compelling reasons. Now, don't get me wrong, I truly respect Joel. But he's wrong. I believe he's using hyperbole. Let me tell you why I think he knows he's wrong.

Abstraction is a very important part of computer science. Without the improvements and advancements in our layers of abstraction you and I wouldn't be here today. Meaning, I wouldn't be here typing a blog entry, and you wouldn't be here reading it. Of course no one reads my blog posts even though we have come up with a lot of amazing abstractions and thus I am here typing them.

Without 3rd generation programming languages and TCP/IP, not to mention about a dozen other abstractions, the web wouldn't exist. Abstractions allow us to forget the problems and challenges those who've gone before us have already solved. Instead we can focus on solving new problem, perhaps in domains more relevant to culture or business. To Joel's point, sometimes the abstractions we build on break. Then if we don't know some of the inner workings, we are hosed. But like most things in life, none of our abstractions are perfect. And they weren't meant to be. Abstractions just have to be solid enough for us to build on top.

"Everybody should learn C." Most superlative statements can easily be proven wrong. Notice I didn't say all superlative statements can easily be proven wrong. Kidding aside, I am certainly not claiming that C isn't useful to some people. Nor do I think people won't ever cross over layers of abstractions. That's part of the feedback cycle that improves our abstractions. However, the fact is most of us don't realize the abstractions are there in first place. That is somewhat the point.

Entropy Busters

I think I coined the phrase "entropy happens." My father has a degree in Physics. So I learned about entropy when he helped me with my elementary school science fair project. We took a cookie sheet of coins all face up. Then we flipped the coins all at once. I recorded the number of heads and tails. We continued flipping and recording for several iterations.


What a simple way to see that a system of order naturally moves to disorder when energy is applied! I didn't realize at the time but entropy also applies to life. As I grew older and wiser about the world, I observed life contains many examples of systems moving from order to disorder. Thus, I fashioned my geeky substitution for the well known phrase "s*** happens."

Signal vs. Noise youtubed a spot by Ira Glass. It reminded me that entropy also takes its toll on software. This can take many forms. 37signals has long highlighted feature bloat as one of entropy's victories. Developers know code bases also trend toward disorder.

These are just a few examples of disorder in code that come to mind:

• responsibilities of methods
• responsibilities of classes
• duplication of behavior
• high coupling
  

I want to guard against promoting refactorbation. I still don't know exactly how to find the right balance between prioritizing features vs. clean code. Sure, Nobody Cares What Your Code Looks Like, except other developers. But, I've inherited enough code sets to know that some degree of cleanliness in code is important. The priority is undoubtedly:

1. Features must solve pertinent business problems.
2. Code should be clean enough to be maintainable and extensible.

In both cases we are fighting entropy. Will you be an entropy buster?

Passion Is Often Confused For Something Else

I love the way the 37signals guys handle popularity. The web can be a tough place; Jeff shares about some of the missing voices because of the popularity problem in the blogosphere. Maybe the web isn't immune to the pattern of popular culture exploiting the lives of celebrities as we see in the news everyday. But I don't think that's the whole story. He wasn't referring to written communication exclusively, but Paul Graham told us people with new ideas would be despised.

I think there are two main issues at work here.

1) Every communication medium has strengths and weaknesses. Written communication fails to convey context because it's asynchronous and one way. Always be sure to choose the right communication medium. Any form of "publishing" is inherently asynchronous. Blogs are personal publications. Of course, I'm not advocating all asynchronous communications, like blogs, should be eliminated. Just know its weakness.

2) Communication driven from passion results with an intensity that can easily be mistaken for something negative.

My blogging certainly hasn't reached any such level of popularity to have dealt with these issues. However, I can remember specific cases of verbal and instant message communications in which I've been misunderstood as both arrogant or defensive because of my strong passion about creating software. Passionate infatuation is easily confused with love. Similarly passion in communication, especially in our beloved blogosphere, is often confused for something else.

Information Overload

So just the other day I was talking about technologies and frameworks with a fellow engineer and then the million dollar question came up after much debate: "What have you done?"

And I just sat there, trying to come up with an answer to justify my points and where I was coming from, but I couldn't respond with anything recent.

I read about emerging technologies in the software engineering field. A lot. I think that's a double edge sword too, because as one keeps reading about the best practices here and there and what others have used and plan to use, you just sit there, wishing and planning on doing so many great and awesome things, but as time goes by, nothing gets done!

So my advice, which I am going to eat my own food in this case, is to learn, but above all, START SOMETHING. A popular slogan comes to mind...

Winsplit: Multi-Monitor Bliss

I share Jeff Atwood's obsession with maxmizing productivity with multi-monitor set ups. I've experimented with several utilities. Lately, I've used Ultramon and Gridmove most. After dabbling with the utilities for several months now, I have concluded the single feature I want most is moving windows between monitors. I hate making mutually exclusive decisions like which monitor a given application should reside by default. I often need two random applications on different monitors side by side, which may well contradict an app's "default" location. So, I like to be able to pop maximized windows between monitors instantly and effortlessly.

At work I have two 1280x1024 monitors.

I don't care much for the other features of either Ultramon or Gridmove. Maybe for truly high resolution screens (higher than 1280x1024) gridmove would be handy. I like using Gridmove at home on my 1680x1050 wide screen to snap windows into a normal width frame. Although, I don't consider 1680x1050 high enough resolution to fully leverage Gridmove. Gridmove can accommodate my most important feature. However, it doesn't perform well at simply moving maximized windows between monitors.

Since I find window switchers (Vista Aero, ALT+TAB, mouse click) much faster than the taskbar at switching to the desired application, I have little use for Ultramon's smart taskbar. And while the wallpaper and screen saver features of Ultramon are cool, they have no utility.

Between Ultramon and Gridmove, I believe Ultramon does the best job of switching windows between monitors. Then I met Winsplit Revolution.

Ultramon never worked for me in Visual Studio. Winsplit worked with VS instantly. The icons Ultramon adds to the title bar don't show up half the time and yet still worked if you clicked where they were supposed to be. Other times the Ultramon-blind-click-of-faith did not work. To be fair, I was running the beta as recommended for Vista. Oh yeah, and Ultramon cost $40, while Winsplit is free.

I changed the default hot-keys in Winsplit for moving the selected window to the monitor to the left, right, and to maximize from:

• CTRL+ALT+Left
• CTRL+ALT+Right
• CTRL+ALT+NUM5

to

• CTRL+ALT+Q
• CTRL+ALT+W
• CTRL+ALT+D

Now all the important commands are one handed. For example, if I am working in Outlook and want Onenote on the opposite monitor, all I have to do is:

• ALT+TAB, mouse click the window with the purple onenote icon
• If it's on the same monitor as outlook, CTRL+ALT+(Q or W) depending on if i need to move it right or left
• If for whatever reason it isn't maximized, stay on CTRL+ALT and press D

Brilliant!

Perception is Reality... Sort Of

The old saying has sticking power. It resonates. It feels true. It's hard to argue with.

I make a habit -read obsession- of finding the common themes and intersections of different readings. I was in a leadership class for two days at work this week. The discussion was excellent. Someone used the phrase "perception is reality." I immediately began reconciling this with my main conclusion of the ebook Getting Real - that running code is real, everything else is not. I had a problem. If only running code was real, what about perception? Is the old saying wrong?

A better question: does the word "real" in my conclusion mean the same thing as "reality" in the old saying? Sort of.

Perception is reality.
Perception is not shared reality.
Shared reality is what counts.

Getting Real attempts to reduce the variance of unshared realities by preferring running code over metadata about running code.